Helm is the package manager for Kubernetes: it bundles the YAML manifests an application needs into a versioned, parameterized package called a chart, and installs, upgrades and rolls back that package in a cluster as a named release. In the Kubernetes ecosystem, Helm plays a role similar to apt or Homebrew on an operating system, and it is a graduated project of the Cloud Native Computing Foundation.
A typical application in Kubernetes consists of a Deployment, a Service, an Ingress, ConfigMaps, Secrets and access rules. Helm turns this collection into one unit that can be installed with a single command, configured through a values file and reproduced identically across development, staging and production clusters.
How Helm charts and releases work
Helm combines templates with values to produce Kubernetes manifests. A chart contains template files written in the Go template language, a values.yaml file with default settings and a Chart.yaml file with metadata. At install time, Helm merges user-supplied values with the defaults, renders the templates and sends the resulting manifests to the Kubernetes API server.
Every installation is a release with a name, a namespace and a revision number. Helm 3 stores release history as Secrets in the release’s namespace, so it needs no server-side component. Earlier Helm 2 relied on an in-cluster service called Tiller, which was removed because it required broad cluster permissions and complicated security.
| File or directory | Purpose | Notes |
|---|---|---|
| Chart.yaml | Name, version, appVersion, dependencies | Chart version follows semantic versioning |
| values.yaml | Default configuration values | Overridden with -f or –set |
| templates/ | Go templates for Kubernetes objects | Rendered into plain manifests |
| _helpers.tpl | Reusable named template snippets | Common labels and names |
| charts/ | Packaged dependency charts | Called subcharts |
| values.schema.json | JSON schema for values | Validates input before rendering |
| crds/ | Custom resource definitions | Installed once, never upgraded by Helm |
The Helm release lifecycle
Helm manages the full lifecycle of a release through a small set of commands. Each successful install or upgrade creates a new revision, which makes rollbacks straightforward.
| Command | Action | Typical use |
|---|---|---|
| helm install | Creates a new release | First deployment of an application |
| helm upgrade –install | Upgrades or installs if missing | Idempotent step in CI/CD pipelines |
| helm rollback | Returns to an earlier revision | Recovering from a bad release |
| helm template | Renders manifests locally | Review, diffing and GitOps tools |
| helm lint | Checks chart structure and syntax | Quality gate before publishing |
| helm uninstall | Deletes release resources | Removing an application |
Upgrades use a three-way strategic merge between the previous manifest, the new manifest and the live state in the cluster. This keeps changes made by other controllers, such as replica counts set by a Horizontal Pod Autoscaler, from being blindly overwritten in most cases. The --atomic and --wait flags make an upgrade roll back automatically if the new pods do not become ready in time.
Charts can also define hooks, which are jobs that run at specific points in the lifecycle, for example a database migration before an upgrade or a cleanup job after uninstall. Hooks are powerful but should be kept idempotent, because a failed hook leaves the release in a failed state that must be resolved before the next upgrade.
Distributing charts through repositories
Charts are shared through chart repositories. A classic repository is any HTTP server hosting packaged .tgz charts and an index.yaml file. Since Helm 3.8, charts can also be stored as OCI artifacts in the same container registries that hold images, which unifies access control and replication.
Public catalogs offer ready-made charts for databases, ingress controllers, monitoring stacks and many other components. Organizations often mirror trusted charts into an internal registry, pin exact chart versions and sign packages with provenance files or Sigstore-based signatures to protect the software supply chain.
Helm compared with other Kubernetes configuration tools
Helm is not the only way to manage Kubernetes manifests, and it is often combined with other tools. The main difference lies in templating versus patching and in whether the tool tracks releases.
| Tool | Approach | Strength | Limitation |
|---|---|---|---|
| Helm | Templating with values and releases | Packaging, sharing and rollback | Complex templates are hard to read |
| Kustomize | Patching plain YAML overlays | Template-free, built into kubectl | No packaging or release history |
| Plain manifests with kubectl | Static YAML applied directly | Maximum transparency | Heavy duplication across environments |
| Operators | Controllers managing custom resources | Day-two automation for stateful apps | Must be developed and maintained |
In GitOps workflows, tools such as Argo CD and Flux render Helm charts and reconcile the result continuously. In that model Helm acts mainly as a packaging and templating format, while the GitOps controller owns deployment and drift correction.
Best practices and common Helm pitfalls
Helm is easy to start with but easy to misuse at scale. Good charts are small, well-documented and predictable, and teams treat values files as code under version control.
| Problem | Cause | Recommended fix |
|---|---|---|
| Release stuck in pending state | Interrupted install or upgrade | Roll back or resolve the failed revision |
| Secrets stored in values files | Plain-text credentials in Git | Use external secret managers or encryption |
| Unreadable templates | Excessive logic and nesting | Simplify, split into subcharts, use helpers |
| CRDs not updated | Helm installs CRDs only once | Manage CRDs separately |
| Unexpected changes on upgrade | Unpinned chart or image versions | Pin versions and review with a diff plugin |
Reviewing rendered output before applying it, with helm template or a diff plugin, catches most surprises. Pinning chart and image versions and keeping one values file per environment make deployments reproducible.
The short version
Installing an application on Kubernetes normally means writing many separate configuration files and applying them in the right order. Helm wraps all of those files into one package, called a chart, much like an app store bundles everything a phone app needs.
You install the package with one command, adjust it with a short list of settings, and if an update goes wrong, you can return to the previous version just as easily. That makes deployments faster, more consistent and less error-prone.
Where it makes a difference
A fintech team runs the same payment API in three Kubernetes clusters: development, staging and production. Each environment used to have its own copy of about fifteen manifest files, and small differences between the copies caused several failed releases a quarter.
The team builds one Helm chart for the API with three values files that differ only in replica count, resource limits, hostnames and feature flags. The CI pipeline runs helm lint, renders the templates for review and deploys with helm upgrade --install --atomic. When a faulty configuration reaches staging, the readiness checks fail and Helm rolls the release back automatically within five minutes, before anyone needs to intervene. Environment drift disappears because every cluster is built from the same versioned chart.