Helm: The Package Manager for Kubernetes

Helm is the package manager for Kubernetes. It bundles the manifests an application needs (Deployments, Services, ConfigMaps, RBAC and so on) into a versioned chart, renders that chart with environment-specific values, and installs it into a cluster as a tracked release that can be upgraded, inspected and rolled back. It addresses a problem every Kubernetes team meets early: a single application needs many related YAML files, and they differ slightly between development, staging and production. Helm began at Deis in 2015, became part of the Kubernetes project, and was accepted into the CNCF as an incubating project in June 2018. It graduated in May 2020. Helm 4, the first major version in six years, was released in November 2025 with a rebuilt plugin system and native server-side apply.

CNCF daily · Sprint 1, day 1 · Application Definition & Image Build

At a glance

Category	Application Definition & Image Build
CNCF status	Graduated. Accepted June 1, 2018 (Incubating); graduated May 1, 2020
Written in	Go, distributed as a single CLI binary and a Go SDK
License	Apache 2.0
Packaging unit	Chart: templates, default values, metadata and dependencies
Distribution	OCI registries (Harbor, ECR, GHCR, ACR) or classic HTTP chart repositories
Current major version	Helm 4 (November 2025); Helm 3 still widely deployed

Architecture

flowchart TB
  DEV[Chart author] --> CHART[Chart<br/>templates, values.yaml, Chart.yaml]
  CHART -->|helm package and push| REG[OCI registry<br/>or chart repository]
  OPS[Operator or CI pipeline] -->|helm upgrade --install| CLI[Helm CLI or SDK]
  REG -->|pull chart| CLI
  VALS[Environment values<br/>dev, stage, prod] --> CLI
  CLI --> RENDER[Template engine<br/>Go templates and Sprig]
  RENDER --> MAN[Rendered manifests]
  MAN -->|apply| API[Kubernetes API server]
  CLI -->|store release record| SEC[Release history<br/>Secrets in the namespace]
  API --> WL[Workloads<br/>Deployments, Services, ConfigMaps]

Component	Responsibility
Chart	A directory or archive containing Chart.yaml (metadata, version, dependencies), values.yaml (defaults) and templates/.
Values	Configuration layered at install time: chart defaults, then values files, then --set overrides.
Template engine	Renders Go templates with Sprig functions and Helm helpers into plain Kubernetes manifests.
Helm CLI / SDK	Resolves dependencies, renders, applies to the cluster and waits for readiness. There is no in-cluster component.
Release record	Each install or upgrade is stored as a versioned Secret in the release namespace, which enables history and rollback.
Registry	Stores packaged charts as OCI artifacts alongside container images, or in a classic index.yaml repository.

Design principle. Helm separates what an application is (the chart) from how a given environment runs it (values). Since Helm 3 removed the in-cluster Tiller server, Helm has been a client-side tool that uses the caller’s own Kubernetes credentials and RBAC. Its state lives in the cluster as ordinary Secrets, so there is nothing extra to operate or secure.

Production reference design

A common pattern on EKS, GKE, AKS or an on-premises cluster: charts are built in CI, stored in an OCI registry, and applied by a GitOps controller.

1. Create and lint a chart for the service, keeping environment differences in values files only:

   helm create payments-api
   helm lint payments-api -f values-prod.yaml
   helm template payments-api -f values-prod.yaml | kubeconform -strict

2. Package and publish to an OCI registry in CI, versioning the chart with semantic versions:

   helm package payments-api --version 1.4.0 --app-version 2.8.1
   helm push payments-api-1.4.0.tgz oci://registry.example.com/charts

3. Keep production overrides small and explicit, for example values-prod.yaml:

   replicaCount: 3
   image:
     repository: registry.example.com/apps/payments-api
     tag: "2.8.1"
   resources:
     requests: { cpu: 250m, memory: 256Mi }
     limits: { memory: 512Mi }
   ingress:
     enabled: true
     hosts: [payments.example.com]

4. Install or upgrade atomically when deploying directly, so a failed upgrade rolls itself back:

   helm upgrade --install payments oci://registry.example.com/charts/payments-api \
     --version 1.4.0 -n payments --create-namespace -f values-prod.yaml --rollback-on-failure --wait --timeout 10m

   (--rollback-on-failure is the Helm 4 name for Helm 3’s --atomic.)
5. Hand deployment to GitOps. In most mature setups, Argo CD or Flux reference the chart and values from Git and render it continuously, and engineers rarely run helm upgrade against production by hand.

Typical production uses include packaging internal microservices, installing third-party platform components (ingress controllers, cert-manager, Prometheus, database operators) from their official charts, and standardising deployments across many clusters.

Operational considerations

• CRDs need a separate plan. Helm installs CRDs from a chart’s crds/ directory but does not upgrade or delete them. Many teams manage CRDs in a dedicated chart or apply them separately before upgrades.
• Release state lives in Secrets. Limit history with --history-max (for example 10) so release Secrets do not accumulate, and restrict who can read Secrets in application namespaces.
• Template complexity is the main long-term cost. Large charts with deep conditionals become hard to review. Prefer library charts, a values JSON schema (values.schema.json) and helm template diffs in pull requests.
• Supply-chain security. Sign charts (Helm provenance files, or Cosign for OCI artifacts) and pin chart versions and image digests; never deploy floating latest tags.
• Helm 3 to 4 migration. Most charts work unchanged, but plugins, some flags and SDK consumers need review. Test in CI before upgrading the CLI used by pipelines.

Adoption

• Helm is the de facto distribution format for Kubernetes software: most open-source infrastructure projects publish an official chart, and Artifact Hub (a CNCF project) indexes many thousands of them.
• The CNCF project page lists case studies from Subaru, for AI development on its EyeSight platform, and HDFC Bank, for a multi-cloud enterprise payment hub.
• Argo CD and Flux, the two graduated CNCF GitOps projects, both support Helm charts natively, which places Helm underneath a large share of GitOps deployments.

Alternatives

Solution	Model	Best suited to
Kustomize	Template-free overlays, built into kubectl	Teams that prefer plain YAML with patches per environment
Carvel (ytt, kapp) (CNCF Sandbox)	Structured templating plus an apply tool	Teams wanting stricter templating and dependency-aware deploys
CDK8s (CNCF Sandbox)	Manifests generated from TypeScript, Python, Go or Java	Platform teams that prefer general-purpose languages
Timoni / CUE	Typed configuration language	Strong schema validation for complex configuration
Operators	Custom controllers that manage an application	Stateful software needing day-2 automation beyond install and upgrade

Strengths and limitations

Strengths	Limitations
Universal packaging format with a huge ecosystem of ready-made charts	Go templating over YAML is error-prone and hard to read at scale
Versioned releases with history and one-command rollback	CRD lifecycle (upgrade and delete) is still not handled
No in-cluster server; uses the caller’s RBAC	Install-time tool only: no continuous drift correction without GitOps
Works with OCI registries alongside container images	Large umbrella charts become slow and fragile
First-class support in Argo CD, Flux and most CI tools	Values interfaces differ between charts, so each one must be learned

Recommendation

Adopt. Helm is the standard way to package and consume Kubernetes applications and belongs in every platform toolkit. Use it for packaging, publish charts to an OCI registry, and let Argo CD or Flux perform the actual deployments. Keep charts small, validate values with a schema, and manage CRDs separately.

References: CNCF project page · Helm documentation · Helm project history · InfoQ: Helm 4 released · Artifact Hub