Install and CLI Fundamentals

Getting Helm installed and mastering the core lifecycle commands: install, upgrade, rollback, uninstall, list, history, status, and template.

Overview

The CLI in one picture

The Helm CLI is a single binary (helm) with around 59 subcommands. In practice, seven cover 90% of day-to-day work: install, upgrade, rollback, uninstall, list, history and template. Knowing exactly what each does to the cluster and to release state is the prerequisite for using Helm confidently.

> [!IMPORTANT] Every install, upgrade and rollback creates or updates a Secret in the target namespace holding the complete state: chart metadata, rendered manifests, values and status.

Installing Helm

macOS — Homebrew: brew install helm
Linux — The official get-helm script
Windows — Chocolatey or winget

The binary has no daemon component. Helm 3 is fully client-side and talks to the Kubernetes API directly through your kubeconfig.

The core commands

helm install — Creates the chart's resources — New named release at revision 1
helm upgrade — Applies the changed manifests — Revision incremented
helm rollback — Restores an earlier revision's manifests — New revision recording the rollback
helm uninstall — Removes the resources — Release removed
helm list, helm history — None — Read only
helm template — None: renders to stdout — None

Two flags to internalize

--wait — Blocks until all resources are ready, not just submitted to the API
--atomic — Makes upgrades self-healing: automatic rollback on failure

> [!TIP] In CI, --atomic --timeout 5m is the standard production pattern. Without --wait, helm upgrade returns success before Pods are actually running.

helm template: the offline path

helm template never touches the cluster, so --atomic and --wait do not apply. It renders manifests to stdout, which makes it the GitOps-friendly pattern: render in CI, commit or diff the rendered YAML, then apply.

Key concepts

helm upgrade --install: The idempotent form: creates the release if absent, upgrades if present. The standard CI/CD pattern. Avoids the error "cannot re-use a name that is still in use" (install) or "release not found" (upgrade).
--atomic: Implies --wait. On upgrade failure or timeout, automatically runs helm rollback and returns exit code 1. Prevents a broken release from being left in FAILED state. Essential for production CI pipelines.
--wait: Blocks until all Deployment, StatefulSet, DaemonSet, Service, Pod, and PVC resources reach ready state. Default timeout is 5 minutes. Without it, Helm returns success as soon as the API accepts the resources, before Pods are running.
helm template: Renders chart templates to stdout without connecting to a cluster (except for --dry-run=server). Used for local inspection, CI diffing, GitOps rendered-manifest repos, and piping into validation tools like kubeval.
helm get manifest: Returns the exact rendered YAML that Helm last applied to the cluster for a release. Essential for debugging drift: compare this output with kubectl get -o yaml to detect out-of-band changes.
Values precedence (highest to lowest): --set flags > -f values files (rightmost wins) > values.yaml in the chart. Knowing this order prevents surprises when --set and -f conflict.

When to use it

First-time install of any chart: helm install -f values.yaml --namespace --create-namespace
Idempotent CI deploy: helm upgrade --install --atomic --wait --timeout 5m
Investigating a production release: helm history, helm get manifest, helm get values
Debugging a failing upgrade: helm status to see current state, helm get manifest to compare with running resources
GitOps-compatible rendering: helm template to stdout for diff or commit

Interview questions

What happens when helm upgrade fails mid-way through applying resources?
How does values precedence work in Helm, and how would you structure values for three environments?
Walk through how you would debug a stuck helm upgrade.
What is the difference between helm template and helm install --dry-run?
How do you list all Helm releases across all namespaces, and what permissions are required?