Kubernetes is powerful. It's also notoriously verbose. Deploying even a simple application means writing dozens of YAML files — Deployments, Services, ConfigMaps, Ingress rules, and more. Now imagine doing that across five environments, three teams, and twenty microservices.
That's exactly the problem Helm charts solve.
Helm is the de facto package manager for Kubernetes, and Helm charts are its core primitive — reusable, versioned, configurable bundles of Kubernetes manifests. If apt manages software packages on Ubuntu and npm manages JavaScript dependencies, Helm does the same for Kubernetes applications.
This guide explains everything you need to know: what Helm charts are, how they're structured, how templating works, and how to use them in production.
What Is Helm?
Helm is an open-source tool that streamlines the installation and management of applications on Kubernetes. It was originally created by Deis in 2015, donated to the CNCF (Cloud Native Computing Foundation), and is now a graduated CNCF project — the highest maturity tier, used by organizations like Google, Microsoft, and Spotify.
Helm introduces three core concepts. Charts are the package — a bundle of templated Kubernetes manifests. Releases are an instance of a chart installed in a cluster. Repositories are remote registries that host and distribute charts.
Think of it this way: a chart is a recipe, a release is a meal you cooked from it, and a repository is the cookbook library.
What Is a Helm Chart?
A Helm chart is a collection of files that describe a related set of Kubernetes resources. It's a directory (or a .tgz archive) with a specific file structure that Helm understands.
Charts come in two flavors. Application charts deploy a full application — Nginx, PostgreSQL, a custom microservice. Library charts are shared helpers reused across other charts and don't produce releases on their own.
A single Helm chart can deploy everything your app needs — the backend, the database, the ingress rules, the secrets injection — all triggered by one command.
Helm Chart File Structure
Every Helm chart follows a standard directory layout. At the root sits Chart.yaml, which holds chart metadata like the name, version, and description. Next to it is values.yaml, which stores all the default configuration values users can override. The charts/ folder holds dependencies — other charts your chart relies on. The templates/ folder is where the actual Kubernetes manifest templates live. And .helmignore works exactly like .gitignore, excluding files you don't want bundled.
Inside the templates/ folder, you'll typically find a deployment.yaml, service.yaml, ingress.yaml, a _helpers.tpl file for reusable template snippets, and a NOTES.txt file that prints helpful instructions to the user after installation.
Chart.yaml
This is the chart's identity card. It declares the chart's name, a human-readable description, whether it's an application or library chart, the chart version, and the appVersion — the version of the actual application being deployed. These two version fields evolve independently, which matters in production. You can update the chart's packaging logic without bumping the app version, and vice versa.
values.yaml
This is where Helm's configurability truly shines. The values.yaml file defines every default setting your templates reference — things like replica count, image repository and tag, service type and port, resource limits, and whether ingress is enabled. Users override any of these at install time without touching the chart itself. That separation between chart logic and environment-specific config is the core design philosophy of Helm.
How Helm Templating Works
Helm uses the Go text/template package, extended with the Sprig function library. Templates reference values using the .Values object and chart metadata via .Chart and .Release.
When you run helm install, Helm processes every template file in the templates/ directory. It replaces every template expression with the actual resolved value and sends clean, standard Kubernetes YAML to the API server. No template syntax ever reaches Kubernetes — it's fully resolved before submission.
Templates support conditionals, so you can render an Ingress resource only when ingress is enabled in values. They support loops, so you can iterate over a list of environment variables. They support pipelines and functions from the Sprig library for things like string manipulation, encoding, and date formatting.
Files prefixed with an underscore, like _helpers.tpl, are special. Helm doesn't render them as Kubernetes manifests. Instead they define named templates — reusable snippets you call from other templates. This keeps large charts DRY and consistent across dozens of resource files.
Helm Repositories
A Helm repository is an HTTP server that hosts a collection of charts alongside an index.yaml file that describes them. The workflow is familiar if you've used any package manager. You add a repository by name and URL, update your local cache, search for charts, and install what you need.
The most widely used repositories in 2026 include Artifact Hub (the central discovery platform aggregating charts from hundreds of publishers), Bitnami (maintained by VMware/Broadcom, known for production-hardened charts for databases, queues, and middleware), and organization-specific private registries hosted on services like AWS ECR, Google Artifact Registry, or Harbor.
Installing and Managing Releases
When you install a Helm chart, Helm creates a release — a named, tracked instance of that chart in your cluster. Every release has a name, a namespace, a revision history, and a status.
The basic install command takes a release name and a chart reference. You can override values inline using the --set flag for quick changes, or pass a custom values file using -f for larger environment-specific configs.
This pattern is how teams manage dev, staging, and production differences cleanly: one chart, multiple value files.
Helm also handles upgrades and rollbacks. When you upgrade a release with new values or a new chart version, Helm increments the revision number. If something goes wrong, a single rollback command restores the previous revision. This revision history is what makes Helm genuinely useful for production operations, not just initial deployment.
Helm Chart Dependencies
Real-world applications rarely exist in isolation. A backend service might depend on PostgreSQL, Redis, and a message broker. Helm handles this through chart dependencies declared in Chart.yaml.
You list each dependency by name, version range, and repository. Running helm dependency update downloads them into the charts/ subdirectory. When you install the parent chart, Helm installs all dependencies as part of the same release. You can enable or disable individual dependencies from values.yaml, which makes it easy to skip bundled databases in environments where you're using a managed cloud service instead.
Helm vs. Alternatives: When to Use What
Helm isn't the only tool for Kubernetes manifest management, and it's worth understanding where it fits.
Kustomize is built into kubectl and takes a pure overlay approach — no templating, just patching. It's great for simple cases and GitOps pipelines where you want to avoid logic in your configs. Helm is better when you need real parameterization, versioned packaging, and dependency management.
Helmfile extends Helm by letting you declare multiple releases, their dependencies on each other, and environment-specific value files in a single declarative file. Teams managing many Helm releases often adopt Helmfile or similar orchestration tools like ArgoCD with Helm support.
Operators are Kubernetes controllers that manage complex stateful applications with custom logic. They're not a direct alternative to Helm — many operators are actually distributed as Helm charts.
For most teams building on Kubernetes, Helm remains the starting point and often the permanent solution.
Helm Security Considerations
Helm charts are code, and like all code, they can contain security issues. A few practices matter in production. Always pin image tags in your values — never rely on latest. Audit third-party charts before deploying them, especially for RBAC rules and hostPath volume mounts.
Use a private chart repository for internal charts to avoid supply chain risks. Enable Helm's provenance and integrity features using cryptographic signatures when distributing charts externally. And use tools like Trivy or Datree to lint and scan charts for misconfigurations before they reach your cluster.
Best Practices for Writing Helm Charts
Keep your values.yaml well-documented — every key should have a comment explaining what it does. Use _helpers.tpl for anything repeated across templates. Set sensible, safe defaults in values.yaml so the chart works out of the box for most users.
Always include resource requests and limits in your templates, with overridable defaults. Use the NOTES.txt file to give users clear post-install guidance. Version your charts properly and maintain a changelog. And test your charts with helm lint and helm template before pushing to a repository.
Common Helm Commands Reference
Helm's CLI is consistent and intuitive. You initialize repos, search, install, upgrade, rollback, list releases, inspect manifests with helm template before applying, and uninstall with helm uninstall. The helm template command is particularly valuable in CI pipelines — it renders the full output of a chart with given values without touching a cluster, making it easy to diff changes or feed output into other tools.
Why Helm Charts Matter in 2026
The Kubernetes ecosystem has matured significantly, but complexity hasn't gone away — it's gone deeper. Platform engineering teams are now the primary consumers of Helm, building internal developer platforms where application teams consume curated charts through self-service portals. GitOps tools like ArgoCD and Flux treat Helm releases as first-class citizens. The CNCF landscape in 2026 shows Helm as one of the most adopted projects at every company size.
Helm charts are also the dominant distribution format for software that runs on Kubernetes — from open-source databases to commercial SaaS operators to internal shared services. If you're running Kubernetes in production, you're almost certainly already using Helm. Understanding how it works under the hood makes you dramatically more effective at debugging, customizing, and building on top of it.
Frequently Asked Questions
Q. What is a Helm chart in simple terms?
A Helm chart is a pre-packaged bundle of Kubernetes configuration files that you can install, configure, and reuse. It's the Kubernetes equivalent of an apt package or an npm module.
Q. Is Helm only for large clusters?
No. Helm is useful at any scale. Even on a single-node local cluster, Helm saves time by eliminating repetitive YAML writing and making upgrades and rollbacks trivial.
Q. What's the difference between a Helm chart version and appVersion?
Chart version tracks the chart's own packaging and logic. appVersion tracks the version of the application the chart deploys. You can update one without changing the other.
Q. Can you use Helm with GitOps?
Yes, and it's one of the most common patterns. Tools like ArgoCD and Flux both have native Helm support, treating Helm releases as declarative desired state that gets reconciled continuously.
Q. What is Helm 3 and how is it different from Helm 2?
Helm 3, released in 2019, removed Tiller — a server-side component that was a significant security concern. Helm 3 is client-only, uses Kubernetes secrets to store release state, and has been the standard ever since. Helm 2 is fully deprecated.
Q. Are Helm charts safe to use from public repositories?
Public charts should be treated like any third-party code — audit them before use. Check the maintainer, review RBAC permissions the chart requests, and scan with security tools like Trivy.
Conclusion
Helm charts transform Kubernetes from an infrastructure you configure to an infrastructure you program. They bring packaging, versioning, dependency management, and environment configurability to a world that would otherwise drown in raw YAML.
Whether you're deploying open-source software onto your cluster, building internal developer platforms, or shipping your own applications across multiple environments, understanding Helm charts is a foundational Kubernetes skill. The learning curve is real but short — and once you've internalized how charts, values, and templates work together, you'll never want to manage raw Kubernetes manifests again.
