helm template: Command Reference for CI/CD
Render a chart to plain YAML, no cluster required.
helm template renders a chart with its values to plain Kubernetes manifests on stdout, entirely client-side. It is how you inspect, diff, and policy-check what a chart will produce before deploying. This reference covers the flags and a CI pattern.
Common flags and usage
- template <release> <chart>: render manifests to stdout
- -f values.yaml / --set k=v: supply the values to render with
- --namespace <ns>: set the namespace used in rendering
- --show-only templates/foo.yaml: render a single template
- --validate: check against the live cluster API (needs access)
Example
helm template web ./charts/web \
-f ./charts/web/values-prod.yaml \
--namespace prod > rendered.yaml
kubectl apply -f rendered.yaml --dry-run=server # validateIn CI
Rendering with helm template and validating the output with kubectl apply --dry-run=server catches both template and schema errors without deploying. Feed rendered.yaml to a policy tool (conftest/kyverno) or to kubectl diff for a review-friendly plan. template alone does not contact the cluster, so it runs anywhere.
Using this in CI
A runner has no kubeconfig, no cached context, and no interactive auth. Every kubectl invocation in CI needs the context supplied explicitly, and most confusing CI failures here are the command running against the wrong cluster or no cluster at all.
# never rely on the ambient context on a runner
kubectl --context "$KUBE_CONTEXT" -n "$NAMESPACE" get pods
# confirm what you are actually connected to before mutating anything
kubectl config current-context
kubectl cluster-info
# fail fast instead of hanging on an unreachable API server
kubectl --request-timeout=30s get nodesKey takeaways
- template renders client-side; it runs without cluster access.
- Pipe the output to --dry-run=server to catch schema errors.
- Rendered YAML feeds policy checks and kubectl diff previews.