What Is Helm? Kubernetes Package Management Explained

Deploying one small app to Kubernetes can mean writing 5 or more YAML files: a Deployment, a Service, a ConfigMap, an Ingress, maybe a Secret and a ServiceAccount. Now deploy that same app to dev, staging and production with slightly different settings in each. Copying and editing YAML by hand gets messy fast, and one wrong indent can take down a release.

Helm solves this problem. It is to Kubernetes what apt is to Ubuntu or Homebrew is to macOS: a way to package, install, configure and upgrade software with a few commands. This guide explains the 3 core ideas (charts, values and releases), walks through a simple install, and covers when Helm is the right tool.

What Helm is

Helm is an open-source package manager for Kubernetes. It joined the Cloud Native Computing Foundation (CNCF) in 2018 and graduated in 2020, the CNCF’s highest maturity level. It runs as a command-line tool on your laptop or in a CI/CD pipeline and talks directly to your cluster’s API.

Helm does 3 jobs:

1. Packages Kubernetes manifests into a versioned, shareable bundle.
2. Templates those manifests so one package works across environments.
3. Tracks each installation, so you can see what is deployed, upgrade it and roll it back.

If Kubernetes itself is still new to you, start with our Kubernetes explainer and the Docker vs Kubernetes guide, then come back.

The 3 big concepts: charts, values and releases

The Helm documentation builds everything on 3 ideas.

Concept	What it is	Everyday analogy
Chart	A package of templated Kubernetes manifests plus metadata	An app installer
Values	Configuration settings that fill in the templates	The options you pick during install
Release	One installed instance of a chart in a cluster, with a name and revision history	The installed app on your machine

A fourth idea, the repository, is simply a place where charts are published and downloaded. Charts can live in classic HTTP chart repositories or in OCI container registries, the same kind of registry that stores your container images. You can search public charts on Artifact Hub.

Key takeaway: A chart is the recipe, values are your ingredient choices, and a release is the meal you actually served. One chart can produce many releases, each with different values.

Inside a Helm chart

A chart is a folder with a predictable layout. According to the Helm chart documentation, the main pieces are:

• Chart.yaml (required): the chart’s name, version, description and any dependencies.
• values.yaml: the default configuration, such as image tag, replica count and resource limits.
• templates/: Kubernetes manifest templates written with Go templating. Helm fills them in with values to produce real YAML.
• templates/NOTES.txt (optional): short usage notes printed after installation.
• charts/: subcharts this chart depends on, such as a database.
• crds/: Custom Resource Definitions, installed before the rest of the chart.
• values.schema.json (optional): a JSON Schema that validates values, catching typos before they reach the cluster.

Charts that target Helm 3 and later use apiVersion: v2 in Chart.yaml. A chart can be an application chart, which installs something, or a library chart, which only provides shared template helpers for other charts.

Here is the idea in miniature. A template line might say:

yaml replicas: {{ .Values.replicaCount }}

And values.yaml might say:

yaml replicaCount: 1 image: repository: nginx tag: "1.27"

When Helm renders the chart, replicas: 1 ends up in the Deployment manifest. Change the value, and the same template produces a different result.

A simple example: install, upgrade and roll back an app

Here is a minimal walk-through using a chart you create yourself, so there is no third-party dependency. You need a Kubernetes cluster (a local one such as kind or minikube works) and the Helm CLI installed.

Step 1: Scaffold a chart

bash helm create hello-web

This generates a working starter chart with a Deployment, Service and other templates. It deploys a basic web server image by default.

Step 2: Preview what Helm will create

bash helm template hello-web ./hello-web

This prints the rendered YAML without touching the cluster. It is a good habit before any install.

Step 3: Install it as a release

bash helm install demo ./hello-web --set replicaCount=2

demo is the release name. The --set flag overrides the default value from values.yaml. Helm creates the resources and records revision 1 of the release.

Step 4: Check the release

bash helm list helm status demo

Step 5: Upgrade with a values file

Create prod-values.yaml with replicaCount: 3, then run:

bash helm upgrade demo ./hello-web -f prod-values.yaml

Helm applies only what changed and records revision 2.

Step 6: Roll back if something breaks

bash helm rollback demo 1

Helm returns the release to revision 1. When you are done, helm uninstall demo removes it.

A note on precedence: you can pass several -f files, and the rightmost wins. Values set with --set are merged on top of values files, so they take priority. In production, prefer values files kept in Git over long --set strings, because files are reviewable and repeatable.

Installing third-party software with Helm

Most teams first meet Helm when installing someone else’s software, such as an ingress controller, a monitoring stack or a database operator. The pattern is the same:

bash helm repo add <repo-name> <repo-url> helm repo update helm install <release-name> <repo-name>/<chart-name> -f my-values.yaml

For charts published to an OCI registry, you reference them with an oci:// address instead of adding a repo. Before installing any public chart, read its values.yaml and README, check who maintains it and pin a specific chart version rather than always taking the latest.

Helm 4 and the end of Helm 3 support

Helm 4.0.0 was released on November 12, 2025, the first major version in 6 years. Highlights include a redesigned plugin system with WebAssembly plugin support, server-side apply support, improved resource watching for waits and local content-based caching. Helm 4 continues to support apiVersion: v2 charts, but it includes some backward-incompatible CLI and SDK changes, so the Helm team advises testing your installs.

The Helm project says Helm 3 gets bug fixes until July 8, 2026 and security fixes until November 11, 2026. If your pipelines still use Helm 3, plan the upgrade now and test your charts and scripts against Helm 4.

Helm vs plain YAML vs Kustomize

Helm is not the only way to manage Kubernetes configuration.

Approach	How it works	Strengths	Trade-offs
Plain YAML (kubectl apply)	Static manifest files	Simple, nothing extra to learn	Lots of copy-paste across environments; no release history
Kustomize	Overlays patch a base set of YAML; built into kubectl	No templating language; easy to read	No packaging, versioning or rollback of its own
Helm	Templated charts plus values; tracks releases	Packaging, sharing, dependencies, upgrades and rollbacks	Go templates can become hard to read in large charts

Many teams use both: Helm to install third-party software and Kustomize or simple charts for their own apps. Helm also fits well with GitOps tools, which can deploy charts directly from Git, and with the broader practice of infrastructure as code.

Where to start

1. Install the Helm CLI and a local cluster, then run the helm create walk-through above.
2. Read a popular chart’s values.yaml to see how experienced maintainers structure options.
3. Package one of your own services. Keep the chart small: a Deployment, a Service and the values you actually change between environments.
4. Add helm lint and helm template to your CI/CD pipeline so broken charts fail before deployment.
5. Store environment values files in Git and pin chart versions for anything you install from public repositories.
6. Standardize on Helm 4 for new work, given the Helm 3 support dates.

Conclusion

Helm turns a pile of Kubernetes YAML into a versioned package you can install, configure, upgrade and roll back with a handful of commands. Learn the 3 core ideas, charts, values and releases, and the rest follows. Start with one simple chart for your own app, keep values in Git, check public charts before trusting them, and move to Helm 4 if you haven’t already.

Sources

• Helm docs: Using Helm — charts, repositories, releases, core commands and values precedence
• Helm docs: Charts — chart file structure, apiVersion v2, chart types and dependencies
• Helm blog: Helm 4 Released — Helm 4.0.0 release date, new features and Helm 3 support timeline
• CNCF: Helm graduation announcement — Helm’s graduated status in the Cloud Native Computing Foundation