I was trying to figure out why my Helm chart wasn’t rendering correctly. A missing if condition meant a ConfigMap wasn’t being created in production. helm template showed me exactly what was (and wasn’t) being generated.
Basic usage Link to heading
See what Helm will generate without installing:
helm template my-release ./my-chart
With values files:
helm template my-release ./my-chart -f values.yaml -f values-prod.yaml
Show specific templates Link to heading
Only render one template:
helm template my-release ./my-chart --show-only templates/deployment.yaml
Useful when you just want to check one file.
From a remote chart Link to heading
helm template my-release bitnami/redis -f values.yaml
With a specific version:
helm template kube-prometheus-stack prometheus-community/kube-prometheus-stack --version 76.2.0 -f values.yaml
Diff before upgrading Link to heading
I always diff templates before upgrading production:
# Current state
helm get manifest my-release > current.yaml
# Proposed state
helm template my-release ./my-chart -f values-prod.yaml > proposed.yaml
# Diff
diff current.yaml proposed.yaml
Or use the helm-diff plugin:
helm plugin install https://github.com/databus23/helm-diff
helm diff upgrade my-release ./my-chart -f values-prod.yaml
Pipe to kubectl Link to heading
Apply the rendered templates directly:
helm template my-release ./my-chart | kubectl apply -f -
Or just view with less:
helm template my-release ./my-chart | less
Helm vs alternatives Link to heading
- Helm - Full templating, releases, rollbacks. Can be complex.
- Kustomize - Patches over templates. Simpler, built into kubectl.
- Helmfile - Declarative Helm releases. Good for managing many charts.
Helm works well for third-party charts (they’re all Helm) and simple internal apps. For complex deployments, Helmfile helps manage multiple releases.
This is the first thing I run when something isn’t deploying right. See what’s actually being generated before trying to install it.