Helm Is Born at the First KubeCon, Modeled on Homebrew and apt
Started as a Deis project on October 15, 2015, Helm brought familiar package-manager concepts to Kubernetes — later merging with Google's Deployment Manager to become the Helm 2 the ecosystem would standardize on.
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.
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.
Sources: The History of the Project — Helm, Helm 3 Preview: A History of Helm — Helm Blog, Helm Project Journey Report — CNCF