Right, let’s get our hands dirty with the four commands you’ll use so often they’ll become muscle memory: install, upgrade, rollback, and uninstall. This isn’t just about slinging YAML at a cluster; it’s about managing the lifecycle of your application with something a bit more sophisticated than frantic kubectl patches.

Think of a Helm chart as a blueprint and helm install as the construction crew. But you don’t just point them at the blueprint and walk away. You give them a set of parameters—--values or --set—to customize what they build. This is Helm’s superpower: taking a single, well-defined chart and deploying it a hundred different ways without touching the source code.

Let’s install a straightforward nginx chart from the Bitnami repository. First, we add the repo (consider this a one-time setup).

helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update

Now, the simplest form of install just gives the release a name and points to the chart. A “release” is the key concept here—it’s a specific instance of a chart running in your cluster. You have to name it. --generate-name is a gift for quick tests, but for anything real, you pick a meaningful name.

# Quick and dirty test (Helm names it for you)
helm install my-test-release bitnami/nginx --generate-name

# The right way: named and with custom configuration
helm install my-nginx bitnami/nginx --set service.type=LoadBalancer

install: The Art of the First Deployment

The most common pitfall here is just assuming the default values are what you want. They almost never are. Always, and I mean always, inspect the chart’s default values first. You do this with helm show values. This saves you from the dreaded “oh, it installed a ClusterIP service and I can’t access it” moment.

helm show values bitnami/nginx > values.yaml
# Now edit values.yaml to your heart's content
vim values.yaml

# Then install with your custom values file
helm install my-nginx bitnami/nginx -f values.yaml

Why -f values.yaml over --set? For anything beyond a one-off tweak, the values file is king. It’s version-controllable, readable, and far less error-prone than trying to quote and escape a labyrinth of --set commands. Use --set for quick overrides on the fly, but the file is your source of truth.

upgrade: Changing the Tires on a Moving Car

So your app is running. Now you need to change something. Maybe you need to scale up, change a config, or deploy a new version of the chart itself. This is where helm upgrade comes in.

# Upgrade our release using the edited values file
helm upgrade my-nginx bitnami/nginx -f values.yaml --set replicaCount=3

See what I did there? I used both -f for the bulk of my config and --set for a quick, immediate override. Helm merges these in a logical order: values files first, then --set overrides, with the latter winning any conflicts.

Here’s the critical best practice: always use --atomic on upgrades. This flag is a lifesaver. It means if the upgrade fails, Helm will automatically roll it back for you. Without it, you can be left in a half-baked, broken state that’s a nightmare to debug.

# The right way to upgrade. Seriously, never skip --atomic.
helm upgrade my-nginx bitnami/nginx -f values.yaml --atomic

rollback: Your “Oh, Crap” Button

Let’s say you ran an upgrade without --atomic (you didn’t listen) and now your release is broken. Panic? No. You use helm rollback. Helm keeps a revision history of every install and upgrade (like a version control system for your releases), and rolling back is trivial.

First, see what revisions you have:

helm history my-nginx

Then, roll back to the last known good version (revision 4, in this case):

helm rollback my-nginx 4

This command is brilliantly simple. It doesn’t delete the bad revision; it simply takes the state of revision 4 and performs a new upgrade (creating revision 5) to re-apply that known-good configuration. Your history remains intact for forensic purposes.

uninstall: The Final Option

This one does what it says on the tin. It deletes the release from your cluster.

helm uninstall my-nginx

The crucial thing to understand here is what doesn’t get deleted. If you created persistent volumes, Helm (by default) won’t touch them. This is generally good—you don’t want your database’s data vanishing because you uninstalled a release. But it’s also a common source of “why can’t I reinstall this?” problems. If you do want to nuke everything, you have to go manually clean up those PVCs afterwards. Helm gives you control, but with that comes the responsibility to actually clean up your room.