Why Helm

The kubectl-sprawl problem and the package management gap Helm fills. Positions Helm against raw manifests, Kustomize, and Terraform.

Overview

Why Helm exists

Helm is the package manager for Kubernetes, a CNCF graduated project maintained by the Helm core team. It solves what practitioners call "kubectl sprawl": the explosion of disconnected YAML files that builds up when you deploy a real application to Kubernetes without any abstraction layer.

> [!IMPORTANT] Without Helm there is no answer to "what exact set of manifests is running in prod right now?" beyond "whatever was last applied, probably."

The sprawl problem

A production workload needs many objects: Deployment, Service, ConfigMap, Secret, HorizontalPodAutoscaler, PodDisruptionBudget, ServiceAccount, NetworkPolicy, Ingress or HTTPRoute. Multiply by environments and services and you quickly have hundreds of files.

Helm's four primitives

Charts — Versioned packages of manifests
Releases — Named, tracked deployments of a chart
Templates — Go template engine that renders YAML from one source of truth plus environment-specific values
Lifecycle commands — install, upgrade, rollback, history, uninstall, with ordered hooks at each phase

Where Helm sits

Helm is complementary to, not competitive with, the other tools in the stack.

Terraform — Infrastructure
Argo CD, Flux — Reconciling desired state from Git
Kustomize — Overlays on plain manifests, no templating
Helm — Packaging, templating and release management

> [!TIP] The 2026 production consensus: Helm for third-party software distribution, Kustomize for your own app overlays, Argo CD or Flux as the GitOps controller that renders either.

Helm 4

Helm 4 (released November 2025 at KubeCon NA, stable at 4.2.2) introduced server-side apply, which changes how field ownership works, and kept Secrets-based release storage.

> [!NOTE] Helm 3 remains widely deployed; the Helm 3 to 4 migration is covered in its own topic.

Key concepts

Chart: A directory (or .tgz archive) containing Chart.yaml, values.yaml, templates/, and optional charts/ (dependencies). The versionable, distributable unit in Helm. Charts are typed: application (installs workloads) or library (provides reusable helpers only).
Release: A named, running instance of a chart in a cluster. Each helm install creates a release. Each helm upgrade creates a new revision of the same release. Helm stores release state as Kubernetes Secrets in the target namespace.
Values: The configuration layer. Chart ships with values.yaml defaults. At install time, users supply overrides via -f myvals.yaml files and --set key=value flags. Templates render against the merged values object.
Revision: An integer counter incremented on every install or upgrade. helm rollback my-app 3 restores the exact manifests from revision 3. helm history my-app shows all revisions with timestamps, status, and chart version.
Hook: A Kubernetes resource (usually a Job) annotated with helm.sh/hook to run at a specific lifecycle phase: pre-install, post-install, pre-upgrade, post-upgrade, pre-delete, post-delete, pre-rollback, post-rollback, test. The canonical use case is a pre-upgrade DB migration Job.
Kubectl sprawl: The anti-pattern of managing dozens of disconnected, unversioned YAML files across environments with no release model, no diff history, and no rollback primitive. The primary problem Helm was designed to solve.

When to use it

Deploying third-party software onto Kubernetes (cert-manager, ingress-nginx, prometheus-stack all distribute as Helm charts)
Building a platform product that other teams install — Helm charts are the standard distribution format
Any application needing rollback history, ordered lifecycle hooks, or release tracking
Multi-environment deployments where the only difference is configuration values, not manifest structure

Interview questions

Explain the difference between a Helm chart, a Helm release, and a Helm revision.
How does Helm compare to Kustomize and when would you use each?
Where does Helm store release state in the cluster, and why does it matter?
How does Helm fit into a GitOps workflow?