Helm: The Package Manager for Kubernetes

What Helm is

Helm is the package manager for Kubernetes. It manages charts, which the README defines as packages of pre-configured Kubernetes resources, and the project's own shorthand is "apt/yum/homebrew for Kubernetes". With Helm you can find and use popular software packaged as charts, share your own applications as charts, create reproducible builds of Kubernetes applications, manage your manifest files and manage releases of those packages over time.

It is aimed at anyone shipping software to Kubernetes: application teams packaging their services, platform teams standardising deployments, and vendors distributing installable software. Helm is written in Go and licensed under Apache-2.0. Helm v4 is the current stable line, developed on the main branch, while Helm v3 is in support mode on the dev-v3 branch. Community channels include several Kubernetes Slack channels, a CNCF-hosted mailing list and a weekly developer call.

How it works

Helm is a client-side tool. The README explains that it renders your templates and communicates with the Kubernetes API, and that it runs wherever you want: your laptop, CI/CD, or anywhere else. A chart contains at least two things: a description of the package in Chart.yaml, and one or more templates containing Kubernetes manifest files. Charts can be stored on disk or fetched from remote chart repositories, much like Debian or Red Hat packages, and they can also be installed straight from OCI-compliant container registries using the oci:// prefix.

Installing a chart creates a release. Helm tracks releases and their revision history, which is what lets you list what is deployed, check status, upgrade, roll back and uninstall. The quickstart notes that with --keep-history, Helm keeps a release's history even after it is uninstalled, so you can audit a cluster's history and even restore a release with helm rollback. The Using Helm guide documents the fixed order in which Helm installs resource kinds, starting with namespaces, network policies and quotas and ending with admission webhook configurations, and points out that Helm does not wait until all resources are running before it exits.

What changed in Helm 4

The Helm 4 overview describes v4 as a significant evolution from v3 that introduces breaking changes and new architectural patterns while keeping backwards compatibility for charts. The main points from the documentation:

• Redesigned plugin system: an optional WebAssembly-based runtime for enhanced security, launching with three plugin types (CLI, getter and post-renderer plugins). Existing plugins continue to work.
• Server-side apply by default for new releases. Upgrades and rollbacks follow the release's previous apply method, so releases created by Helm 3 keep client-side apply unless --server-side is set explicitly.
• kstatus integration that shows more detailed status for deployed resources.
• Install by OCI digest: charts whose digest does not match are not installed, which the docs present as a supply-chain security improvement.
• Multi-document values, so complex values can be split across several YAML documents, and custom template functions supplied by plugins.
• A stable SDK API for using Helm as a Go library.
• Charts v3, in early development and gated behind an environment variable; v2 charts continue to work unchanged.
• Renamed flags: --atomic becomes --rollback-on-failure and --force becomes --force-replace. The old names still work but print deprecation warnings.

Key features

• Chart discovery: helm search hub searches Artifact Hub, and helm search repo searches the repositories you have added locally, using fuzzy matching over local data with no public network connection needed.
• Multiple chart sources: traditional chart repositories added with helm repo add, OCI registries such as GitHub Container Registry or Docker Hub, and charts on local disk.
• Templated manifests: charts parameterise Kubernetes YAML so a single chart can be installed with different values in different environments.
• Release lifecycle commands: helm list, helm status, helm rollback and helm uninstall manage what is deployed.
• Chart preview: helm show chart displays a chart's metadata before you install it.
• Broad install options: release binaries plus Homebrew, Chocolatey, Winget, Scoop, Snapcraft, Flox and mise.

Getting started

You need a Kubernetes cluster and a locally configured kubectl. Install the Helm client, for example with Homebrew:

brew install helm

Search Artifact Hub for a chart:

helm search hub podinfo

Install a chart directly from an OCI registry, without adding a repository first:

helm install my-podinfo oci://ghcr.io/stefanprodan/charts/podinfo --version 6.11.2

List releases, then uninstall the release, which removes its resources and release history:

helm list
helm uninstall my-podinfo

To experiment with the new chart format in Helm 4, enable it and create a chart with the v3 API version:

export HELM_EXPERIMENTAL_CHART_V3=1
helm create --chart-api-version=v3 mychart

Use cases

• Installing third-party software such as databases, ingress controllers or monitoring stacks from published charts.
• Packaging internal services as charts so every team deploys the same way across development, staging and production.
• Distributing software to customers who run Kubernetes, through a chart repository or an OCI registry.
• CI/CD pipelines that install or upgrade charts as a deployment step.
• Recoverable rollouts that rely on release history and helm rollback when an upgrade misbehaves.

How it compares

The README frames Helm by analogy with operating-system package managers such as apt, yum and Homebrew rather than against other Kubernetes tools. In practice, teams usually weigh it against applying plain manifests with kubectl, which avoids templating but provides no release tracking or rollback, and against overlay-based tools such as Kustomize, which patch YAML instead of templating it. Helm's distinguishing points are the packaging format itself, the large catalogue of published charts on Artifact Hub, and release history with rollback built in.

Things to know before adopting

• Licence: Apache-2.0.
• Helm 3 end of support: v3 bug fixes ended on July 8, 2026, and security fixes end on November 11, 2026. Teams still on v3 should plan their move to v4.
• Breaking changes in v4: post-renderers must now be plugins, so passing an executable directly to --post-renderer no longer works; helm registry login accepts only the domain name, not a full URL; and automation that uses --atomic or --force should switch to the renamed flags.
• Apply-method latching: new releases default to server-side apply while existing v3 releases keep client-side apply. The docs suggest testing in environments where operators or other controllers manage the same resources.
• Charts v3 is experimental: the docs warn that features might change or be removed before the final release and that it is for testing and feedback only.
• Version skew: the quickstart recommends the latest stable Kubernetes release and points to Helm's version support policy for the maximum supported skew between Helm and Kubernetes.
• Third-party charts: Artifact Hub aggregates charts from hundreds of repositories and shows security information; previewing a chart with helm show chart before installing is cheap.

Project activity

As of October 2026 the helm/helm repository has about 30,400 stars. It was created in October 2015, is written in Go and is licensed under Apache-2.0. The latest release is v4.3.1, published on October 15, 2026, and the Helm 4 changelog covers 571 pull requests compared with v3.19.0. The roadmap is tracked with GitHub milestones. Source is at github.com/helm/helm and documentation at helm.sh/docs.