What Helm 4 Actually Changed (and What It Did Not)

▶ Watch (0:42)

Helm 4 is the first major release in six years, timed to the project’s 10th anniversary. It adds a WASM-based plugin engine, server-side apply, k-status implementation, and content-addressable chart caching. Existing plugins continue to work. The Charts v2 API is unchanged. A common misconception is that Helm 4 broke existing charts. It did not. Chart API version and Helm tool version are independent, and no v2 charts require modification to run on Helm 4.

Charts v3: What It Unlocks and Why v2 Could Not

▶ Watch (5:11)

Charts v2 sends all resources to the Kubernetes API in a single batch. Changing that would break existing charts, so resource sequencing has been impossible to add. Charts v3 fixes this at the API level. It also enables pluggable render engines, so chart authors can swap Go templates for CUE, YAML script, or other engines. Value transformation between parent and subcharts gets a dedicated plugin type. Helm ignore will finally match git ignore behavior. None of these changes are backported to v2.

Chart-Defined Plugins and the HIP Process

▶ Watch (8:00)

Major changes to Helm go through HIPs, Helm Improvement Proposals, modeled on Python PEPs. The most anticipated HIP covers chart-defined plugins. Today, plugins must be installed globally. Under Charts v3, plugins become chart dependencies, resolved the same way subchart dependencies are today. A working reference implementation already exists. A signer plugin HIP targets cosign and SSH keys as signing mechanisms, replacing PGP. Only a handful of attendees reported signing charts today, which the maintainers attributed directly to PGP’s friction.

OCI Improvements: Registry Mirroring and Policy Enforcement

▶ Watch (14:32)

Helm’s OCI support is shifting away from Docker’s inherited credential model toward the containers tools project, which includes tools like Podman. The registries.conf format allows per-repository credentials on registries like quay.io. policy.json lets organizations block specific registries, such as docker.io, at the client level. Registry mirroring transparently redirects hardcoded chart dependency locations to an enterprise registry, which matters for air-gapped environments where public registry access is blocked. Some of these features are already in the ORAS library Helm uses today.

How to Get Involved Now

▶ Watch (19:35)

The maintainers outlined three concrete entry points. First, read and comment on open HIPs at helm.sh. Second, join the Helm Dev channel on Kubernetes Slack (not CNCF Slack, since Helm predates the CNCF). Third, attend the weekly developer meeting, held every Thursday at 9:30 AM Pacific. A tracking issue in the Helm repository shows exactly where Charts v3 implementation stands. The experimental flag for creating a v3 chart is available in Helm 4 today, though install support is still in progress.

Q&A

Was resource sequencing the most requested Charts v3 feature? Sequencing was cited as the top long-blocked request, with the single-batch API call in v2 given as the reason it could not ship earlier. ▶ 20:57

Notable Quotes

charts v2 is unchanged. Robert Sirchia · ▶ 02:18

it’s not written in Rust. So please don’t ask. Robert Sirchia · ▶ 02:43

PGPG, although it always was only pretty good. Um, it also isn’t pretty good for users, right? It kind of sucks. Scott Rigby · ▶ 11:51

registry mirroring is used in enterprise environments a lot and one of the limitations right now is that you basically are limited by the either your dependencies and they’re hardcoded within the chart. Andrew Block · ▶ 17:22

Key Takeaways

  • Helm 4 is the first major release in six years; existing v2 charts require no changes.
  • Charts v3 enables resource sequencing, pluggable renderers, and cosign chart signing.
  • Registry mirroring via policy.json lets enterprises block public registries at the client level.

About the Speaker(s)

Scott Rigby is a Helm Maintainer at Replicated, a Cloud Native Ambassador, and organizer of CNCF community events including the New York Kubernetes Meetup and New York KCD.

Robert Sirchia is Director of Technical and Community Marketing at SUSE, with over 20 years in technology spanning .NET, Microsoft, and cloud-native infrastructure.

Andrew Block is a Distinguished Architect at Red Hat focused on cloud-native and security practices. He has authored multiple technical publications and contributes frequently to open source communities.