Helm — The Package Manager for Kubernetes

You've hand-written Deployments, Services, ConfigMaps, PVCs, Ingress rules, and RBAC objects. Now imagine doing that for one real application, times three environments, every single time you deploy. There's a better way — and you already know the pattern. You've been using it since your first day on Linux.

The problem: one app, many YAML files, many environments

A real application is almost never just one Deployment. It needs a Service to expose it, a ConfigMap for its settings, maybe a PVC for storage, an Ingress rule to route traffic in, and a ServiceAccount with RBAC rules so it can talk to the API server safely. That's five or six files, all working together as one unit. You wrote every one of them by hand in earlier posts — that was the right way to learn what each piece does.

Now multiply that by real life. Dev needs 1 replica and small resource limits. Staging needs 2 replicas and a staging image tag. Prod needs 5 replicas, higher limits, and a different Ingress host. Copy-pasting that bundle three times and hand-editing the differences works fine for a week. Then someone forgets to bump the prod replica count, or fixes staging's Service without touching prod's copy, and your environments quietly drift apart. Hand-copying YAML doesn't scale.

Helm: apt/yum, but for Kubernetes

You already solved a version of this problem on plain Linux. A package manager is a tool that installs software for you — it fetches the right files, wires them together, and gives you an easy way to upgrade or remove things later. You didn't download source code, compile it, and hunt down dependencies by hand. You ran apt install nginx or yum install nginx and let the package manager do the work. Helm is that same idea, aimed at Kubernetes objects instead of system binaries.

Chart: the package itself

A Helm Chart is a bundle of files. It has a templates/ folder holding templated versions of the YAML you already know how to write — Deployment, Service, ConfigMap, and so on. It has a values.yaml file holding the default settings for all those templates. And it has a Chart.yaml file with metadata, like the chart's name and version. Someone — Bitnami, a project's maintainers, or you — writes the Chart once. You install it as many times as you need, with different settings each time.

Templating: how one chart becomes dev, staging, and prod

Templating means a file has placeholders instead of fixed values, and something fills those placeholders in later. Open a Chart's template file, and instead of a hardcoded replicas: 3, you'll see something like replicas: {{ .Values.replicaCount }}. That {{ }} is the placeholder. At install time, Helm fills every one of them, in every template, with the matching value from values.yaml — or from any override you pass on the command line. Same Chart, same templates, same structure. Different values in, different final YAML out. One Chart, three environments, zero copy-pasting.

Release: an installed instance, with its own name

When you run helm install, you're not just applying YAML — you're creating a Release, a named, tracked instance of a Chart running in your cluster. You can install the same Chart multiple times under different release names with different values, say my-nginx-dev and my-nginx-staging, and Helm keeps them separate, each with its own history. That history is what makes helm upgrade and helm rollback possible. Rolling back isn't "figure out what the old YAML looked like" — it's "go back to revision 1."

Repository: where charts come from

A Repository is a hosted collection of packaged Charts — the Kubernetes equivalent of an apt or yum package registry. The best-known public one is Bitnami's, which publishes solid, well-maintained Charts for databases, message queues, and monitoring stacks. That's infrastructure that would otherwise take you days to hand-write and get right: replication, health checks, security defaults, and all the fiddly details. helm repo add is how you point your local Helm client at one of these sources.

Hands-on: install, upgrade, rollback, uninstall

Add the Bitnami repo and refresh your local index of what's available:

$ helm repo add bitnami https://charts.bitnami.com/bitnami
"bitnami" has been added to your repositories

$ helm repo update
Hang tight while we grab the latest from your chart repositories...
...Successfully got an update from the "bitnami" chart repository
Update Complete. ⎈ Happy Helming!⎈

Search the repo for a chart, the same way you'd search apt's package index:

$ helm search repo nginx
NAME                    CHART VERSION   APP VERSION   DESCRIPTION
bitnami/nginx           15.5.2          1.25.3        NGINX Open Source web server
bitnami/nginx-ingress-controller  9.3.1  1.9.4         NGINX Ingress controller

Install it as a named release:

$ helm install my-nginx bitnami/nginx
NAME: my-nginx
LAST DEPLOYED: Thu Sep  3 09:12:04 2026
NAMESPACE: default
STATUS: deployed
REVISION: 1

List what's running:

$ helm list
NAME       NAMESPACE  REVISION  STATUS    CHART        APP VERSION
my-nginx   default    1         deployed  nginx-15.5.2 1.25.3

Change a value — this is the templating in action, overriding values.yaml's default replica count from the command line:

$ helm upgrade my-nginx bitnami/nginx --set replicaCount=3
Release "my-nginx" has been upgraded. Happy Helming!
REVISION: 2

Not happy with revision 2? Go back:

$ helm rollback my-nginx 1
Rollback was a success! Happy Helming!

And when you're done with it entirely:

$ helm uninstall my-nginx
release "my-nginx" uninstalled

Before installing anything, it's worth seeing exactly what knobs a chart exposes — this is the best way to figure out what actually goes in a values override:

$ helm show values bitnami/nginx | head
## @param replicaCount Number of nginx replicas to deploy
replicaCount: 1

## @param image.registry nginx image registry
image:
  registry: docker.io
  repository: bitnami/nginx
  tag: 1.25.3-debian-12-r0

Where Helm fits with what you already know

Helm doesn't replace kubectl or raw YAML — it generates the exact same YAML you've been hand-writing, then applies it for you and tracks the result as a release. That's the whole value: less repetition, consistent structure across environments, and an upgrade/rollback history instead of hoping someone kept a backup of the old manifest.

Next up: StatefulSets, Jobs & CronJobs — running the workloads that don't fit the stateless, run-forever Deployment model.