Helm Cheat Sheet

Helm is fine until you're three values files deep and don't remember which one is winning. The commands that pull you out of that hole, plus the values-file pattern that prevents getting stuck.

install & upgrade

One verb you almost never want directly: install. upgrade --install covers both first-deploy and re-deploy, making your CI script idempotent.

• helm install nova ./chart -n prod --create-namespace, first deploy. Release name is nova.
• helm upgrade --install nova ./chart -n prod -f values.prod.yaml, the idempotent default. Use this in CI.
• helm upgrade nova ./chart -n prod --set image.tag=v1.4.2, one-off override. --set trumps values files.
• --atomic, on failure, automatically roll back to the previous release. Add to every prod upgrade.
• --wait --timeout 5m, block until pods are ready. Pair with --atomic for safe deploys.
• --dry-run --debug, render and validate without applying. Always run before the real deploy.

list & rollback

Helm keeps revision history. The day you need it, you'll be glad it's there.

• helm list -n prod, releases in this namespace. -A for all namespaces.
• helm history nova -n prod, revision log. Each upgrade gets a number; that's what you roll back to.
• helm rollback nova 7 -n prod, revert to revision 7. Creates revision 8 = revision 7's state.
• helm rollback nova -n prod, no number = roll back to the previous revision. The 3am-friendly form.
• helm uninstall nova -n prod --keep-history, remove resources but keep the revision log. Lets you redeploy without losing context.
• helm status nova -n prod, current revision, deployed time, manifest summary. The "what's in there?" check.

get values & manifest

"What values is this release actually using?" is the single most-asked Helm question. Three commands answer it.

• helm get values nova -n prod, user-supplied values only. The bits you set with -f or --set.
• helm get values nova -n prod -a, all values, including chart defaults. The full picture.
• helm get manifest nova -n prod, the rendered Kubernetes YAML that's actually applied. The source of truth.
• helm get notes nova -n prod, the post-install message the chart printed. Often has the URL or kubectl command you need.
• helm get hooks nova -n prod, the lifecycle hooks (pre-install, post-upgrade, etc.). Worth a glance when something runs that you didn't expect.
• helm get values nova -n prod -o yaml > current.yaml, export current values for diff against your repo. Catches drift.

template & diff

Render locally before you ever talk to the cluster. The two commands that turn Helm from "yolo" into "review-able".

• helm template nova ./chart -f values.prod.yaml, render to stdout. Pipe to kubectl apply --dry-run=server -f - for server-side validation.
• helm template ./chart --debug --validate, render with cluster-side validation (CRDs, etc.). Catches schema problems pre-deploy.
• helm diff upgrade nova ./chart -f values.prod.yaml -n prod, the killer plugin. helm plugin install https://github.com/databus23/helm-diff.
• helm diff revision nova 6 7 -n prod, compare two past revisions. The "what actually changed last Tuesday" tool.
• helm lint ./chart, static check on chart syntax + best practices. Run in CI.
• helm template ./chart --show-only templates/deployment.yaml, render just one template. Useful when debugging a single resource.

Chart repos

• helm repo add bitnami https://charts.bitnami.com/bitnami, add a repo. Names are local; the URL is the truth.
• helm repo update, refresh the index. Run this before every search/install.
• helm search repo postgres, search across added repos. helm search hub for the public hub.
• helm pull bitnami/postgresql --untar, fetch a chart locally so you can see what you're deploying. Always do this with charts you're new to.
• helm dependency update ./chart, pull subcharts listed in Chart.yaml. Required before install if you have dependencies.
• helm push ./chart oci://registry.example.com/charts, OCI registry support. The post-3.8 way to host private charts; no separate repo server.

Values-file patterns across envs

The pattern that prevents the 3-files-deep nightmare: one base, one per environment, one for secrets, in that load order.

• values.yaml, base. Defaults that apply everywhere. No environment-specific values, no secrets.
• values.dev.yaml / values.staging.yaml / values.prod.yaml, per-env overrides. Replicas, resource sizes, hostnames.
• values.secrets.yaml, secret refs (not the secrets themselves). Use existingSecret: pointing at a SealedSecret or ExternalSecret.
• Load order, helm upgrade --install nova ./chart -f values.yaml -f values.prod.yaml -f values.secrets.yaml. Last file wins for any conflict.
• --set beats every -f, reserve it for one-off overrides during incidents (image tag pin, replica bump). Don't put it in CI scripts.
• Lock the chart version, helm upgrade --install ... --version 1.4.2. Floating versions cause the worst kind of "it worked yesterday".