Guests: Matt Butcher | Matt Farina
Project/Company: Helm | Fermyon | SUSE
Show Name: KubeStruck
Topics: Kubernetes, CNCF

Helm turned 10 years old this year and just released version 4. The six-year gap since version 3 isn’t a sign of stagnation. It’s a feature. When 70% of Kubernetes users depend on your tool, breaking things becomes unacceptable. Matt Butcher, Co-Creator of Helm and CEO of Fermyon, and Matt Farina, Core Maintainer and Distinguished Engineer at SUSE, explain how Helm evolved from rapid experimentation to production-critical infrastructure—and what version 4 means for the next decade of cloud-native complexity.

The Evolution of Helm’s Release Cadence

Helm’s release timeline tells the story of Kubernetes itself. Butcher announced Helm at the very first KubeCon in 2015. Version 1 to version 2 happened in months. Everyone was experimenting. No one was running Kubernetes in production yet.

The jump from Helm 2 to Helm 3 took three years. Kubernetes was settling into a rhythm. Developers and DevOps teams were learning patterns. The ecosystem was maturing.

Now, six years separate Helm 3 from Helm 4. That extended timeline reflects something important. Helm found its niche. It became the stable tool that teams depend on every day.

“We’ve got an obligation to make it stable and reliable and not surprise people too frequently,” Butcher said. “The ecosystem itself has landed in that stable cadence where Kubernetes is not changing at the velocity it used to be.”

Farina emphasized the principle. “We don’t want to break anybody. There’s just so many people using Helm. If you break it, they’re going to know. They’re going to find you.”

That philosophy mirrors Linux kernel development. Linus Torvalds has the same rule: never break userspace. Helm applies that same standard to Kubernetes package management.

WebAssembly Plugins Solve the Cross-Platform Problem

Helm 4 introduces WebAssembly-based plugins. The old plugin system worked like Git—executable files in the filesystem. That created a fragmentation problem. Developers had to build plugins for Windows, Mac, Linux, and multiple architectures under Linux. Most didn’t bother. The plugin ecosystem stayed disconnected.

WebAssembly changes that. Build once, run everywhere. Helm can now execute the same plugin binary across every operating system and architecture. That opens up the extensibility ecosystem in ways that weren’t possible before.

“We wanted a way to just have plugins where you could build it once and run it in all these places,” Farina said. “WebAssembly isn’t just for the web. It’s being used all over the place.”

The move to WebAssembly plugins aligns with broader industry trends. WebAssembly is becoming the runtime for serverless, edge computing, and secure sandboxing. Helm is positioning itself where the infrastructure is going.

New Chart Format Addresses Modern Complexity

Charts—the packages Helm installs into Kubernetes clusters—haven’t seen major changes in years. That’s changing. Helm 4 refactored internals to enable a new chart major version coming in the next year.

The current chart format was designed for simpler times. Teams installed one thing, maybe with a couple of dependencies. Now workloads are more complex. Umbrella charts. Multi-component applications. Thousands of CRDs in platforms like Crossplane.

Kubernetes is supposed to be declarative. Deploy and let everything reconcile. Reality is messier. Sometimes you need ordering. Sometimes you need nuanced handling of cluster-wide resources.

“How do we enable Helm to make those nuances easy so bigger and more complicated things can really be installed very easily?” Farina asked.

The new chart format will support those use cases while maintaining backward compatibility with existing charts. Teams won’t lose what they’ve already built.

Managing CRDs and Platform Engineering Challenges

Custom Resource Definitions exploded in usage. They were designed as kernel extensions to Kubernetes. Now they’re everywhere. Platforms install hundreds or thousands of them. That creates stability challenges.

“How do you play in these ecosystems where you’ve got lots of CRDs which are cluster wide, and you don’t want to impact people in a negative way?” Farina said. “The big thing with all of this is stability. You don’t want to break or impact people negatively. How do we not take down somebody’s production environment?”

Butcher shared an example that crystallized Helm’s flexibility. Fermyon builds serverless WebAssembly platforms. When they started deploying those workloads with Helm, everything just worked. No adaptations needed. The CRD system inside Kubernetes and Helm’s design made it seamless.

“That’s one of the testaments to both Kubernetes and Helm as far as how they’ve evolved over time,” Butcher said. “As new things arise, they just continue to work.”

The Next Phase: Taming Cloud-Native Complexity

Helm’s next major challenge is managing complexity at scale. Cloud-native started with microservices. Now it’s multi-part, conglomerate applications. The sophistication keeps increasing. Enterprises are running applications they’ll operate for decades.

“The next major phase in Kubernetes is going to be dealing with the complexity that we’ve created in order to build a more sophisticated set of applications,” Butcher said. “Helm’s big challenge going forward will be to become the tool to manage some of that complexity.”

Farina echoed that vision. Helm 4 sets up a foundation for continuous iteration. The team can now add features and shape where Helm goes based on real-world platform engineering needs.

“We’re looking at how can we better install things into clusters and better manage them,” Farina said. “How can we take what Helm does and do it better for the workloads that are out there?”

Helm celebrated 10 years at KubeCon Atlanta. It started at the very first KubeCon. It was one of the first CNCF projects. Now it’s the infrastructure tool that 70% of Kubernetes users can’t live without. The six-year journey to Helm 4 proves that sometimes slow and steady wins the race—especially when stability matters more than speed.