Why Helm: The Case for a Kubernetes Package Manager

If you have ever copy-pasted a folder of Kubernetes YAML, search-and-replaced the environment name, and then realised you missed one — congratulations, you have discovered the problem Helm solves.

The Problem with Plain YAML

A non-trivial Kubernetes application is rarely a single manifest. A typical web service ships with:

• A Deployment and Service
• A ConfigMap and one or more Secrets
• An Ingress (or HTTPRoute)
• A ServiceAccount, Role, and RoleBinding
• A HorizontalPodAutoscaler and PodDisruptionBudget
• A NetworkPolicy
• Possibly a CronJob, a queue worker Deployment, and a database StatefulSet

That is ten to twenty YAML documents per service, and most of them differ subtly between dev, staging, and prod: replica counts, image tags, resource limits, hostnames, secrets references. Multiply by a dozen services and the spreadsheet of "what is deployed where" becomes the most important — and most fragile — artefact in the company.

Teams typically reach for one of three solutions:

1. Templating — Helm, Jsonnet, cdk8s
2. Overlay patching — Kustomize
3. Operators — custom controllers that own the lifecycle

Helm is the most widely adopted of these by a large margin: the CNCF 2024 annual survey reported Helm in use at over 80% of organisations running Kubernetes. Most cloud-native vendors publish a Helm chart as the official install path.

What Helm Gives You

Two Vocabulary Words You Cannot Confuse

• Chart — the package. A directory (or .tgz) containing templates, values, metadata. Reusable.
• Release — an installation of a chart into a cluster with a specific name and values. You can install the same chart many times (e.g., frontend-eu, frontend-us) — each is a separate release.

Releases are tracked in the cluster itself, as Kubernetes secrets in the release namespace (or configmaps for very old installs). This is the headline change from Helm 2 to Helm 3 — there is no server-side Tiller component; the client talks directly to the Kubernetes API.

Helm 3 vs Helm 2

You will still see references to Helm 2 in old documentation. Important differences:

• No Tiller. Helm 3 runs entirely client-side using your kubeconfig credentials. RBAC is whatever your user has, not what a privileged Tiller had.
• Three-way strategic merge. Upgrades consider the live state, the previous release, and the new manifests. Out-of-band edits are detected.
• OCI support. Charts can be pushed and pulled from any OCI registry — Docker Hub, GHCR, ECR, Artifact Registry, Harbor.
• JSON schema validation on values.yaml.
• Library charts — reusable template fragments published as charts.

Helm 2 reached end of life in November 2020. If you encounter it, plan migration via helm-2to3.

Where Helm Sits in the Modern Stack

Helm is not the only word in the conversation. Most production teams use it alongside:

• GitOps controllers (Argo CD, Flux) — these read your Helm charts from Git and reconcile them into the cluster, replacing the imperative helm install step.
• Helmfile / helm-secrets / SOPS — declarative orchestration of multiple releases and encrypted values files.
• Kustomize — used either instead of Helm (for first-party apps) or after Helm renders (to patch vendor charts).

Knowing Helm is non-optional for anyone running production Kubernetes. Knowing where it stops being the right tool is what makes you a senior engineer.

What You Will Build in This Course

Over the next seven lessons we will build a chart for a small web application from scratch, version it, publish it to an OCI registry, parameterise it for three environments, and finally compare the same problem solved with Kustomize. By the end you will be able to read any third-party Helm chart confidently and write one that is fit for production.