Helm 4: Server-side Apply, WASM Plugins, and the Helm v3 Maintenance Window

Helm v4.0.0 (released November 2025) is a significant operational release. It re-centers Helm around Kubernetes server-side apply (SSA) semantics, redesigns the plugin surface to support WASM-based extensions alongside legacy plugins, and modernizes the SDK to encourage embedding Helm inside platform tooling. Concurrently, the Helm project published an explicit maintenance timeline for Helm v3 (bug fixes through 2026-07-08 and security fixes through 2026-11-11, with no feature backports). For platform teams, GitOps controllers, and CI/CD pipelines that integrate Helm, these changes require planned validation and migration work.

Quick inventory of what changed

Helm v4 introduces three practical changes you should evaluate:

• Server-side apply: Helm can use the API server to perform merges and track field ownership instead of relying solely on client-side three-way strategic merge logic. This changes apply semantics and conflict modes.

• Rebuilt plugin system with WASM support: The plugin architecture preserves legacy shell/Go plugins and adds a WASM-capable extension model for portable, sandboxed plugins.

• SDK modernizations: The Go SDK exposes modern logging interfaces and embeddable command primitives to make Helm easier to integrate as a library in controllers and platform CLIs.

Additionally, Helm v3 is now in a defined maintenance window: bug fixes only until 2026-07-08 and security fixes only until 2026-11-11. There will be no feature backports.

Server-side apply: what changes and why it matters

Server-side apply delegates merge logic and field ownership to the API server. Concretely:

• Field ownership is recorded in managedFields on Kubernetes objects; conflicting writes surface as server errors rather than being silently merged by the client.
• Interactions between Helm and controllers become explicit: both actors can claim ownership of fields and the API server will arbitrate ownership, which can expose conflicts that previously went unnoticed.
• The client-side lifecycle (render -> three-way-merge -> apply) shifts toward render -> server-side-apply. Charts that relied on Helm's strategic-merge behavior (for example, patching fields controllers normally own) will need inspection and likely changes.

Operational guidance for platform teams:

• Audit templates for writes to controller-managed fields (status, conditions, or controller-maintained annotations). Avoid writing fields that operators own.

• Standardize the field manager string used by Helm runs. Helm v4 exposes a --field-manager flag; choose and document a consistent value (for example, helm-platform-v4) so managedFields are easier to interpret.

• Update CI/CD: expect upgrades that previously auto-merged to fail with 409s. Treat SSA errors explicitly in pipelines and define whether to retry, hand off to an operator, or fail the deployment.

Example: a CI job that uses server-side apply with an explicit field manager and timeout

# CI job: upgrade using server-side apply with an explicit field manager and a reasonable timeout
helm upgrade --install myapp ./charts/myapp \
  --namespace production \
  --server-side \
  --field-manager=helm-ci-v4 \
  --atomic \
  --wait \
  --timeout 10m

Combine --server-side with --atomic and --wait so failed server-side apply operations roll back and surface as job failures.

WASM plugins: portability, distribution, and security trade-offs

Helm v4's plugin redesign keeps legacy shell/Go plugins and adds a WASM extension surface. Key operational impacts:

• Distribution: WASM artifacts are portable across host OSes when a compatible runtime is present, simplifying distribution to heterogeneous CI runners.

• Sandboxing and security: Running plugin logic in a WASM runtime (for example, Wasmtime) reduces the host attack surface compared with arbitrary native binaries, and makes execution constraints easier to enforce.

• Integration: WASM plugins can be embedded in containers or runner images without requiring a host-language runtime, improving portability.

Operational guidance:

• Treat WASM plugins like any signed artifact: verify signatures, record provenance, and include them in release manifests.

• Ensure runners have a compatible WASM runtime when you rely on WASM-mode plugins. Provide a minimal runtime in runner images if needed.

• Maintain backward compatibility: Helm v4 supports legacy plugins so you can migrate incrementally.

Illustrative plugin manifest (schema and fields are illustrative; consult the Helm repo for exact schema):

# plugins/plugin.yaml
name: my-helm-wasm-plugin
version: 0.1.0
type: wasm
wasm: dist/my-plugin.wasm
description: "WASM plugin that validates chart values against org policy"
entry: handler

Install-time tooling should verify signatures and manage deployment of plugin artifacts to CI runners or images.

SDK changes and embedding Helm in platform tooling

The Helm v4 SDK modernization focuses on two practical improvements: integration with standard Go logging abstractions and embeddable command primitives.

• Expect the SDK to accept standard logging adapters so embedded Helm conforms to the host application's logging and telemetry.

• Embeddable commands reduce the need to shell out to the helm binary from controllers, simplifying error handling and observability by returning structured errors and results.

If immediate migration to embedding is impractical, continue to run the CLI hermetically and parse structured output. Example: capture JSON output for programmatic handling in a POSIX shell.

set -euo pipefail
OUTPUT=$(helm upgrade --install myapp ./charts/myapp --namespace infra --server-side --output json)
# Extract fields from the JSON output
echo "$OUTPUT" | jq -r '.release.name, .release.version'

Embedding via the SDK will reduce operational complexity once toolchains migrate, but structured CLI output is a practical interim pattern.

Migration strategy and compatibility checklist

Helm v3's maintenance dates (bugs to 2026-07-08; security to 2026-11-11) make migration planning urgent for high-risk workloads. A pragmatic migration plan:

1. Inventory: list CI pipelines, controllers, and automation that invoke Helm and record chart versions and hooks used.
2. Shadow-test SSA: run Helm v4 with --server-side in staging and log 409 conflicts and other errors.
3. Triage templates: remove or stop templating controller-owned fields; if a chart must manage a field an operator also manages, decide ownership or introduce a CRD-backed pattern.
4. Standardize field-manager: update pipeline templates to pass a consistent --field-manager value.
5. Validate plugins: inventory custom plugins and test both legacy and WASM plugin modes on your runners; plan migrations where portability or sandboxing are priorities.
6. Canary upgrades: prefer canary rollouts and use --atomic, readiness probes, and automated rollback policies; add alerts for SSA conflict rates.
7. Evaluate embedding: if you embed Helm via v3 SDK, test the v4 SDK in non-production focusing on logging and structured errors.

Bottom line for platform teams

• Treat Helm v4 as an operational shift: SSA changes the merge model and will expose conflicts that were previously masked.

• Plan a phased migration based on risk: use the Helm v3 maintenance timeline to prioritize workloads for early migration and leave lower-risk workloads on v3 while security fixes remain available.

• Standardize field-manager strings and capture managedFields in audits so ownership questions are traceable.

• Revisit plugin strategy: WASM plugins improve portability and sandboxing; migrate critical cross-platform plugins and add artifact signing.

• Make embedding a medium-term goal to reduce shell-out complexity and improve telemetry.

Start now with staged SSA validation, an inventory of plugins, and consistent field-manager configuration across pipelines. Those steps will reduce surprises when you move clusters and pipelines onto Helm v4.

Sources

• Helm Blog
• Introducing Helm 4 - Matt Farina & Robert Sirchia, SUSE
• Helm 4.0.0 coverage