Helm values.yaml Generator

Helm values.yaml in depth: charts, templates, overrides, and best practices

Helm is the de facto package manager for Kubernetes. Instead of writing dozens of raw YAML manifests by hand and copy-pasting them across environments, you bundle them into a chart — a directory containing Chart.yaml (metadata), values.yaml (defaults), and a templates/ folder full of Go-templated manifests. Installing a chart turns into a single command: helm install my-release ./mychart -f prod-values.yaml.

The values.yaml file is the configuration surface of the chart. Users override defaults at install/upgrade time with --set image.tag=2.0 or, more cleanly, with their own YAML file via -f my-values.yaml. Multiple files merge left-to-right, so the last one wins.

Anatomy of a chart

mychart/
├── Chart.yaml          # name, version, appVersion, dependencies
├── values.yaml         # default configuration
├── values.schema.json  # JSON Schema validation (optional but recommended)
├── templates/
│   ├── deployment.yaml
│   ├── service.yaml
│   ├── ingress.yaml
│   ├── _helpers.tpl    # reusable template snippets
│   └── NOTES.txt       # printed after install
└── charts/             # sub-chart dependencies

Go template syntax you will actually use

• {{ .Values.image.tag }} — read a key from values.yaml.
• {{ .Release.Name }}, {{ .Release.Namespace }}, {{ .Chart.Version }} — built-in objects.
• {{- if .Values.ingress.enabled }}...{{- end }} — conditional blocks (the dashes strip surrounding whitespace).
• {{- range .Values.envVars }}...{{- end }} — iterate over a list.
• {{ include "common.labels" . | nindent 4 }} — call a named template defined in _helpers.tpl and indent its output 4 spaces.
• {{ .Values.image.tag | default .Chart.AppVersion | quote }} — pipelines: fall back to AppVersion, then wrap in quotes.

Common values patterns

replicaCount: 2

image:
  repository: nginx
  tag: "1.27"
  pullPolicy: IfNotPresent

service:
  type: ClusterIP
  port: 80

ingress:
  enabled: false
  className: nginx
  hosts:
    - host: app.example.com
      paths: [{ path: /, pathType: Prefix }]
  tls: []

resources:
  limits:   { cpu: 500m, memory: 512Mi }
  requests: { cpu: 100m, memory: 128Mi }

nodeSelector: {}
tolerations: []
affinity: {}

Sub-charts and dependencies

A chart can depend on other charts (declared in Chart.yaml under dependencies, fetched via helm dependency update). The parent passes config down by nesting a key with the same name as the sub-chart: postgresql: { auth: { password: changeme } } overrides values in the bundled PostgreSQL chart. Set global: for values shared across every sub-chart.

Hooks and lifecycle

Annotate a template with "helm.sh/hook": pre-install (or post-install, pre-upgrade, post-delete, test) to make Helm run it at the right moment. Classic use: a Job that runs database migrations before the new Deployment rolls out. Combine with "helm.sh/hook-delete-policy": before-hook-creation,hook-succeeded to clean up old hook resources.

Best practices

• Always pin chart versions in CI (--version 1.4.2); never trust "latest".
• Validate before applying: helm lint, then helm template or helm install --dry-run --debug to see the rendered YAML.
• Ship a values.schema.json — Helm enforces it on install, catching typos before they hit the cluster.
• Prefer values files (-f prod.yaml) over long chains of --set; files are reviewable and version-controlled.
• Keep secrets out of values.yaml — use sealed-secrets, external-secrets-operator, or a Helm secrets plugin (helm-secrets + SOPS).
• Factor repeated label/selector blocks into _helpers.tpl and include them — drastically reduces drift.

FAQ

How do I roll back a bad release? helm rollback my-release N where N is the revision (find it with helm history my-release). Helm keeps the last 10 revisions by default.

Values files or --set flags? Files, almost always. Files are reviewable, diff-able, and live in git. --set is fine for one-off overrides in CI (--set image.tag=$SHA).

Helm vs Kustomize — which one wins? Different tools. Helm is template-and-package (good for distributing reusable apps). Kustomize is overlay-based (good for environment-specific patches on top of a base). Many teams use both: Helm to install third-party charts, Kustomize to tweak in-house manifests.

What changed in Helm v3 vs v2? v3 removed Tiller (the cluster-side component that needed broad RBAC), made releases namespace-scoped, and switched to native JSON Schema validation. Anything still using v2 should migrate — v2 is unsupported.

My template renders an empty string somewhere — what is wrong? Usually a typo in the values path. helm template . --debug shows the rendered YAML and the error. Also check {{- with .Values.foo }} blocks: if .Values.foo is nil they silently skip.