The Three Pillars of Helm
To understand Helm, you need to know its three main concepts. Think of it like ordering a car from a factory.
1. The Chart (The Blueprint)
A Helm Chart is a bundle of information designed to create an instance of a Kubernetes application. It's a directory (or a compressed .tgz archive of that directory) containing template YAML manifests, default configuration, and metadata.
- Analogy: The detailed engineering blueprints for a specific model of car (e.g., "Model X Blueprint"). The blueprint itself is not a car — it's the instructions for building one.
2. Values (The Configuration)
Values are the specific configuration settings you want to apply to the blueprint. These are usually stored in a file named values.yaml. Every parameter that might differ between environments — image tag, replica count, resource limits, hostname — should be expressed as a value.
- Analogy: Your specific order sheet: "Paint it red, add the sunroof, use leather seats, ship to this address."
3. The Release (The Running Instance)
A Release is a specific instance of a chart running in a Kubernetes cluster. It's what you get when you combine a Chart with specific Values and deploy it. You can install the same chart multiple times to create multiple independent releases — for example, wordpress-staging and wordpress-prod can both exist in the same cluster simultaneously, each with their own configuration and lifecycle.
- Analogy: The actual red Model X car sitting in your driveway with license plate "MY-CAR-1". A second car built from the same blueprint but painted blue would be a separate release.
Release History and Rollbacks
Every time you install or upgrade a release, Helm records a new revision of that release. This history is stored as Secrets inside the Kubernetes cluster itself (in Helm v3). This means Helm's state is stored in the cluster, not on your local machine — any team member with cluster access and Helm installed can manage releases.
Every release carries its full revision history, so rolling back to any previous known-good revision is a single command referencing that release and revision number. This is one of Helm's most operationally valuable features: the ability to atomically roll back an entire application — all its Kubernetes resources — to a known-good state with a single command.