Right, let’s talk about Helm. You’ve probably already felt the pain of deploying a multi-resource application to Kubernetes by hand. You write a dozen YAML files, carefully stringing them together with kubectl apply -f, and you pray to the scheduler gods that nothing goes wrong. Then you need to update one config value. Cue the frantic grep and sed session, followed by another prayer. It’s a mess. Helm exists to fix this. It’s not just a templating engine; it’s a full-fledged package manager for your Kubernetes cluster, and it works by introducing a few key concepts you need to wrap your head around.

Charts: The Blueprint

Think of a Chart as the blueprint, the source code, the recipe. It’s a collection of files that describes a related set of Kubernetes resources, bundled together. A chart is what you develop, version control, and share.

Inside a chart, you’ll find a specific directory structure. The most important bits are:

  • Chart.yaml: The metadata file. This is where you define the chart’s name, version, and dependencies. Helm cares deeply about the version field here—it’s used for release management.
  • values.yaml: The configuration file. This is your chart’s public API. It provides the default configuration for your templates. The whole point is that users (or you, in a different environment) can override these values without having to edit the templates themselves.
  • templates/: This directory is where the magic (and the YAML) happens. It contains all your template files, which are just Kubernetes manifest files spiced up with Go template directives ({{ .Values.image.tag }}, {{ .Release.Name }}, etc.).

You can create a new chart from scratch to see this structure yourself:

helm create my-awesome-app
tree my-awesome-app

You’ll see the full scaffolding, including a sample deployment and service. It’s a great starting point, but don’t feel obligated to use all of it. I often delete the templates/test folder immediately. It’s a nice idea, but I’ve never seen it used effectively in the wild.

Releases: The Live Instance

If a Chart is the blueprint, a Release is the actual, running house you built from it. It’s a specific instance of a chart that has been deployed to the Kubernetes cluster using the helm install command.

This is the genius of Helm. You can install the same chart multiple times with different release names and different configurations, and they will coexist perfectly. Want two copies of your web app, one for staging and one for production? No problem.

# Installing the same chart, creating two distinct releases.
helm install my-staging-app ./my-chart --set environment=staging
helm install my-production-app ./my-chart --set environment=production

Each release gets its own unique name (like my-staging-app) and is tracked meticulously by Helm. This brings us to…

Revisions: The Time Machine

Every time you upgrade a release with helm upgrade, Helm doesn’t just overwrite the previous state. It creates a new Revision (a numbered snapshot) of that release. This is your undo button. It’s arguably one of Helm’s best features.

If you upgrade your release and everything immediately catches fire, you can roll back to the previous revision with terrifying simplicity:

# See the revision history for a release
helm history my-production-app

# Roll back to the previous version
helm rollback my-production-app 0

Why is this so much better than just using kubectl? Because Helm tracks the state of the entire set of resources as a single unit. Rolling back with kubectl means figuring out which of the 20 resources you just updated need to be reverted and to what state. Helm already knows. It just reapplies the entire previous set of manifests. Life-saving.

A word of warning: the history isn’t kept forever. By default, Helm only keeps the last 10 revisions. You can change this with the --history-max flag on install/upgrade, but you have to remember to set it. It’s a questionable design choice—this feels like it should be a cluster-wide configuration—but we work with what we have.

Repositories: The App Store

Finally, the Repository is where you share charts. It’s essentially a HTTP server that houses an index.yaml file and the packaged *.tgz chart files. The Helm CLI knows how to talk to these servers to find, download, and install charts.

Adding a repo is simple:

# Add the official Bitnami repo, a great source of production-quality charts
helm repo add bitnami https://charts.bitnami.com/bitnami

# Now you can search and install from it
helm search repo bitnami/nginx
helm install my-nginx bitnami/nginx --version 13.2.21

Notice I pinned a version there. Always, always pin your chart versions. @latest is a fantasy in the deployment world. Repositories let you leverage the work of others, but the real power is building your own internal repo (using tools like helm package and helm serve or a cloud-native solution like OCI registries) to share standardized applications across your entire organization. That’s when you go from just installing software to actually managing your platform.