Helm and the Packaging of Kubernetes Applications
Helm gave Kubernetes applications a package abstraction called charts, evolving from a 2015 Deis project through Tiller, Helm 3, OCI registries, CNCF graduation, and today's Helm 4 era.
Kubernetes made deployment declarative but left applications spread across many resources
Kubernetes objects such as Deployments, Services, ConfigMaps and role definitions can all be represented as declarative manifests. Real applications, however, often require many related resources plus configuration values that differ across environments. Helm emerged to package those related declarations as one installable and versioned unit. The project began in 2015 at Deis as Helm Classic and was introduced at the inaugural KubeCon.[1] Its core idea was that Kubernetes applications needed a distribution layer above raw YAML.
A chart packages relationships, not just files
The value is not merely compressing manifests into an archive. A chart expresses that several Kubernetes resources form one deployable application with shared configuration and lifecycle.
Charts became the reusable package format for Kubernetes applications
Helm charts contain metadata, templates, default values and dependencies that together describe a related set of Kubernetes resources. Helm documentation describes chart repositories as stores for packaged charts, while the project history records how charts became the durable packaging abstraction across Helm generations.[3][1] Templates allow one chart to produce environment-specific manifests while retaining a common application definition.
Helm 2 merged two projects and introduced Tiller inside the cluster
In 2016 Helm Classic merged with Google’s Kubernetes Deployment Manager work. Helm 2 retained a server-side component, renamed Tiller, which ran in the Kubernetes cluster and managed releases.[1] This architecture gave Helm its own release-management service but also introduced operational and security complexity because Tiller needed significant permissions and represented another control component administrators had to secure.
The package manager became part of the cluster control path
Helm 2 did not merely render manifests locally. Tiller held release state and performed operations from inside Kubernetes, making its permissions central to the security model.
Helm 3 removed Tiller and relied on Kubernetes access already held by the client
Helm 3’s redesign removed Tiller, eliminating the need to install a privileged Helm service in each cluster. The client instead uses the user’s Kubernetes credentials and stores release information in the cluster through Kubernetes resources.[1] Released in November 2019, Helm 3 brought the project closer to its original client-oriented model and simplified the relationship between Helm authorization and Kubernetes role-based access control.
Chart repositories made application packages distributable independently of source repositories
Helm chart repositories are HTTP services that expose an index of packaged charts, allowing clients to discover and retrieve versioned application bundles.[3] Organizations can operate private repositories while public discovery moved through community services such as Artifact Hub. This separated the source repository that builds an application from the package repository that distributes deployable releases.
Packaging created an ecosystem above container images
A container registry distributes images, but an application often needs several images plus Kubernetes configuration. Helm charts package that higher-level assembly.
OCI support connected charts to the container-registry infrastructure cloud teams already used
Helm 3 introduced support for storing charts in OCI-compatible registries, and the feature became enabled by default with Helm 3.8.[4] This reduced the need for a completely separate repository technology. Teams could manage charts and container artifacts through related registry infrastructure, bringing application packages closer to the distribution systems already central to cloud-native delivery.
CNCF graduation reflected Helm’s role as shared Kubernetes infrastructure
Helm joined CNCF as an incubating project in 2018 and graduated in 2020, milestones recorded in the project’s own history.[1] Graduation marked a transition from a useful deployment tool into durable ecosystem infrastructure. Charts had become a standard way vendors and open-source projects documented installable Kubernetes applications.
Package formats become standards through adoption as much as specification
Helm’s influence came from widespread use by application publishers, cluster operators and platforms that treated charts as the expected unit of Kubernetes installation.
Why Helm belongs in package-management history
Helm belongs in package-management history because it raised the unit of packaging from a library or executable to a distributed application assembled from Kubernetes resources. Its history spans Helm Classic, the Tiller architecture, the client-only Helm 3 redesign, chart repositories and OCI-based distribution.[1][2][4]
The project continues to evolve. Helm 4 was released in November 2025, and the Helm release feed shows v3.22.0 arriving in September 2026 as the final planned Helm 3 minor feature line.[2] The project’s end-of-life plan keeps Helm 3 in security-only maintenance through February 10, 2027.[5] The package abstraction survived major internal redesigns because users depended more on charts and release workflows than on any one implementation architecture.
That durability is Helm’s broader significance. Kubernetes supplied primitives for running distributed systems; Helm supplied an ecosystem convention for packaging combinations of those primitives into something users could name, version, install, upgrade and share. In cloud-native computing, the package had become an application topology rather than a single file.
Helm also changed how application publishers document installation. A chart can carry defaults, dependency relationships and template logic in a versioned artifact that vendors can test against supported Kubernetes releases. That makes installation guidance executable: instead of copying a long sequence of kubectl commands from documentation, operators can start from a package whose structure is itself maintained and released.
Works Cited
- 01Helm — History of the Project docs.helm.sh
- 02Helm GitHub — Helm v3.22.0 Release github.com
- 03Helm — Chart Repository Guide docs.helm.sh
- 04Helm — OCI-Based Registries docs.helm.sh
- 05Helm — Helm 3 End of Life helm.sh
CodeHistory is a living archive. Citations document the evidence used for this edition; later evidence may refine the account.
Submit a research lead