Helm—the package manager for Kubernetes—has officially entered a new era with the release of Helm v4. This release brings major architectural changes, a modernized ecosystem, security enhancements, and a long-awaited overhaul of Helm’s plugin system. While Helm 4 maintains strong backward compatibility with existing charts, it also introduces several breaking changes and shifts in behavior that teams must understand before upgrading.

In this post, we’ll walk through:

• 🆕 The biggest new features in Helm 4
• ⚠️ Breaking changes from Helm 3 → 4
• 🛠️ A simple step-by-step guide to migrating to Helm 4

Let’s dive in.

 What’s New in Helm 4?

Helm 4 is packed with improvements focused on extensibility, performance, stability, and security. Here’s a breakdown of the most important updates.

🔌 1. Overhauled Plugin System (Including WebAssembly Plugins)

Helm 4 introduces a redesigned plugin architecture with support for Wasm-based plugins, allowing plugins to run in a sandboxed environment for enhanced security.

Highlights:

• Optional WebAssembly runtime
• Expanded plugin capabilities (CLI, getter, post-renderer, and more coming)
• More customization over Helm’s core execution paths
• Backwards compatibility: existing Helm 3 plugins still work

This is one of the most transformative parts of Helm 4 and paves the way for new ways to extend Helm’s behavior.

🔍 2. kstatus Integration for Better Resource Monitoring

Helm 4 brings improved deployment visibility with kstatus support. This enables Helm to display detailed resource statuses—especially useful for complex apps and custom controllers.

You’ll now get clearer insights into:

• Whether resources are progressing
• Stalled deployments
• Reconcile delays
• Rollout issues

🔐 3. Enhanced OCI Support (Install Charts by Digest)

Helm 4 improves supply-chain security with support for installing charts by digest, ensuring you deploy the exact artifact intended.

Example:

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

If the digest doesn’t match, Helm simply refuses to install.

🗂️ 4. Multi-Document Values

You can now split values.yaml into multiple YAML files.

Perfect for:

• Environment-specific configs
• CI-driven values
• Layered configuration structures

Example:

helm install myapp . --values values-prod.yaml --values values-network.yaml

🤝 5. Server-Side Apply Support

With Server-Side Apply, Helm 4 resolves conflicts more intelligently when multiple tools (e.g., operators, GitOps, controllers) modify the same resource.

This enhances reliability in:

• Highly automated clusters
• GitOps flows
• Multi-team shared resource environments

🔧 6. Custom Template Functions (via Plugins)

Helm 4 allows plugin authors to register custom template functions, giving organizations the ability to implement:

• Custom string manipulation
• Internal formatting logic
• Specialized rendering helpers

This brings a new level of customization to Helm’s Go template engine.

🏎️ 7. Performance Improvements

Helm 4 ships with significant performance gains:

• Faster dependency resolution
• Content-based caching
• Improved chart loading efficiency

Especially noticeable in large enterprise charts.

🛡️ 8. Security & Auth Enhancements

• Better OCI registry authentication
• OAuth/token improvements
• Stricter TLS handling

These improvements support secure CI/CD pipelines and hardened supply chains.

🧰 9. Modernized Codebase

Helm 4 completes major modernization efforts:

• Migrated to Go 1.24
• Switched logs to slog for modern structured logging
• Cleaned and simplified internal dependencies
• Introduced stable SDK APIs

This gives Helm a cleaner foundation for years of future development.

⚠️ Breaking Changes in Helm 4

While Helm 4 strives to remain compatible with existing charts, a few breaking changes require attention.

❌ 1. Post-Renderers Must Now Be Plugins

In Helm 3, you could pass an executable script directly:

helm template . --post-renderer ./myfilter.sh

In Helm 4, this no longer works.

You must reference a post-renderer plugin instead:

helm template . --post-renderer my-post-plugin

This will require updates to CI pipelines and automation scripts.

❌ 2. CLI Flag Renames (Old Flags Still Work but Emit Warnings)

• --atomic → --rollback-on-failure
• --force → --force-replace

Old flags still function but are marked as deprecated—update CI/CD to avoid future breakage.

❌ 3. Plugin Architecture Changes

Although Helm 3 plugins still work, plugin developers must update code to the new APIs if they want to take advantage of Helm 4’s expanded capabilities.

Some custom or tightly-coupled plugins may break.

❌ 4. Post-renderer workflows may break

If your workflow depends on piping rendered manifests into an external tool, that may no longer behave the same way.

🧭 How to Upgrade from Helm 3 to Helm 4 (Simple Guide)

Migrating from Helm 3 to Helm 4 is straightforward if you follow a safe path.

---

✅ Step 1: Test Helm 4 in a Sandbox

Before upgrading production environments:

• Install Helm 4 locally
• Deploy a test release using your existing Helm 3 charts
• Validate rendering, installation, rollback, and upgrades

Example:

helm4 install test-release ./mychart

✅ Step 2: Validate All Plugins

Test all three plugin types:

• CLI plugins
• Getter plugins
• Post-renderer plugins

Check if any need modification.

If you previously used a post-renderer script → rewrite it as a plugin.

✅ Step 3: Update CI/CD Pipelines

Look for:

• Deprecated flags
• Hard-coded post-renderers
• Custom automation scripts
• Registry login workflows
• Digest-based installs

Run pipelines with Helm 4 in a non-prod environment before rollout.

✅ Step 4: Validate Registry Authentication

Test:

helm registry login
helm pull oci://...
helm install ...

Ensure private registry integrations still work.

✅ Step 5: Test New Features with Your Charts

Try:

• Multi-document values
• Digest-based installs
• Server-side apply
• Custom template functions

These features were designed to improve real-world workflows—see where they fit your environment.

✅ Step 6: Roll Out Helm 4 Gradually

Recommended approach:

1. Upgrade dev environment
2. Upgrade staging
3. Upgrade production once CI/CD and charts are validated

Most teams will find direct adoption easy once post-renderers and flags are handled.

🎯 Conclusion

Helm 4 is the most ambitious Helm release since Helm 3, introducing a modernized platform, stronger security, enhanced extensibility, and more powerful tooling. While there are a few breaking changes—especially around post-renderers and CLI flags—the migration path is smooth for most teams.

If you’re using Helm in CI/CD pipelines, GitOps platforms, or large-scale Kubernetes clusters, now is the time to start testing Helm 4 and unlocking its new capabilities. See the official release here: https://helm.sh/docs/overview/