Helm: the Kubernetes package manager

Template and release K8s apps.

Kubernetes is configured with YAML manifests, and once an application has a dozen of them — Deployment, Service, ConfigMap, Ingress, and more, each needing per-environment values — raw YAML becomes unmanageable. Helm is the Kubernetes package manager that solves this: it bundles an app’s manifests into a versioned, parameterized "chart," so you install, upgrade, and roll back a whole application as one unit, with values that differ per environment. It is IaC for Kubernetes workloads, the way Terraform is IaC for cloud resources.

$ helm install myapp ./myapp-chart -f values-prod.yaml   # install a chart with prod values
$ helm upgrade myapp ./myapp-chart -f values-prod.yaml   # roll out a change
$ helm rollback myapp 1                                    # instant rollback to revision 1
$ helm list                                               # what is installed, and its revision
$ helm repo add bitnami https://charts.bitnami.com/bitnami   # install community charts (postgres, redis...)

Templates and values

A Helm chart is a set of templated manifests plus a values file. The templates contain placeholders ({{ .Values.replicas }}), and the values file supplies the actual numbers — so one chart renders into different manifests for dev (1 replica, small resources) and prod (5 replicas, large) purely by swapping the values file. This is the same "shared code, per-environment inputs" pattern as Terraform modules, applied to Kubernetes. Public charts (a production Postgres, Redis, or ingress controller) let you deploy complex apps with a single command and a values file.

# template:
spec:
  replicas: {{ .Values.replicas }}
  ...
        image: "{{ .Values.image.repo }}:{{ .Values.image.tag }}"
 
# values-prod.yaml:
replicas: 5
image: { repo: registry.acme.internal/myapp, tag: "1.4.2" }

Releases: install, upgrade, rollback

Helm tracks each installed chart as a "release" with a revision history, which gives you application-level lifecycle management: helm upgrade rolls out a new version, and helm rollback instantly reverts to a previous revision if it goes wrong — because Helm remembers exactly what each revision deployed. This turns "deploy a Kubernetes app" into a reviewable, versioned, reversible operation, which is why Helm is the most common way to package and ship applications on Kubernetes.