Helm 4.1: What's New, Release History & EOL Status

What Is New in Helm 4.1

Helm 4 is a major evolution of the Kubernetes package manager -- not just an incremental update. It ships breaking changes alongside new architectural patterns, a redesigned plugin system, and a stabilized SDK. Charts written for v2 continue to work without modification.

How Does the New Plugin System Work in Helm 4?

The plugin architecture is completely redesigned. Helm 4 introduces an optional WebAssembly (Wasm) runtime alongside the traditional executable-based approach. Existing plugins keep working as before -- you don't have to migrate anything unless you want the new capabilities.

Three plugin types are now formally supported: CLI plugins, getter plugins, and post-renderer plugins. The system is also designed to allow new plugin types in the future, meaning Helm's core behavior can be customized at more extension points over time.

The biggest practical shift: post-renderers are no longer standalone executables you pass via a path. They must now be registered plugins. Any pipeline that calls helm render --post-renderer ./my-script.sh will need to wrap that script as a proper plugin.

# Register a post-renderer as a Helm plugin first
# Then reference it by name, not path
helm install myapp ./chart --post-renderer my-plugin-name

For reference and example implementations, see the HIP-0026 plugin spec and Helm 4 example plugins.

What Changed with OCI Registry Support?

Two concrete improvements here. First, you can now install a chart by its content digest, which pins you to an exact artifact rather than a mutable tag. If the digest doesn't match what's in the registry, the install is rejected outright.

helm install myapp oci://registry.example.com/charts/app@sha256:abc123...

Second, helm registry login now accepts only the domain name -- not a full URL. This is intentional: it allows authentication to be scoped at different levels within the same registry going forward.

# v4 -- domain only
helm registry login registry.example.com

# v3 style -- no longer accepted in v4
helm registry login https://registry.example.com/

Registry authentication also gets improved OAuth and token handling, which matters when working with private registries that use short-lived credentials.

How Does Server-Side Apply Change Release Behavior?

Helm 4 defaults to Server-Side Apply (SSA) for all new chart installs. In practice, this means Kubernetes handles the field management and conflict resolution on the server, rather than Helm computing and applying a three-way merge client-side.

For upgrades and rollbacks, Helm uses whatever method was already set for that release. If a release was created with Helm 3 (client-side apply), it stays on client-side apply after you upgrade to Helm 4 -- unless you explicitly pass --server-side to override it. This latching behavior prevents unexpected changes to existing release workflows.

# Force SSA on an existing release upgrade
helm upgrade myapp ./chart --server-side

# Force client-side apply on a new install
helm install myapp ./chart --server-side=false

If your cluster runs operators or other controllers that also manage the same resources, SSA significantly reduces the chance of field ownership conflicts. Test this in staging before flipping it on for production releases.

What Are the Multi-Document Values and Custom Template Functions?

Multi-document values let you split a single large values.yaml into multiple YAML files passed together. This is a clean solution for environment-specific configs that would otherwise bloat a single file or require fragile merge tooling.

helm install myapp ./chart \
  -f values/base.yaml \
  -f values/production.yaml \
  -f values/secrets.yaml

Custom template functions extend Helm's built-in Sprig/Go template set with your own logic, delivered through plugins. Rather than hacking around missing functions with complex nested templates or preprocessing steps, you can now register functions directly in the rendering pipeline.

In practice, this is most useful for teams with shared templating patterns -- things like custom label generation, secret name conventions, or environment-specific interpolation -- that previously required either duplicated helpers across charts or a separate pre-render step.

Which CLI Flags Were Renamed or Deprecated?

Two frequently used flags are renamed in Helm 4. The old names still work but produce deprecation warnings, so CI output will get noisy if you don't update your scripts.

Two flags on helm template are deprecated and hidden from help output: --hide-notes and --render-subchart-notes. They never had any effect (template output never includes notes) and will be removed entirely in Helm 5. Remove them from any scripts now rather than chasing a failure in the next major version.

What Does the Stable SDK API Mean for Helm Tooling Authors?

The Helm Go SDK has historically been treated as an internal API -- subject to change without notice between releases. Helm 4 marks the point where breaking API changes are considered done, making it reasonable to build production tooling on top of Helm's Go packages without expecting churn.

Packages have moved to versioned paths, which aligns with standard Go module conventions. If you're importing Helm packages directly, expect import path updates.

// v3 import (old)
import "helm.sh/helm/v3/pkg/action"

// v4 import -- check changelog for exact versioned paths
import "helm.sh/helm/v4/pkg/action"

The stable API also lays the groundwork for Charts v3 -- the next chart format version. Charts v2 continue to work unchanged while the Helm team gathers feedback on what Charts v3 should include.

What Should You Check Before Upgrading to Helm 4?

The Helm team identifies several high-priority items to validate before fully committing to v4 in production pipelines:

• Run your existing charts through helm template and helm install --dry-run with v4 to catch any rendering differences.
• Audit any CI/CD scripts for --atomic and --force flags and replace them with the renamed versions.
• Update any post-renderer integrations -- executables passed directly to --post-renderer will no longer work.
• Test all three plugin types (CLI, getter, post-renderer) that your workflows depend on.
• Verify OCI workflows, especially if you use helm registry login with full URLs in automation.
• SDK consumers should update import paths and run their test suites against the stable v4 API surface.

Helm 4 is still relatively new. Run it alongside v3 in a staging environment before flipping the switch for release pipelines.