Helm — what is the Kubernetes package manager?

What is Helm?

Helm is the package manager for Kubernetes^?Kubernetes: an open-source system for automatically deploying and managing containerized applications. Its job is to bundle a related set of cluster resources (Deployments, Services, ConfigMaps, Ingresses and more) into a single, versioned, distributable artifact called a chart, then install it, upgrade it and — when needed — roll it back in a cluster. The official project repository on GitHub states it plainly: "Helm is a tool for managing Charts. Charts are packages of pre-configured Kubernetes resources," adding "think of it like apt/yum/homebrew for Kubernetes."

An important distinction up front: Helm is not an AI model or a machine-learning platform. It is a developer and infrastructure tool — a layer on top of Kubernetes that plays three roles at once: a package manager (distributing ready-made applications), a templating engine (generating YAML^?YAML: a human-readable format for data and configuration files manifests from parameters), and a release manager (tracking successive versions of an installed application). Since version 3, Helm runs entirely client-side — as a command-line tool (CLI) that talks directly to the Kubernetes API.

Who is behind it?

Helm began in 2015 as a Deis project ("Helm Classic"), introduced at the inaugural KubeCon (project history). In June 2018 it joined the Cloud Native Computing Foundation (CNCF), and in April 2020 it reached "graduated" status — the foundation's highest maturity level (CNCF announcement). The key technical milestone was Helm 3, released in November 2019, which removed the server-side Tiller component and returned Helm to a client-only tool. Today the project is community-maintained, with core maintainers from Microsoft, Samsung SDS and IBM (Helm 3 announcement blog).

How does it work?

At the heart of Helm is a templating engine. A chart contains a templates/ directory with files that are not yet finished Kubernetes manifests but templates. When Helm evaluates a chart, it passes every file in that directory through the rendering engine. Templates are written in the Go template language, extended with about 50 add-on functions from the Sprig library plus a few Helm-specific functions — as confirmed by the charts documentation.

The mechanics are simple to describe: template directives are enclosed in double curly braces {{ }}, and inside them you can reference configuration values and built-in objects. For example, {{ .Release.Name }} injects the current release's name into a manifest — as the chart template guide explains. The values fed into templates come from the values.yaml file (defaults) and from parameters supplied at install time.

The result of rendering is complete YAML manifests, which Helm sends to the Kubernetes API. Each installation creates a release — a named instance of a chart running in a cluster. The same chart can be installed many times into one cluster, and each installation creates a separate release with its own name, as described in the architecture documentation. Subsequent helm upgrade and helm rollback operations create new revisions of the same release. Helm stores the history of these revisions, which is why reverting to a previous state is a single command.

From application code to running Pods

Helm does not work in a vacuum — it is one link in a chain that starts at application code and ends with running containers. Walking through that flow step by step shows clearly where Docker^?Docker: an open-source platform for packaging applications and their dependencies into portable container images's role ends and Helm's and Kubernetes' roles begin:

1. A developer commits a change to the application code.
2. The CI pipeline builds a Docker image and pushes it to an image registry with a specific tag (e.g. a version number or commit hash).
3. The Helm chart points to that image through a value in values.yaml (repository + tag) — usually the only place you change to ship a new version.
4. The helm upgrade --install command renders the templates into manifests and sends them to the Kubernetes API.
5. Kubernetes compares the desired state with the current one and creates or updates Deployment objects, which spin up new Pods^?Pods: the smallest deployable units in Kubernetes — one or more containers running together.
6. If the new version misbehaves, a single helm rollback restores the previous revision of the release.

The division of roles is clear: Docker builds the image, Helm describes and deploys what that image should become in the cluster, and Kubernetes maintains the desired state. Helm itself neither builds images nor runs containers — it wires the ready-made pieces into one repeatable deployment.

Helm in the CI/CD pipeline

Helm's biggest practical value is that one chart serves many environments. Instead of maintaining separate sets of YAML files for dev, staging and production, you swap only the values file (e.g. values-prod.yaml) and the template does the rest. Add release versioning and atomic rollback, and these three things solve the real pain of hand-managing manifests on every change.

In a classic CI/CD pipeline (the push model) a deployment comes down to a single command: after building the image, the pipeline runs helm upgrade --install with the values appropriate for the target environment. Same chart, different values, predictable result — no hand-gluing of manifests.

The alternative is the pull model, i.e. GitOps^?GitOps: an operational model where the desired state of the cluster is declared in a Git repository and automatically reconciled. Argo CD natively supports charts — it renders them via helm template and continuously ensures the cluster state matches what is described in the Git repository. Git becomes the source of truth, not manually typed commands.

Terraform, in turn, lets you treat a chart as a piece of infrastructure. The official helm provider installs and manages charts in the cluster as part of the same description that creates the cluster itself, so a single terraform apply can stand up a cluster and immediately deploy the baseline applications onto it.

What are its key components?

A chart has a strictly defined directory structure, documented in the official docs:

mychart/            # the chart directory
├── Chart.yaml      # metadata: name, version, dependencies
├── values.yaml     # default configuration values
├── templates/      # templates → K8s manifests     [reserved]
│   ├── deployment.yaml
│   ├── service.yaml
│   └── _helpers.tpl
├── charts/         # subcharts = dependencies       [reserved]
│   └── postgresql/ # example dependency
└── crds/           # Custom Resource Definitions    [reserved]

• Chart.yaml — the mandatory metadata file: name, chart version, application version, dependencies.
• values.yaml — the default configuration values, which a user can override at install time.
• templates/ — templates that, when combined with values, produce valid Kubernetes manifests.
• charts/ — a directory for dependencies, i.e. subcharts (a chart can depend on other charts, e.g. an app on a database).
• crds/ — Custom Resource Definitions.

The templates/, charts/ and crds/ directories are reserved by Helm. Beyond the single chart, there are two distribution mechanisms: chart repositories (HTTP servers with a chart index) and — in newer versions — OCI registries^?OCI registries: repositories following the Open Container Initiative standard — the same one used for container images, which let you store charts in the same infrastructure as container images. Helm also offers a hook mechanism — ordinary Kubernetes manifests marked with a special helm.sh/hook annotation that let you intervene at specific points in a release's lifecycle (e.g. take a backup before an upgrade, or run an initialization job before the application starts).

How does it differ from other approaches?

The most common comparison is Helm versus Kustomize — the trade-offs are summarized well in Baeldung's comparison, while typed-configuration projects such as Timoni (based on the CUE language) show an alternative approach. Here are the main options alongside Helm:

Kustomize is built into kubectl and is often simpler for small changes, while Operators and Terraform solve problems other than one-off deployment — which is why they more often complement Helm than replace it.

Key limitations and challenges

The biggest criticism concerns the text-templating model: Helm operates on strings rather than typed structures, so a mistake in a template easily yields invalid YAML that surfaces only at render time. This weakness is precisely what drives alternatives like Timoni.

Another challenge is complexity at scale: large charts with many subcharts and nested values can be hard to maintain and debug. Helm does provide helm lint and helm test, along with a set of best practices, but testing template logic remains labor-intensive. It is also worth remembering that some of the details here (exact dates, revision mechanics) come from the project's primary sources, but Helm evolves quickly — for production work, always check the current documentation.

Why does it matter?

Helm has taken the place in the Kubernetes ecosystem that apt or homebrew hold in operating systems — it became the default way to distribute and install software in clusters. Its significance stems less from technical elegance (the text-templating model is often criticized) than from a network effect: since most popular applications are published as charts, and CI/CD and GitOps tooling "speaks Helm," knowing Helm is practically a prerequisite for working efficiently with Kubernetes.

Equally important is the lesson the project's evolution carries. Removing the server-side Tiller component in Helm 3 showed that simplifying architecture and moving permission control to a standard Kubernetes mechanism (the kubeconfig^?kubeconfig: a file holding a user's access credentials and permissions for a Kubernetes cluster file) can solve real security problems. For someone learning DevOps, Helm is therefore doubly valuable: as an everyday tool and as a case study of how an open-source project matures under a large foundation.

Helm is not a universal solution — for simple cases Kustomize or plain YAML will do, and advocates of typed configuration will reach for newer tools. It remains, however, the most widely encountered package manager for Kubernetes, and its concepts — chart, release, values, revision — have become part of the shared vocabulary of the entire ecosystem.

Sources

• Helm — official charts documentation — link
• Helm — architecture and concepts (release) — link
• Helm — project history (Deis, Tiller) — link
• Helm — blog: Helm 3 released — link
• CNCF — Helm graduation announcement — link
• GitHub — helm/helm (tool definition) — link
• Argo CD — Helm chart support — link
• HashiCorp — Terraform Helm provider — link
• Baeldung — Helm vs Kustomize — link