How Helm Works
IntermediateHelm is the package manager for Kubernetes. Deploying an app to Kubernetes means writing lots of YAML — deployments, services, config maps, ingresses — often nearly identical across environments. Helm packages these into a reusable, parameterised bundle called a chart. You supply a values file to customise it, and Helm renders the templates into final manifests and installs them as a tracked release you can upgrade and roll back — turning sprawling YAML into a versioned, shareable package.
Think of Helm as a meal kit for Kubernetes
Cooking a complex dish from scratch means measuring every ingredient yourself, every time (hand-writing YAML). A meal kit (a Helm chart) comes with a recipe and pre-portioned ingredients, and a card where you note preferences like spice level (the values file). You follow it to plate the finished meal (rendered manifests), and if a new version of the kit arrives you can upgrade — or go back to the previous recipe — without recreating everything from raw ingredients.
Step by Step
Key Concepts
Chart
A Helm package: a directory of templated Kubernetes manifests plus metadata (Chart.yaml) and default values. Charts are versioned and shareable via repositories, like packages in any package manager.
Templates and Values
Templates are manifests with placeholders; values are the parameters that fill them. Separating them lets one chart produce different deployments (dev/staging/prod) from different values files.
Release and Revision
A release is a named, installed instance of a chart in a cluster. Each upgrade creates a new revision, and Helm keeps the history so you can roll back to any previous revision.
Helm vs Kustomize
Helm uses templating and packaging with values and releases; Kustomize patches base YAML without templates. Helm suits shareable, parameterised packages; Kustomize suits overlay-based customisation of your own manifests.
Key Facts
- Helm 3 removed the server-side Tiller component, so it now runs entirely client-side and respects normal Kubernetes RBAC.
- Public chart repositories let you install complex software (databases, ingress controllers, monitoring stacks) with a single command instead of authoring dozens of manifests.
- The values file is the customisation seam — the same chart deploys to every environment by supplying different values, keeping configuration DRY.
Real-World Applications
Installing off-the-shelf software
Rather than writing manifests for PostgreSQL or an ingress controller, you helm install a community chart and override a few values — production-grade software deployed in one command.
Packaging your own app
A team wraps its microservice manifests in a chart with a values file per environment, so deploying to staging vs prod is just a different values override, and upgrades and rollbacks are tracked releases.
Frequently Asked Questions
What is Helm and what problem does it solve?
Helm is the package manager for Kubernetes. Deploying an application to Kubernetes requires many YAML manifests that are often duplicated across environments with small differences. Helm solves this by packaging templated manifests into a reusable, parameterised bundle called a chart. You customise it with a values file, and Helm renders and installs it as a tracked release — turning repetitive, error-prone YAML into a versioned, shareable package.
What is a Helm chart?
A Helm chart is a package containing templated Kubernetes manifests, metadata (Chart.yaml), and default configuration values. The templates use placeholders instead of hard-coded values, so a single chart can produce different deployments depending on the values supplied. Charts are versioned and can be shared through chart repositories, much like packages in npm or apt.
How do Helm templates and values work together?
Templates are Kubernetes manifests with placeholders written in Go templating syntax, and values are the parameters that fill those placeholders. You provide a values.yaml file (and per-environment overrides) specifying things like the image tag, replica count, and hostnames. When you install or upgrade, Helm merges the templates with your values to produce the final manifests, so the same chart deploys differently to dev, staging, and production.
How do upgrades and rollbacks work in Helm?
When you run helm upgrade, Helm renders the chart with your new values and applies the changes as a new revision of the release, keeping the previous revisions in its history. If the new version has problems, helm rollback returns the release to a previous revision quickly. Because Helm tracks every revision of a release, deployments become versioned and reversible.