Helm
Also known as: Helm charts
Helm is a package manager for Kubernetes.
It bundles everything an application needs to run on a cluster, such as deployments, services, and settings, into a 'chart' that can be installed, upgraded, or rolled back with one command. While Helm made Kubernetes far easier to use, its template-heavy charts can become hard to read, and many teams now mix it with other tools.
Helm, explained at three levels
At home
Installing an app on Kubernetes can mean writing many configuration files. Helm is like an app store installer: you pick a package and it sets everything up, with options for things like size or passwords.
At work
Helm lets teams install and update complex applications on Kubernetes consistently across environments. Popular software such as databases and monitoring tools comes with ready-made Helm charts.
At home
A Helm chart contains template files plus a 'values' file with settings. When you install a chart, Helm fills in the templates with your values and sends the result to Kubernetes. Each install is a 'release' that Helm can upgrade or roll back.
At work
Teams publish internal charts to registries, keep environment-specific values files for development, staging, and production, and deploy charts through CI/CD or GitOps tools such as Argo CD. Chart versions let teams pin and promote known-good configurations.
At home
Helm uses Go templates, which can turn into a maze of conditionals and loops. In my view, a chart with hundreds of options is often a sign that it tries to serve everyone and ends up hard for anyone to understand.
At work
Review third-party charts before use, since they can set broad permissions; pin versions and scan rendered manifests for misconfigurations. Consider Kustomize for simple overlays, or render Helm templates in CI so reviewers see actual manifests. Store charts as OCI artifacts in existing container registries to simplify distribution.
Real-world examples
At home
Marcus wanted to try a monitoring stack on his home Kubernetes cluster. Instead of writing dozens of files, he installed a community Helm chart with one command and had dashboards running in minutes.
At work
Nadia's platform team at a Calgary energy company maintains one Helm chart for all internal web services. Product teams supply a short values file, and the chart adds logging, security settings, and autoscaling automatically.
How it compares
| feature | Helm | Kustomize |
|---|---|---|
| Approach | Templates filled with values | Patches layered on plain YAML |
| Packaging | Versioned charts | No packaging |
| Rollback | Built in | Through Git or other tools |
| Readability | Can get complex | Closer to the final YAML |
Helm packages applications. Kustomize customizes configuration.
For analysts
Public Helm charts are convenient, but they're third-party code running in your cluster. I'd require a review of permissions and pinned versions before any community chart reaches production.
History & origin
Deis created Helm in 2015, and it was announced at the first KubeCon that November. Helm 2 merged in work from Google's Kubernetes Deployment Manager team, but it relied on a server-side component called Tiller that raised security concerns. Microsoft acquired Deis in 2017, and Helm joined the Cloud Native Computing Foundation in 2018, graduating in 2020. Helm 3, released in November 2019, removed Tiller entirely. Artifact Hub, launched in 2020, became the main place to find public charts. In my opinion, removing Tiller was one of the best decisions in the Kubernetes ecosystem, a reminder that a popular project can admit a design mistake and recover.