CNCF Launches Initiative to Update Helm Package Manager
The Cloud Native Computing Foundation (CNCF) has launched a 4.0 initiative to update the Helm, that promises to make the open source package manager for Kubernetes environments more extensible.
Announced at the KubeCon + CloudNativeCon North America 2025 conference, other updates that are already available in Helm 4 include support for logs written in the Go programming language, support for a server-side apply capability, and an ability to embed Helm commands within applications.
The latest major update to Helm occurred six years ago. On the 10th anniversary of its initial launch, the maintainers of Helm plan to revamp the underlying architecture using WebAssembly (Wasm) instruction format to make it simpler to build a plug-in that can run across multiple operating systems.
Matt Farina, a Helm maintainer and distinguished engineer at SUSE, said that the capability will eliminate the need to build and maintain separate plugins for every platform on which Helm is deployed.
Additionally, the maintainers of the Helm project plan to modernize the underlying application programming interfaces (API) upon which the package manager is based to improve overall performance. That effort, however, will involve multiple experiments over time to preserve as much backward compatibility as possible, he noted.
Originally developed by Matt Butcher, now CEO of Fermyon Technologies, Helm is widely relied on to help IT teams manage application deployments on Kubernetes clusters. It has also been embedded into a large number of tools and applications, which makes any effort to update Helm a significant challenge. Many organizations have, over the years, also extended Helm themselves in ways they may no longer want to maintain and support if additional functionality can be added to the core Helm project. Helm 4, in the meantime, retains the core interface and behavior familiar to current users, minimizing disruption for existing workflows while also making it easier to add new capabilities and features.
There are, of course, alternatives to Helm. Many IT teams have, for example, adopted Operators based on Kubernetes APIs as a means of packaging, deploying, and managing a Kubernetes application. The choice between using Helm or an Operator developed for a specific application is largely determined by personal preference. In some Kubernetes environments, it’s not uncommon to see both Helm and Operators being used to deploy software.
IT professionals who want to participate in the development of Helm 4 are invited to an online HelmDev meeting that occurs every Thursday, noted Farina. The overall goal is to collect as much feedback as possible as the Helm API continues to evolve, he added.
Ultimately, each IT organization will need to determine to what degree to adopt Helm 4 versus opting to rely on previous versions or migrate to an alternative. When Helm was originally developed, there was no way of foreseeing how package managers might need to evolve a decade later, noted Butcher.
Hopefully, the Helm package manager will continue to remain relevant for many more years to come, at a time when the amount of software being deployed on Kubernetes clusters only continues to exponentially increase.
