Helm 4 marks 10 years with major features for Kubernetes

Helm, the Kubernetes package manager now marking its 10th anniversary with the release of version 4, began as a hackathon project in 2015.

"I was working for a startup called Deis, and we were building an open source competitor to Heroku," said Matt Butcher, co-founder of Helm. "We were getting really into containers, and Kubernetes 1.0 had just come out."

During a company offsite, Butcher and his colleagues ran a hackathon. "We decided it would be really cool to build like NPM, but for Kubernetes," said Butcher. "We had already experienced how hard it was to manage all the YAML that Kubernetes required."

Their project, originally named K8s Place, won a USD $75 Amazon gift card. "I promptly spent my $25 share on coffee. We thought that was the end of it," said Butcher.

But the company's leadership saw potential. The next day, Butcher met with Deis's CEO and CTO. They liked the package manager and assigned Butcher a team to start developing a full project. Butcher said he project was renamed after a brainstorming session involving nautical terms - a fitting choice for Kubernetes' maritime theme. There, in 2015, Helm was underway.

Matt Farina, one of the longest-standing core maintainers, joined soon after. The two Matts had long collaborated on open source projects before Helm. "We wrote one of the first package managers for Go," said Butcher. "Before that, we were in the PHP and OpenStack communities. We've just kind of worked our way through the trendy technologies."

Farina started off working on the project on the side. Later, while working for Samsung, he was formally assigned to maintain Helm. "[Samsung] said this is a core technology for us - go become a maintainer and work on that." That's when working on help became less of a contribution to and more of a mainstream thing for me for Farina.

Evolving with Kubernetes

Helm's development has mirrored Kubernetes' own evolution.

"When Helm 1 and Helm 2 came out, you didn't have CRDs, you didn't have custom controllers. RBAC hadn't started yet," said Farina. "We were so early on in Kubernetes that all these things we think of as foundational weren't there. So when all this stuff landed...We needed to modernise it, to bring it to modern Kubernetes, which is what brought about Helm 3."

Helm 2 represented a move from an early prototype to a full-fledged package manager, merging with a Google project. The transition to Helm 3 brought architectural changes to align with Kubernetes' maturing ecosystem.

"Helm 3 was the first release where we felt like it hit the stability guidelines we wanted," said Butcher. "We understood the problem, the user, and how they were going to use it."

That stability helped Helm remain in version three for six years. Butcher noted that over time, the addition of features led to design debt, prompting the need for Helm 4.

Launching Helm 4 at KubeCon

Helm 4 was officially launched this week, on the second day of KubeCon North America in Atlanta. The launch introduces notable advancements to the Software Development Kit (SDK), specifically targeting developers who integrate Helm functionality into their own applications. It introduces support for modern Go logging and enables Helm commands to be integrated directly into external applications. This update also aligns Helm with the latest versions of Kubernetes, adding compatibility with features such as server-side apply.

The release includes a new plugin system, allowing plugins to be written in WebAssembly (WASM), broadening portability across platforms and architectures. Existing plugins remain compatible, maintaining continuity for teams already using Helm extensions.

The update also modernised support for the Open Container Initiative (OCI), improved security, and cleaned up long-standing technical debt. 

In response to calls for more flexible package management, Helm 4 lays the groundwork for expanded chart capabilities in future updates. The new structure also permits significant changes and enhancements to charts without disrupting existing user workflows, ensuring backward compatibility.

"People would type switch between it when they use the Helm SDK, which was kind of painful," said Farina. "We really just always wanted to combine it back into the one, but we followed along with the Go compatibility guidelines. There were a lot of things like that internally in the SDK - so this stuff slowly built up over time."

Why six years?

The long interval between major releases reflects both deliberate stability and community turnover. "After Helm 3 was going for a while, many of the maintainers rolled off to go do other things," said Farina. "A bunch got into the WebAssembly space, and new people had to come up to speed."

Butcher credited the newer maintainers for staying true to Helm's founding principles. "You could end up with new maintainers taking it in a whole different direction, but largely thanks to Matt [Farina] and Scott [Rigby], two of the longer-term contributors, they kept the vision the same and just brought in a bunch of other people to help with the work and bring their own ideas."

Looking ahead

Butcher expects the new plugin system to inspire innovation from the community. "We might start seeing community members build plugins that we look at and say, 'That one is excellent - let's make it a core feature,'" said Butcher.

The maintainers are also exploring new chart formats and emerging technologies such as YAML Script and WebAssembly. "We've got some interesting things that we want to do now that we've enabled ourselves to do them," said Farina.