Helm Chart values.yaml Builder

Generate a Helm chart values.yaml for a standard app deployment

Build a Helm values.yaml with image repository and tag, replicaCount, service type and port, ingress with host and TLS, resource requests and limits, env vars, and a configMap data map. Runs in your browser. It runs free in your browser on Gera Tools, with nothing uploaded.

Last updated Source: Gera Tools

What is the difference between resource requests and limits?

Requests are what the scheduler reserves for the pod and uses to decide placement, guaranteeing that much CPU and memory. Limits are the hard ceiling — exceeding the memory limit triggers an OOM kill, and exceeding the CPU limit throttles the container.

A Helm values.yaml builder that produces the configuration layer for a standard application chart. Set the image, replicas, service, ingress, resources, env vars, and configMap, and copy a values.yaml you can feed to a chart scaffolded with helm create — matching its conventional key structure.

How it works

Helm separates a chart’s templates from its values. The templates contain the Kubernetes manifests with placeholders; values.yaml supplies the concrete settings. This builder emits the conventional keys those templates expect: an image map (repository, quoted tag, pullPolicy), replicaCount, a service block, an ingress block with hosts and an optional tls section, a resources block with requests and limits, an env list, and a configMap.data map.

The image tag is always quoted because YAML would otherwise parse 1.20 as the number 1.2. Env vars are expanded into the name/value list shape Kubernetes containers expect, and configMap entries become a flat data map. When ingress TLS is enabled, a tls entry with a derived secretName is added so an ingress controller can terminate HTTPS.

Tips

  • Always set both resource requests and limits. Requests let the scheduler place pods sensibly; limits prevent one noisy pod from starving its neighbors. Omitting them is a common cause of node instability.
  • For internet-facing HTTP apps, prefer ClusterIP plus an ingress over LoadBalancer. One load balancer can then front many services through host and path routing.
  • Pair the ingress tls block with cert-manager so the named TLS secret is created and renewed automatically rather than managed by hand.
  • Run helm template ./chart -f values.yaml to render the manifests locally and confirm your values produce the expected Kubernetes objects before installing.

Common mistakes in Helm values files

Unquoted image tags

The most common error is leaving the image tag unquoted. Tags like 1.0, 1.20, or 2.0 look like numbers to a YAML parser and get converted to floats, silently mangling the value. Kubernetes will then try to pull an image tagged 1 or 2 instead of your intended version. Always quote tags as strings: tag: "1.20".

Missing resource limits

A Kubernetes pod without resource limits is a risk to the entire node. If the container leaks memory, the kernel’s OOM killer will evict other pods to reclaim memory. Best practice is to set both requests (what the pod is guaranteed) and limits (the hard ceiling). A simple starting point for a typical web app:

resources:
  requests:
    cpu: "100m"
    memory: "128Mi"
  limits:
    cpu: "500m"
    memory: "512Mi"

Ingress without TLS

An ingress without TLS serves your application over HTTP, which exposes session tokens and user data. Enable the TLS option in the builder, which adds the correct tls block pointing to a named secret. Pair this with cert-manager in the cluster to automatically provision and renew a Let’s Encrypt certificate for your hostname.

Environment variables as ConfigMap data

The builder lets you define both env variables (injected directly into the container environment) and configMap.data entries (stored as a Kubernetes ConfigMap). For secret values such as API keys and passwords, neither of these is the right place — use a Kubernetes Secret and reference it via valueFrom.secretKeyRef in the container spec. Never commit secret values to a values.yaml file checked into source control.

Using the output

Save the generated values.yaml in your chart directory or alongside it, then install with:

helm install my-release ./my-chart -f values.yaml

To upgrade an existing release with updated values:

helm upgrade my-release ./my-chart -f values.yaml

To preview what manifests Kubernetes will receive without installing:

helm template my-release ./my-chart -f values.yaml