Helm in Production

Versioning and Promotion

Treat the chart as an immutable artifact: bump version for any chart change (semver — chart consumers see breaking changes via major bumps), record the deployed app in appVersion, and promote the exact same chart version through environments rather than rebuilding per environment.

Store the environment definitions next to the chart:

charts/my-api/          # source, tagged v1.4.2
envs/dev/values.yaml
envs/staging/values.yaml
envs/prod/values.yaml

Deployments become deterministic commands:

helm upgrade --install my-api ./charts/my-api -n prod \
  -f envs/prod/values.yaml --set image.tag=$TAG --atomic --wait

Because Helm records values per revision, helm get values -n prod my-api shows exactly what a running release was configured with — useful in incident review.

Secrets and Reviews

Never put credentials in Git plaintext. Two standard patterns:

• SOPS encrypts values.yaml fields with age/PGP — the decrypted file never exists in the repo, and CI decrypts at deploy time.
• Sealed Secrets / external-secrets store only encrypted blobs or reference an external vault.

Before applying anything, diff it:

helm template my-api ./charts/my-api -f envs/prod/values.yaml \
  | kubectl diff -f -

Also run helm lint, kubeconform against the rendered output, and a chart/image scanner (e.g. trivy on referenced images) in CI. helm get values and Git history together give an audit trail: what changed, who merged it, what cluster state resulted.

Pitfalls and Interview Angles

--set secrets in pipelines. Values passed with --set land in shell history, process listings, and CI logs — use files or external secret stores.

Missing --atomic. An unattended upgrade that half-applies leaves the release broken until a human notices; production upgrades should always carry --atomic --wait.

Chart drift across envs. If dev installs from main and prod from a tag, you are not testing what you ship. Pin --version everywhere.

Drilling rollback. helm history my-api -n prod then helm rollback my-api <revision> -n prod — know the pair cold; verify with kubectl rollout status after rollback.

Interview angle: walk your promotion path (build once, same version dev → staging → prod), the gates between stages, and how you would investigate what values a prod release actually has.