Helm — Trivia & Interesting Facts¶
Surprising, historical, and little-known facts about Helm.
Helm was created at Deis, which no longer exists¶
Helm was created by Matt Butcher and Matt Fisher at Deis (a PaaS company) in 2015. Microsoft acquired Deis in 2017 primarily for its Kubernetes tooling, including Helm. Deis as a product was discontinued, but Helm survived and thrived. Butcher went on to create several other CNCF projects and co-authored "Learning Helm" for O'Reilly.
Helm 2's Tiller component was a massive security hole¶
Helm 2 required a server-side component called Tiller that ran inside the Kubernetes cluster with broad permissions. By default, Tiller had cluster-admin access and no authentication — anyone who could reach the Tiller pod could deploy anything to any namespace. This was such a severe security concern that many organizations banned Helm 2 entirely. Helm 3 (November 2019) eliminated Tiller completely, calling its removal the release's "headline feature."
Helm charts are just tarballs with a specific directory structure¶
Despite the elaborate tooling, a Helm chart is ultimately a .tgz file containing YAML templates, a Chart.yaml metadata file, and a values.yaml defaults file. You can create one with tar and install it with helm install. The entire chart format was inspired by Homebrew formulas and Debian packages — the idea was to make Kubernetes applications as installable as apt-get install nginx.
The Artifact Hub replaced a single-point-of-failure chart repository¶
The original Helm stable/incubator chart repositories, hosted on GitHub, were deprecated in November 2020 after becoming unmaintainable — the single repo had thousands of charts maintained by a handful of volunteers, with a pull request backlog stretching months. Artifact Hub (artifacthub.io) replaced it with a decentralized model where anyone can publish charts from their own repositories.
Go templates in Helm charts cause more frustration than any other feature¶
Helm uses Go's text/template library, which was designed for simple text substitution, not complex YAML generation. The combination of YAML's whitespace sensitivity and Go templates' whitespace handling has driven countless developers to madness. The {{- and -}} trim markers, the nindent function, and the toYaml pipe are all workarounds for what is fundamentally a mismatch between the template engine and the output format.
helm template renders locally — no cluster required¶
helm template renders a chart's templates into plain Kubernetes YAML without contacting a cluster. This is used extensively in GitOps workflows where the rendered manifests are committed to git and applied by ArgoCD or Flux. Some teams never run helm install at all — they use Helm purely as a templating engine and let their GitOps tool handle the deployment.
Helm hooks can run jobs before or after install, upgrade, or delete¶
Helm's hook system (pre-install, post-install, pre-upgrade, post-upgrade, pre-delete, post-delete) lets charts run Kubernetes Jobs at specific lifecycle points. Common uses include database migrations on upgrade and backup jobs before delete. However, hooks have sharp edges: a failed pre-upgrade hook leaves the release in a "pending-upgrade" state that requires manual helm rollback to recover from.
Helm stores release state as Kubernetes Secrets¶
In Helm 3, every release's state (the rendered manifests, values, and metadata) is stored as a Kubernetes Secret in the release's namespace. This means helm list is actually querying the Kubernetes API, not a local database. The Secrets are base64-encoded, gzipped JSON. If you delete these Secrets, Helm loses all knowledge of the release — the deployed resources remain but become "orphaned" from Helm's perspective.
Helmfile was created because Helm could not manage multiple releases¶
Helm manages individual releases, but real environments have dozens of interdependent charts. Helmfile (created by Mumoshu in 2017) fills this gap by letting you declaratively define multiple Helm releases with dependencies, shared values, and environment-specific overrides in a single helmfile.yaml. It became so popular that the Helm maintainers considered and rejected building similar functionality into Helm itself, preferring to keep Helm focused.
Library charts contain no templates — only reusable definitions¶
Helm 3 introduced "library charts" (type: library in Chart.yaml) that cannot be installed directly. They exist solely to provide reusable template helpers and named templates that other charts can import. This solved the massive duplication problem where dozens of microservice charts each contained identical boilerplate templates for Deployments, Services, and Ingresses.
Helm OCI support took four years to stabilize¶
Support for storing Helm charts in OCI registries (the same registries that store container images) was announced as experimental in Helm 3.0 (2019) and did not reach GA until Helm 3.8 (January 2022). The slow rollout was due to complexities in mapping Helm's chart metadata to OCI artifact manifests. OCI support means charts and the images they reference can live in the same registry, simplifying air-gapped deployments considerably.