Cheat sheet

Helm

Install, upgrade, rollback, debug, and manage Helm chart releases.

Install & upgrade

# Install a chart
helm install my-app ./charts/my-app

# Install with custom values
helm install my-app ./charts/my-app \
  --values values-prod.yaml \
  --set image.tag=v1.2.3

# Upgrade (install if not exists)
helm upgrade --install my-app ./charts/my-app \
  --namespace production \
  --create-namespace \
  --atomic \
  --timeout 5m

# Upgrade with version pin
helm upgrade my-app bitnami/nginx \
  --version 15.0.0

Rollback & history

# View release history
helm history my-app

# Rollback to previous revision
helm rollback my-app

# Rollback to specific revision
helm rollback my-app 3

# View current values
helm get values my-app

# View all computed values (including defaults)
helm get values my-app --all

Inspect & debug

# List all releases
helm list -A

# Show release status
helm status my-app

# Render templates locally (no install)
helm template my-app ./charts/my-app \
  --values values-prod.yaml

# Dry run (server-side validation)
helm upgrade --install my-app ./charts/my-app \
  --dry-run

# Show computed manifest
helm get manifest my-app

Repository management

# Add an HTTPS repository
helm repo add ingress-nginx \
  https://kubernetes.github.io/ingress-nginx

# Update all repos
helm repo update

# Search for a chart
helm search repo nginx

# Search Artifact Hub
helm search hub nginx

# Remove a repo
helm repo remove ingress-nginx

# OCI registries — no "helm repo add" step
# Install directly from OCI registry
helm install my-release \
  oci://registry-1.docker.io/bitnamicharts/nginx \
  --version 15.0.0

# Pull OCI chart locally
helm pull oci://registry-1.docker.io/bitnamicharts/nginx \
  --version 15.0.0

Chart development

# Scaffold a new chart
helm create my-chart

# Lint a chart
helm lint ./charts/my-chart

# Package chart as .tgz
helm package ./charts/my-chart

# Validate against Kubernetes API
helm template my-app ./charts/my-chart | kubectl apply --dry-run=server -f -

# Show chart info
helm show chart bitnami/postgresql
helm show values bitnami/postgresql

Values & overrides

# Precedence (highest wins):
# 1. --set flags
# 2. -f / --values files (last file wins)
# 3. Chart defaults (values.yaml)

# Override nested key
--set ingress.hosts[0].host=example.com

# Override list item
--set tolerations[0].key=dedicated \
--set tolerations[0].value=gpu

# Set from file
--set-file config=./app.conf

# Set string explicitly (avoid type coercion)
--set-string version=1.0

Uninstall & cleanup

# Uninstall a release
helm uninstall my-app

# Uninstall but keep history
helm uninstall my-app --keep-history

# List failed/pending releases
helm list -A --pending
helm list -A --failed

# Delete a stuck namespace (remove finalizers)
kubectl get namespace stuck-ns -o json \
  | jq '.spec.finalizers = []' \
  | kubectl replace --raw /api/v1/namespaces/stuck-ns/finalize -f -

About the Helm cheat sheet

Helm's core loop is small — template, install, upgrade, rollback — and most of the difficulty is in understanding what it will do before it does it. The single most valuable habit is rendering templates locally and reading the output rather than applying and hoping.

Values resolution is where surprises come from. Values arrive from the chart's defaults, from files you pass, and from command-line overrides, with later sources winning. When a setting appears to have no effect, the answer is almost always that something later in that chain is overriding it, and the way to find out is to ask Helm what values it actually computed.

Release state lives in the cluster, not on your laptop. Helm stores each release's history as secrets in the namespace, which is what makes rollback possible from any machine and why a release can end up stuck if an upgrade is interrupted.

Frequently asked questions

How do I see what a chart will apply before applying it?

Render it locally with the template command, which produces the manifests without touching the cluster. A dry run on upgrade renders what would be applied — for an actual diff against the live release you need the helm-diff plugin. Rendering first turns most template errors into a local problem rather than a partially applied release.

My release is stuck in pending-upgrade. What now?

This usually means an upgrade was interrupted before completing. Check the release history, then either roll back to the last known-good revision or, if the state is genuinely inconsistent, remove the stuck release secret so Helm reconciles from the previous revision. Investigate why it was interrupted — most often a timeout on a hook or an unready resource.

Why is my values override being ignored?

Almost always a path mismatch — the key you are setting does not exist at that location in the chart's values structure, so Helm accepts it and nothing consumes it. Ask Helm for the computed values of the release and compare against what you intended. Silent acceptance of unknown keys is the trap.

How do I handle CRDs?

Carefully. Helm installs CRDs from the crds directory on first install but does not upgrade or delete them, which is deliberate — deleting a CRD deletes every object of that kind. Upgrade CRDs as an explicit step outside the normal release flow, and read the chart's upgrade notes, because this is where charts most often expect manual action.

Should I use Helm or Kustomize?

Helm when you are distributing software for others to install, because a versioned chart with values is what the ecosystem expects. Kustomize when the manifests are yours and you want them to stay readable YAML. Many teams use both — Helm to render a third-party chart, Kustomize to patch the result.