Helm Is Born at the First KubeCon, Modeled on Homebrew and apt
Helm began at Deis in 2015, merged ideas with Deployment Manager, removed Tiller in Helm 3, and matured into Kubernetes package management.
Helm, now the standard package manager for Kubernetes, began life as a Deis project on October 15, 2015, introduced at the very first KubeCon — at the time, explicitly modeled after the package-manager experience of tools like Homebrew, apt, and yum.
The problem it set out to solve
Early Kubernetes had no standard way to package and distribute an application’s full set of related resources (deployments, services, config) as a single, versioned, installable unit — each team tended to develop its own ad-hoc conventions for managing multi-resource applications. Helm’s original goal, in its first incarnation (retrospectively called Helm Classic), was making it easy to package and install applications on Kubernetes the same straightforward way a traditional package manager handles software on a single machine.
The 2016 merger that produced Helm 2
In January 2016, the Helm project merged with Kubernetes Deployment Manager, a Google Cloud Storage-based tool with its own server-side component. That merger’s most lasting contribution was Deployment Manager’s server-side piece, renamed Tiller, which became a defining (and later controversial, eventually removed) architectural feature of Helm 2, released later that year.
Tiller maintained release operations inside the cluster, which enabled Helm 2’s model but created a substantial authorization and lifecycle surface. Installations frequently granted Tiller broad permissions, making its security configuration inseparable from the security of every chart it could deploy. The architecture also complicated multi-tenant clusters and recovery.
Helm 3 changed the trust model
Helm 3, released in November 2019, removed Tiller. The client now uses the Kubernetes API with the invoking user’s credentials, aligning chart operations with ordinary cluster authentication and RBAC. Release state remained stored in the cluster, and the revision model, templating, chart dependencies, hooks, and rollback concepts continued in evolved form.
Removing Tiller did not make charts inherently safe. A chart can create privileged workloads, cluster-wide RBAC, hooks, and custom resources. Operators must still inspect rendered manifests, constrain credentials, pin chart and image versions, test upgrades, and understand persistent-data changes. Helm packages Kubernetes resources; it does not replace application architecture or change management.
What the package-manager analogy gets right—and misses
The analogy to apt or Homebrew explains versioned packages, dependencies, repositories, installation, upgrades, and removal. A Helm release, however, manages declarative API objects in a distributed control plane. Readiness is asynchronous, controllers continue reconciling after Helm exits, and external side effects may not roll back with the release.
That is why a production chart needs more than successful rendering: schema validation, supported Kubernetes APIs, immutable image identity, health probes, upgrade compatibility, rollback tests, documented values, and safe ownership boundaries. Helm’s success came from making a difficult packaging problem approachable, while mature use requires remembering where the analogy ends.
The path to becoming an official CNCF project
Helm moved from a Kubernetes subproject to a full, independent CNCF project in June 2018, and reached CNCF’s graduated maturity status in April 2020 — the same kind of formal recognition process Prometheus went through as CNCF’s second hosted project, reflecting the project’s growing maturity and broad production usage across the ecosystem.
Why modeling Helm on traditional package managers was the right instinct
Every major operating system had already solved “how do I install, upgrade, and remove a piece of software as one coherent unit” decades before Kubernetes existed — Helm’s founders recognized that Kubernetes applications, despite being distributed across multiple resource types and pods, faced the exact same fundamental packaging problem. Borrowing a well-understood mental model, rather than inventing an entirely new one, made Helm considerably easier for the ecosystem to adopt quickly.
Related:
Sources: