Skip to main content

Helm 4.0 Released: The 6-Year Wait for Server-Side Apply, WebAssembly Plugins, and the End of Merge Conflicts

· 19 min read

Published: November 30, 2025 | Reading time: 18 minutes

TL;DR​

Helm 4.0.0 was released November 12, 2025 at KubeCon Atlanta—the first major version in 6 years. The headline feature is Server-Side Apply (SSA) as default, which fixes the long-standing conflict between Helm and GitOps tools like ArgoCD and Flux. Other major changes include WebAssembly-based plugins (breaking for post-renderers), OCI digest support for supply chain security, and performance improvements of 40-60% for deployments. Helm 3 receives security patches until November 2026, so there's no rush—but organizations should start testing now. Budget 8-12 weeks for migration if you have custom post-renderers.

Key Statistics​

MetricValueSourceDate
Helm adoption rate75-87%CNCF Annual Survey 2024Nov 2024
Time since Helm 36 yearsHelm 3.0 released Nov 2019Nov 2025
SSA performance improvement40-60% fasterKubernetes SIG-CLI benchmarks2024
CI/CD pipeline improvement20-30%Community reportsNov 2025
Helm 3 support windowUntil Nov 2026helm.sh officialNov 2025
GitHub Stars28,000+github.com/helm/helmNov 2025
CNCF project tenure10 yearsCNCF announcementNov 2025
Helm charts ecosystem20,000+Artifact HubNov 2025

Helm powers 75-87% of Kubernetes deployments according to the CNCF's 2024 Annual Survey. It's the de facto standard for packaging and deploying Kubernetes applications. Yet for years, a fundamental friction existed: Helm's three-way merge strategy conflicted with GitOps tools like ArgoCD and Flux.

Here's the scenario that played out in organizations everywhere: A platform team configures ArgoCD with Server-Side Apply (SSA) by default. A developer runs helm upgrade to deploy a hotfix. ArgoCD's next reconciliation loop detects "drift"—fields have changed outside of Git. Alerts fire. The developer asks "who changed my deployment?" Nobody did—the tools were fighting over field ownership.

Helm 4 fixes this. Server-Side Apply is now the default. Helm speaks the same field ownership language as ArgoCD, Flux, and kubectl apply. The "merge conflict" era is over.

But there's a catch: breaking changes are real. Post-renderers must be rewritten as WebAssembly plugins. CLI flags have changed. Some teams testing the beta reported friction. Is Helm 4 worth adopting now, or should you wait?

This guide covers everything platform engineers need to know: the technical changes, the migration path, the timeline, and the decision framework for when to upgrade.

Quick Answer​

What happened: Helm 4.0.0 released November 12, 2025 at KubeCon Atlanta after 6 years of development.

Key change: Server-Side Apply replaces three-way merge as the default apply mechanism, enabling GitOps tool coexistence.

Performance impact: 40-60% faster deployments from reduced API calls; 20-30% faster CI/CD pipelines overall.

Breaking changes: Post-renderers require WebAssembly plugins (Go binaries no longer work), CLI flag renames, plugin SDK restructured.

Support timeline: Helm 3 receives security patches until November 11, 2026—one year from Helm 4 release.

Upgrade decision: Upgrade now if you're already using ArgoCD/Flux (SSA experience), starting greenfield projects, or need WASM extensibility. Wait 3-6 months if relying on custom post-renderers, complex Helm hooks, or following conservative change management practices.

🎙️ Listen to the podcast episode: Episode #042: Helm 4 Deep Dive - 24-minute extended episode covering SSA technical deep-dive, WASM plugin migration, breaking changes by impact level, and detailed 12-week migration timeline.

The 6-Year Journey: Why Helm 4 Took So Long​

The Helm Timeline​

To understand why Helm 4 matters, you need to understand the journey:

  • 2015: Helm created by Deis (later acquired by Microsoft)
  • 2016: Helm 2 introduces Tiller, the in-cluster component
  • 2018: Helm becomes a CNCF incubating project
  • November 2019: Helm 3.0 removes Tiller, becomes CNCF graduated project
  • 2020-2024: Incremental 3.x releases with SSA support added as opt-in
  • November 12, 2025: Helm 4.0 released at KubeCon Atlanta, marking 10-year anniversary

Six years between major versions. For comparison, Kubernetes releases a new minor version every 4 months. What took so long?

Why the Wait Was Necessary​

The Helm maintainers weren't being slow—they were being strategic:

  1. Server-Side Apply needed to mature. SSA reached GA in Kubernetes 1.22 (August 2021), but adoption patterns needed to stabilize. Making SSA the default meant waiting for the ecosystem to establish consistent field ownership conventions.

  2. GitOps tool alignment. ArgoCD and Flux both adopted SSA before Helm. The maintainers waited to ensure Helm's SSA implementation would be compatible with existing GitOps workflows, not introduce new conflicts.

  3. Plugin security concerns. The old post-renderer model allowed arbitrary binary execution—a security nightmare. Designing and implementing the WebAssembly sandbox took time.

  4. Chart ecosystem compatibility. With 20,000+ charts in the ecosystem, breaking changes needed careful consideration. The maintainers ran extensive compatibility testing.

Key Takeaway

Helm 4's 6-year development cycle wasn't hesitation—it was waiting for Kubernetes Server-Side Apply to mature and for the ecosystem to establish consistent field ownership patterns. The result is a release that works with GitOps tools rather than fighting them.

Server-Side Apply: The Headline Feature That Changes Everything​

What SSA Actually Is​

To understand why SSA matters, you need to understand what it replaces.

Three-way merge (Helm 3 default):

  1. Fetch current state from API server
  2. Fetch last-applied-configuration annotation
  3. Calculate diff between desired state, current state, and last-applied
  4. Apply the diff

This approach has a fundamental problem: the last-applied-configuration annotation only tracks what the last apply set. If another tool (ArgoCD, kubectl, HPA) modifies the resource, Helm doesn't know which fields belong to whom.

Server-Side Apply (Helm 4 default):

  1. Send full desired object to API server
  2. API server tracks field ownership in managedFields metadata
  3. Each manager (Helm, ArgoCD, kubectl) owns specific fields
  4. Conflicts are detected and reported at apply time

The critical difference: field ownership is tracked at the API server level, not in a client-side annotation. Every tool that touches a resource participates in the same ownership model.

The GitOps Peace Treaty​

Here's the scenario that plagued organizations before SSA:

1. ArgoCD deploys nginx with replicas=3 (using SSA)
2. HPA scales to replicas=5 based on load
3. Developer runs `helm upgrade` with replicas=3 in values
4. Helm's three-way merge overwrites HPA's setting
5. ArgoCD detects "drift" - replicas changed outside Git
6. Alerts fire, confusion ensues

With Helm 4's SSA default:

1. ArgoCD deploys nginx with replicas=3 (SSA, owns replicas)
2. HPA scales to replicas=5 (SSA, takes ownership of replicas)
3. Developer runs `helm upgrade` (SSA, doesn't own replicas)
4. Helm respects HPA's ownership - replicas stay at 5
5. ArgoCD sees no drift - everyone respects managedFields
6. Peace and harmony

The managedFields metadata now shows exactly who owns what:

managedFields:
  - manager: helm
    operation: Apply
    fieldsV1:
      f:metadata:
        f:labels:
          f:app.kubernetes.io/managed-by: {}
      f:spec:
        f:template:
          f:spec:
            f:containers: {}
  - manager: argocd-controller
    operation: Apply
    fieldsV1:
      f:spec:
        f:replicas: {}

Performance Benefits of SSA​

SSA isn't just about correctness—it's faster.

Three-way merge requires:

  • GET current resource (1 API call)
  • Read last-applied-configuration
  • Calculate diff client-side
  • PATCH or PUT to apply (1 API call)

Server-Side Apply requires:

  • PATCH with full object (1 API call)

For a release with 50 resources, three-way merge makes 100+ API calls. SSA makes 50. At scale—hundreds of resources per release, frequent deployments—the difference compounds.

Community benchmarks report:

  • 40-60% faster deployment times for resource-heavy releases
  • 20-30% improvement in CI/CD pipeline duration end-to-end

For a platform team deploying hundreds of times per day, that translates to hours saved and reduced API server load.

Key Takeaway

Server-Side Apply isn't just a performance improvement—it's a correctness improvement. Multiple tools managing the same Kubernetes resource now works correctly by default, eliminating the merge conflict nightmares that made Helm controversial in GitOps environments.

WebAssembly Plugin System: Security Through Sandboxing​

Why WASM?​

Helm's post-renderer feature allowed custom processing of rendered manifests before applying. The implementation was simple: shell out to any executable. Powerful, but dangerous.

The security problems with arbitrary binary execution:

  • No sandboxing—full host access
  • Supply chain risk from untrusted binaries
  • Platform-specific binaries (Linux/Mac/Windows)
  • No standardized interface for capabilities

Helm 4 replaces this with WebAssembly plugins using the Extism runtime:

  • Sandboxed execution: WASM modules run in isolation
  • Cross-platform: Same module works everywhere
  • OCI distribution: Plugins distributed alongside charts
  • Capability-based security: Explicit grants for file access, network, etc.

The kstatus Plugin: A Practical Example​

One of the first official Helm 4 plugins demonstrates the value. The kstatus plugin enables deployment readiness tracking beyond "resource created."

Before kstatus, Helm's --wait flag only checked that resources existed in the API server. With kstatus integration:

metadata:
  annotations:
    helm.sh/readiness-success: "status.conditions[?(@.type=='Ready')].status=='True'"
    helm.sh/readiness-failure: "status.conditions[?(@.type=='Failed')].status=='True'"

Helm now waits for actual readiness—pods running, endpoints available, CRDs reconciled. This catches a whole class of "deployment succeeded but nothing works" scenarios.

Migration Impact for Post-Renderer Users​

This is the highest-friction breaking change in Helm 4.

If you use custom post-renderers (shell scripts, Go binaries, etc.):

  • They will not work with Helm 4
  • You must rewrite them as WASM plugins
  • Extism provides SDKs for Rust, Go, JavaScript, and other languages
  • Budget significant engineering time for this conversion

Migration steps:

  1. Inventory all post-renderers in your organization
  2. Evaluate which ones are still needed
  3. Choose implementation language (Rust for performance, Go for familiarity)
  4. Rewrite using Extism SDK
  5. Distribute via OCI registry alongside charts
  6. Test extensively before production

For organizations with complex post-render pipelines, this alone may delay Helm 4 adoption by months.

Key Takeaway

The WebAssembly plugin system trades convenience (any binary works) for security (sandboxed, verifiable plugins). If your organization uses custom post-renderers, budget time for rewriting them—this is the highest-friction breaking change in Helm 4.

The Complete Breaking Changes Inventory​

High Impact Changes​

1. Post-renderers require WASM plugins

As covered above, Go binaries and shell scripts no longer work as post-renderers. This affects any organization with custom manifest processing.

2. Server-Side Apply behavioral differences

SSA is more strict about field ownership. Some patterns that worked with three-way merge will fail:

  • Controllers that assume they own all fields
  • Operators that patch without declaring ownership
  • Rollback scenarios where field ownership changed

Testing is essential before production migration.

3. Annotation changes

The last-applied-configuration annotation is no longer used. Any tooling that depends on parsing this annotation must migrate to using managedFields.

Medium Impact Changes​

1. CLI flag renames

Several flags changed for consistency:

Helm 3Helm 4Notes
--dry-run=client--dry-run=serverServer-side now default
--force--force-replaceClarifies behavior
Various plugin flagsRestructuredCheck plugin docs

CI/CD pipelines using these flags need updates.

2. Plugin SDK restructured

Third-party plugins built on the Helm 3 SDK may not work. Check compatibility before assuming plugins work.

3. Deprecated APIs removed

Legacy v3 APIs that were deprecated are now gone. Chart developers using deprecated fields need to update.

Low Impact Changes (But Still Notable)​

1. Content-based caching

Helm 4 uses hash-based caching instead of version-based. This eliminates cache collisions when chart versions are reused with different content (a common practice in development).

2. OCI digest support

Charts can now be referenced by digest, not just tag:

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

This is significant for supply chain security—digest references are immutable.

3. Multi-document values

Values files can now contain multiple YAML documents. This enables cleaner organization of complex value sets.

Key Takeaway

The most disruptive change isn't SSA (which improves things)—it's the WASM-only post-renderer requirement. Audit your tooling now: any shell scripts or Go binaries in your post-render pipeline must be converted before Helm 4 adoption.

Helm 4 vs Alternatives: Decision Framework​

With Helm 4 adopting SSA, one of the main arguments for alternatives has weakened. Let's assess the landscape:

Comparison Table​

CapabilityHelm 4KustomizeCarvel (ytt/kapp)Jsonnet
ApproachTemplating + valuesPatch overlaysStarlark templatesFull language
Apply mechanismSSA (default)SSA (kubectl)kapp (SSA-like)kubectl
Package distributionOCI, ChartMuseumGit reposOCIGit repos
Ecosystem size20,000+ chartsN/A (patches)GrowingAcademic
Learning curveModerateLowModerate-HighHigh
GitOps integrationArgoCD, FluxNative kubectlCarvel toolsCustom
Rollback supportBuilt-inGit revertkapp rollbackManual

When Helm 4 is the Right Choice​

Choose Helm 4 if:

  • You have an existing investment in Helm charts (most organizations)
  • Your team is familiar with Go templating
  • You need semantic versioning and rollback for packages
  • You're using ArgoCD or Flux with Helm sources
  • You want access to the largest ecosystem of pre-built charts

When Alternatives May Be Better​

Choose Kustomize if:

  • You prefer patching over templating (no template language to learn)
  • You want native kubectl integration without additional tooling
  • Your customizations are primarily value overrides, not logic

Choose Carvel (ytt/kapp) if:

  • You need Starlark programmability (loops, conditionals, functions)
  • You want kapp's apply ordering and wait semantics
  • You're already invested in the Carvel ecosystem

Choose Jsonnet if:

  • You need a full programming language for manifest generation
  • You're in an environment that standardized on Jsonnet (some Google-adjacent orgs)
  • Academic or research contexts where Jsonnet expertise exists

The SSA Factor​

Before Helm 4, a common argument was: "Kustomize uses SSA, Helm causes merge conflicts." That argument is now obsolete. Both use the same underlying mechanism.

The choice now comes down to:

  • Templating preference (Go templates vs patches vs full language)
  • Ecosystem leverage (20,000 charts vs build your own)
  • Organizational momentum (what teams already know)

Key Takeaway

Helm 4's SSA adoption eliminates the "GitOps incompatibility" argument that pushed teams toward Kustomize. Both now use the same underlying mechanism. Choose based on templating preference (Go templates vs patches), not apply semantics.

The Real Migration Guide: 12-Week Plan​

Phase 1: Assessment (Week 1-2)​

Inventory your Helm estate:

# List all releases across all namespaces
helm list -A --output json > helm-inventory.json

# Count releases per namespace
helm list -A -o json | jq -r '.[].namespace' | sort | uniq -c

# Identify Helm versions in use
helm version --short  # Check each cluster

Document critical paths:

  • Which releases are in production?
  • Which have custom post-renderers?
  • Which use third-party plugins?
  • What's the deployment frequency?

Identify risks:

  • Post-renderers that need WASM conversion
  • Third-party plugins without Helm 4 support yet
  • CI/CD pipelines with hardcoded CLI flags

Phase 2: SSA Testing (Week 3-6)​

Helm 3.16+ supports SSA as an opt-in flag. Test before upgrading:

# Enable SSA for a specific upgrade
helm upgrade myrelease mychart --server-side

# Compare behavior with current approach
helm upgrade myrelease mychart --dry-run=server

What to watch for:

  • Drift detection changes in ArgoCD/Flux
  • HPA/VPA interaction with managed fields
  • Custom controllers that assume field ownership
  • Monitoring that parses last-applied-configuration

Test matrix:

  1. Simple deployments (stateless apps)
  2. StatefulSets with persistent storage
  3. Resources managed by operators
  4. Resources with HPA/VPA autoscaling
  5. CRDs and custom controllers

Phase 3: WASM Plugin Migration (Week 4-8)​

If you have custom post-renderers, this is the long pole:

Step 1: Audit existing post-renderers

# Find all post-renderer references in your pipelines
grep -r "post-renderer" .gitlab-ci.yml Jenkinsfile .github/workflows/

Step 2: Categorize by complexity

  • Simple transformations (add labels, modify annotations)
  • Complex logic (conditionals, external data lookup)
  • Integration with external systems (secrets managers, etc.)

Step 3: Choose implementation language

  • Rust: Best performance, steep learning curve
  • Go: Familiar to Kubernetes teams, good Extism support
  • JavaScript: Easiest for simple transformations

Step 4: Implement and test

# Build WASM plugin
extism-go build -o my-plugin.wasm

# Test locally
helm template mychart --post-renderer ./my-plugin.wasm

# Distribute via OCI
oras push registry.example.com/helm-plugins/my-plugin:v1 my-plugin.wasm

Phase 4: Staged Rollout (Week 8-12)​

Development clusters first:

  • Install Helm 4 alongside Helm 3 (different binary name)
  • Migrate non-critical releases
  • Validate monitoring and alerting

Staging environment:

  • Production-like workloads
  • Full CI/CD pipeline testing
  • Performance benchmarking (compare deployment times)

Production migration:

  • Start with low-risk releases
  • Maintain rollback capability (keep Helm 3 binary available)
  • Monitor for unexpected behavior
  • Gradual rollout over multiple deployments

Common Migration Errors​

  1. Forgetting CI/CD flag updates: --dry-run=client becomes --dry-run=server
  2. HPA conflicts: SSA changes field ownership; test autoscaler interactions
  3. Third-party plugin incompatibility: Check each plugin's Helm 4 support status
  4. Monitoring breakage: Tools parsing last-applied-configuration need updates

Key Takeaway

Budget 8-12 weeks for Helm 4 migration. The SSA transition itself is low-risk if you test first, but WASM plugin conversion and third-party compatibility are the long poles. Helm 3 support until November 2026 means no rush—plan carefully.

Community Sentiment and Adoption Curve​

Early Adopter Feedback​

From KubeCon Atlanta and community forums:

Positive signals:

  • Performance improvements validated (40-60% deployment time reduction confirmed)
  • SSA migration smoother than expected for ArgoCD/Flux users
  • OCI digest support praised for supply chain security

Pain points:

  • WASM plugin learning curve steeper than expected
  • Some third-party plugins not yet Helm 4 compatible
  • Documentation still catching up for edge cases

What the Skeptics Say​

Not everyone is celebrating:

  • "SSA should have been the default years ago—this is just catching up"
  • "WASM plugins are overkill for simple post-rendering; shell scripts were fine"
  • "Breaking post-renderers will delay adoption by 6+ months for many orgs"

These critiques have merit. The WASM migration burden is real, and organizations with complex post-render pipelines face significant work.

Adoption Timeline Prediction​

Based on historical Helm adoption patterns and current community signals:

  • Month 1-3: Early adopters, greenfield projects, organizations already using SSA
  • Month 3-6: GitOps-first teams (ArgoCD/Flux users), organizations with simple charts
  • Month 6-12: Mainstream adoption, plugin ecosystem matures, third-party compatibility improves
  • Month 12+: Legacy Helm 3 migrations, late adopters, highly regulated industries

What Helm 4 Means for Platform Teams​

Immediate Implications​

For platform engineers:

  • Standard Helm charts now GitOps-compatible by default
  • Fewer "drift detection" false alarms from ArgoCD/Flux
  • Performance budgets can be more aggressive (faster deployments)

For developers:

  • helm upgrade no longer fights with GitOps controllers
  • Clearer error messages when field ownership conflicts occur
  • Better rollback behavior with SSA field tracking

Strategic Implications​

WASM plugin ecosystem will grow: Helm 4's plugin architecture enables a new category of Helm extensions. Expect security scanning plugins, policy enforcement plugins, and integration plugins to emerge.

OCI-first distribution aligns with security trends: The industry is moving toward supply chain security (SLSA, Sigstore). Helm 4's digest support and OCI distribution fit this direction.

Helm's CNCF position strengthens: As a 10-year graduated project with renewed momentum, Helm's role as the standard Kubernetes package manager is reinforced.

What to Tell Leadership​

Translating technical changes to business value:

  • "Helm 4 reduces GitOps friction" = Fewer incidents from tool conflicts, faster deployments, less ops toil
  • "Migration has a 12-month runway" = No emergency, plan strategically, align with other initiatives
  • "WASM plugins improve security" = Reduced attack surface, better compliance posture, future-proof architecture
  • "40-60% faster deployments" = Quantifiable developer productivity improvement, reduced CI/CD costs

Conclusion: The Path Forward​

Helm 4 is the update the Kubernetes ecosystem needed. Server-Side Apply adoption, security improvements through WASM sandboxing, and performance gains from reduced API overhead. The 6-year wait was worth it for the alignment with GitOps patterns.

But upgrading isn't urgent. Helm 3 receives security patches until November 2026. Organizations should:

Immediate Actions (This Week)​

  1. Test SSA in Helm 3.16+: Run helm upgrade --server-side on non-production releases
  2. Inventory post-renderers: Identify any custom binaries or scripts in your Helm workflows
  3. Check third-party plugins: Verify Helm 4 compatibility with your plugin vendors

Near-Term Actions (Next 30 Days)​

  1. Create migration timeline: Plot your 8-12 week migration against other initiatives
  2. Budget WASM development time: If you have post-renderers, allocate engineering resources
  3. Update runbooks: Document new CLI flags and SSA-specific troubleshooting

Medium-Term Actions (Q1 2026)​

  1. Pilot Helm 4 in development: Validate full workflow before production
  2. Migrate staging environments: Test with production-like workloads
  3. Begin production rollout: Gradual migration with rollback capability

The Helm 4 release marks a maturation milestone. Kubernetes package management is no longer fighting GitOps—it's aligned with it. For the 75-87% of organizations using Helm, that's worth celebrating.

Resources​

Official Documentation​

Platform Engineering Playbook Coverage​

Technical Deep Dives​

Stay Updated: Helm Blog | #helm on Kubernetes Slack | Helm GitHub