Once a chart exists, day-to-day work with Helm is almost entirely about managing releases: installing them, upgrading them as the chart or its values change, and occasionally rolling one back. This guide covers that lifecycle end to end.

The core commands

Command	What it does
helm install NAME CHART	Creates a new release from a chart.
helm upgrade NAME CHART	Applies changes to an existing release.
helm upgrade --install NAME CHART	Installs if the release doesn’t exist yet, upgrades if it does.
helm list	Lists releases in the current namespace (-A for every namespace).
helm status NAME	Shows a release’s current state and its NOTES.txt again.
helm rollback NAME REVISION	Reverts a release to a previous revision.
helm uninstall NAME	Removes a release and its resources.

helm upgrade --install is worth calling out on its own: it’s the pattern almost every CI/CD pipeline actually uses, because it means “make sure this release exists with this configuration” without the script needing to know or check whether it’s a first deploy or the hundredth.

Every change is a numbered revision

helm install web ./webapp
helm list

A fresh install is revision 1. Each subsequent upgrade adds the next number, and rollback adds a number too, since a rollback isn’t a time machine, it’s a new revision whose content happens to match an older one:

Operation	Resulting revision
helm install	1
helm upgrade	2
helm upgrade	3
helm rollback web 1	4 (content matches revision 1, but the number keeps climbing)

helm history web

lists every revision with its status, chart version, and app version, which is what rollback and the inspection commands below read from.

Roll back when an upgrade goes wrong

helm rollback web 2
kubectl rollout status deployment/web

Rolling back to a specific revision number is the usual case. helm rollback web with no number reverts to the immediately previous one. Because rollback creates a new revision, rolling back and then rolling back again gets you back to where you started, it doesn’t undo the rollback itself; check helm history to be sure which revision you’re actually reverting to.

Inspect a release without changing it

helm status web
helm get values web
helm get manifest web
helm diff upgrade web ./webapp -f values-prod.yaml   # requires the helm-diff plugin

get values shows what was actually supplied for this release, useful when a running release doesn’t match what a values file on disk suggests. get manifest shows the exact Kubernetes YAML Helm applied, after templating, which is the ground truth when you’re debugging a discrepancy between the chart source and what’s live. helm diff isn’t built in, it’s a widely used community plugin (helm plugin install https://github.com/databus23/helm-diff), and it’s worth having before you run an upgrade you’re unsure about, since it shows exactly what would change without applying anything.

Uninstall, and keep or discard history

helm uninstall web
helm uninstall web --keep-history

By default, uninstalling removes both the release’s resources and its history. --keep-history removes the resources but keeps the release’s record, so helm history web and helm rollback still work afterward, in case you need to reinstate it or just want an audit trail of what used to run. helm list won’t show an uninstalled release even with --keep-history unless you add -a/--all.

What changed in Helm 4

If you’re using Helm 4, note one behavior difference: new installs default to Kubernetes’ server-side apply rather than the client-side apply Helm 3 used, which handles field ownership and conflicts between tools more predictably. Upgrades and rollbacks of a release created under Helm 3 keep using client-side apply unless you pass --server-side explicitly, so mixed-version workflows won’t suddenly change behavior underneath you. This doesn’t change any of the commands above, only how the resulting manifest gets applied.