Helm

First PublishedFeb 16, 2026Last UpdatedMar 30, 2026ByAtif Alam

Helm is the package manager for Kubernetes. Instead of managing dozens of individual YAML files, you install a chart — a pre-packaged set of Kubernetes resources — and customize it with values.

Key Concepts

• Chart — A collection of templates and defaults that describe a set of Kubernetes resources (e.g. a deployment, service, configmap, ingress).
• Release — A specific instance of a chart installed in a cluster. You can install the same chart multiple times with different names.
• Values — Configuration you pass to customize a chart (replicas, image tag, resource limits, etc.).
• Repository — A place where charts are stored and shared (like npm for Node or PyPI for Python).

Common Commands

Add a Repository

helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update

Search for Charts

helm search repo nginx
helm search hub prometheus        # search Artifact Hub

Install a Chart

helm install my-nginx bitnami/nginx

This creates a release named my-nginx using the bitnami/nginx chart with default values.

Custom Values

Override defaults with --set or a values file:

helm install my-nginx bitnami/nginx --set replicaCount=3

helm install my-nginx bitnami/nginx -f my-values.yaml

Example my-values.yaml:

replicaCount: 3
service:
  type: LoadBalancer
resources:
  limits:
    cpu: 200m
    memory: 256Mi

List Releases

helm list
helm list -A                # all namespaces

Upgrade a Release

helm upgrade my-nginx bitnami/nginx --set replicaCount=5
helm upgrade my-nginx bitnami/nginx -f my-values.yaml

Rollback

helm rollback my-nginx 1    # roll back to revision 1
helm history my-nginx        # see all revisions

Uninstall

helm uninstall my-nginx

Chart Structure

A chart is a directory with this layout:

my-chart/
  Chart.yaml          # name, version, description
  values.yaml         # default configuration
  charts/             # sub-charts (dependencies)
  templates/          # Kubernetes manifest templates
    deployment.yaml
    service.yaml
    ingress.yaml
    _helpers.tpl      # reusable template snippets
    NOTES.txt         # post-install message shown to user

When you run helm install, Helm renders every file in templates/ using Go templating, merges your values with the defaults, and applies the resulting YAML to the cluster. For the full guide on writing templates, value injection methods, and where values come from in production, see Helm Templating.

When to Use Helm

• Third-party software — Installing Prometheus, NGINX, PostgreSQL, etc. Most have official Helm charts.
• Repeatable deployments — Same app deployed to dev, staging, prod with different values files.
• Versioned releases — Helm tracks revisions so you can roll back if something breaks.
• Your own apps — Once you have more than a few manifests, templatizing them into a chart avoids copy-paste across environments.

Limitations and Pitfalls

• Helm 3 vs 2 — Helm 3 has no Tiller; releases are namespace-scoped by default and upgrades use a three-way merge (live state vs last release vs new chart). Understand unexpected retained fields after kubectl edit outside Helm.
• Hooks and ordering — pre/post hooks and CRD install jobs can fail or run in surprising order; upgrades may leave resources half-applied. Test upgrades in staging.
• Subcharts and versions — Dependency version pins in Chart.yaml / lock files; transitive chart upgrades are easy to get wrong (“subchart hell”).
• Opaque upstream charts — Huge community charts hide complexity; values surface only part of the behavior — use helm template and diff tools before prod.
• GitOps + Helm — Drift when someone runs kubectl outside the pipeline; Argo CD / Flux reconcile rendered manifests — align who owns release vs sync.
• Secrets in values — Plaintext in values.yaml is a git and shell history risk; prefer Sealed Secrets, SOPS, External Secrets, or CI-injected values (see Helm Templating secrets section).
• Debugging — helm template / helm get manifest to see rendered YAML; compare with cluster objects when “Helm says success but app broken.”

For when operators or GitOps fit better, see Helm, operators, and GitOps.

Key Takeaways

• Helm = charts (packages) + values (config) + releases (instances).
• helm install to deploy, helm upgrade to update, helm rollback to revert.
• Use values files (-f values.yaml) for environment-specific config instead of long --set chains.
• For Go templating syntax, built-in objects, named templates, and value sources, see Helm Templating.