The Everyday Loop: Install, Upgrade, Rollback

You understand the three ideas now: chart, values, release. This phase is the muscle memory — the handful of commands you'll actually run, in the order you'll run them. None of them is complicated. The skill is knowing which one to reach for and what it does to your release history.

Scaffold a chart

You rarely write a chart from a blank file. helm create gives you a working starter chart you trim down:

$ helm create myapp
Creating myapp

$ ls myapp
Chart.yaml  charts  templates  values.yaml

What just happened: Helm generated the standard chart layout from the last phase, pre-filled with a sample Deployment, Service, and a sensible values.yaml. The generated chart is more than most apps need — treat it as a starting point to delete from, not a sacred template. Open templates/deployment.yaml and you'll see the same {{ .Values.* }} placeholders you already understand.

Render before you ship: helm template

Before sending anything to a cluster, see what Helm will actually produce. helm template renders the chart locally and prints the final YAML — no cluster involved:

$ helm template myapp ./myapp
---
# Source: myapp/templates/service.yaml
apiVersion: v1
kind: Service
metadata:
  name: myapp
...
---
# Source: myapp/templates/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  replicas: 1
...

What just happened: Helm filled in every placeholder using the defaults in values.yaml and printed the manifests it would send to Kubernetes — the placeholders are gone, replaced by real values. This is your read-before-you-commit step. If the output looks wrong here, it'll be wrong in the cluster. Get in the habit of running this whenever you change a template.

Install: create a release

helm install renders the chart and applies it to your cluster, recording the result as a named release:

$ helm install web ./myapp
NAME: web
LAST DEPLOYED: Mon Jun 30 09:14:02 2026
NAMESPACE: default
STATUS: deployed
REVISION: 1

What just happened: web is the release name you chose — every command from here on refers to this release by that name. REVISION: 1 is the key line: this is the first version of the release. Helm rendered the templates with the default values, sent the manifests to the cluster, and stored revision 1 in its history.

To install the same chart with different settings, point Helm at a values file or override individual keys on the command line:

$ helm install web-prod ./myapp -f values-prod.yaml --set image.tag=1.4.1

What just happened: -f values-prod.yaml layers a prod-specific values file on top of the chart's defaults; --set image.tag=1.4.1 overrides one key inline. This is the per-environment story in action: same chart, different values, different release name. Values from -f and --set win over the chart's values.yaml, and --set wins over -f — later sources override earlier ones.

Keep one values file per environment (values-dev.yaml, values-prod.yaml) checked into git. Reserve --set for one-off overrides and CI-injected values like the image tag. A --set that should have been permanent is a value you'll forget you applied.

See what's running

Two commands answer "what's deployed and is it healthy":

$ helm list
NAME      NAMESPACE  REVISION  STATUS    CHART        APP VERSION
web       default    1         deployed  myapp-0.1.0  1.16.0
web-prod  default    1         deployed  myapp-0.1.0  1.4.1

$ helm status web
NAME: web
STATUS: deployed
REVISION: 1

What just happened: helm list shows every release in the namespace with its current revision and status — your inventory of what Helm manages. helm status web zooms into one release. If a release ever shows a status other than deployed (like failed or pending-upgrade), that's your signal something went sideways during the last operation.

Upgrade: change a release

When you ship a new image tag or tweak a value, you helm upgrade the existing release — you do not install again:

$ helm upgrade web ./myapp --set image.tag=1.4.1
NAME: web
STATUS: deployed
REVISION: 2

What just happened: Helm re-rendered the chart with the new tag and applied the diff to the cluster. The crucial detail is REVISION: 2 — Helm bumped the revision and kept revision 1 in history. Upgrade is the workhorse: nearly every deploy after the first is an upgrade.

A safer habit is helm upgrade --install (often written helm upgrade -i):

$ helm upgrade --install web ./myapp --set image.tag=1.4.1

What just happened: This upgrades the release if it exists, or installs it if it doesn't. It's the standard command in CI pipelines because it works whether or not the release is already there — no need to branch on "first deploy versus later deploy." One command for both cases.

Inspect history and roll back

Helm keeps the revision history, and that history is what makes rollback trivial:

$ helm history web
REVISION  STATUS      CHART        APP VERSION  DESCRIPTION
1         superseded  myapp-0.1.0  1.16.0       Install complete
2         deployed    myapp-0.1.0  1.4.1        Upgrade complete

What just happened: superseded means an older revision that's been replaced; deployed is the live one. This is the audit trail — you can see exactly what each revision was and when it landed.

Now suppose revision 2 is broken. You don't dig through git or hand-edit YAML under pressure. You roll back:

$ helm rollback web 1
Rollback was a success! Happy Helming!

$ helm history web
REVISION  STATUS      CHART        APP VERSION  DESCRIPTION
1         superseded  myapp-0.1.0  1.16.0       Install complete
2         superseded  myapp-0.1.0  1.4.1        Upgrade complete
3         deployed    myapp-0.1.0  1.16.0       Rollback to 1

What just happened: helm rollback web 1 re-applied the exact state of revision 1 — and recorded it as a new revision 3. Notice rollback doesn't delete history or rewind the counter; it moves forward to a state identical to a past one. Run helm rollback web with no number and it goes to the immediately previous revision. This is the payoff of the release model: recovery is one command, and the trail stays intact.

Tear down

When you're done with a release, remove it and everything it created:

$ helm uninstall web
release "web" uninstalled

What just happened: Helm deleted every resource it created for the web release — the Deployment, Service, and so on — in one shot. No hunting down individual objects with kubectl delete. Because Helm tracked exactly what it installed, it knows exactly what to remove.

That's the full daily loop: create to scaffold, template to preview, install for the first deploy, upgrade (or upgrade --install) for every change, history and rollback when something breaks, uninstall to clean up. Six commands cover almost everything you'll do.

In the wild: most teams never run helm install by hand after the first day. CI runs helm upgrade --install on every merge, with the image tag injected via --set. Humans mostly run helm list, helm history, and the occasional helm rollback when a deploy goes wrong.

[
  {
    "q": "You changed the image tag and want to apply it to an already-running release. Which command?",
    "choices": [
      "helm install web ./myapp",
      "helm upgrade web ./myapp",
      "helm create web",
      "helm template web ./myapp"
    ],
    "answer": 1,
    "explain": "Existing releases are changed with helm upgrade, which bumps the revision and keeps history. Re-running install would error because the release already exists."
  },
  {
    "q": "What does 'helm rollback web 1' do to the revision history?",
    "choices": [
      "Deletes revisions 2 and 3 and rewinds to revision 1",
      "Edits revision 1 in place",
      "Re-applies revision 1's state and records it as a new revision",
      "Uninstalls the release entirely"
    ],
    "answer": 2,
    "explain": "Rollback moves forward: it creates a new revision identical to the target, preserving the full history rather than rewinding the counter."
  },
  {
    "q": "Why is 'helm upgrade --install' the common choice in CI pipelines?",
    "choices": [
      "It skips the cluster and only renders locally",
      "It installs if the release is absent and upgrades if it exists, so one command handles both",
      "It deletes the release before reinstalling",
      "It is the only command that accepts --set"
    ],
    "answer": 1,
    "explain": "The flag makes the command idempotent across first-deploy and later-deploy, so the pipeline needs no special-casing."
  }
]

← Phase 1: The Mental Model | Overview | Phase 3: Where It Bites: Templating Gotchas and When Not to Use Helm →