Helm, the Kubernetes application package manager, has officially reached version 4.0.0. Helm 4 is the first major upgrade in six years, and also marks Helm’s 10th anniversary under the guidance of the Cloud Native Computing Foundation (CNCF). The update aims to address several challenges around scalability, security, and developer workflow.
Helm 4’s SDK features several enhancements designed to enhance integration and developer experience. It adopts modern Go logging interfaces to facilitate multi-logger support and allows Helm’s functionality to be embedded directly into other applications through embeddable commands. Helm 4 also now offers native support for server-side apply (a Kubernetes feature that moves the logic from the kubectl apply command into the API server). This change reflects a broader trend in that direction in the Kubernetes ecosystem, ensuring that integrations built on top of Helm are both powerful and physically coherent with modern cluster behaviour.
The plugin system has also been rebuilt: traditional Helm plugins still function, but users can now also write plugins in WebAssembly (WASM) for broader portability. Additionally, there are improvements in chart distribution, performance, and mechanisms for chart signing and testing automation.
These changes reflect both new features and a revisiting of design debt accumulated during the Helm v3 era, according to a blog post by Helm co-founder Rimantas Mocevicius.
HIP-0012 (Helm Improvement Proposal), the proposal guiding Helm 4, set a schedule beginning with planning in late 2024, followed by engineering through mid-2025 and release by November 2025. It emphasised feature development that the team could deliver in a reasonable timeframe, carefully introducing breaking changes. Improvements targeting Kubernetes integration, such as server-side apply (SSA), modern plugin architecture, and chart API refinements, were part of the roadmap. Problems with contributor engagement and maintenance backlog were also recognised and addressed via process improvements.
From the broader user perspective, Jimmy Song, writing on his blog, captures how the release “moves beyond a templating tool” and modernises Helm. He suggests that adding SSA aligns it much closer with GitOps methods, and that having reproducible builds, WASM for plugins, and tools like kstatus for status parsing bring it up to date with the modern Kubernetes paradigm. Song suggests that these changes mean that Helm is shifting from being more than a chart renderer to being more of a deployment orchestrator.
One of the more contentious issues in the Helm ecosystem concerns support for Custom Resource Definitions (CRDs). A proposal for more robust CRD updating behaviour, including merging new versions, appending to version lists, preserving metadata, and ensuring rollback paths for backwards compatibility, has been submitted for inclusion. However, as of Helm 4’s initial release, these proposals have not been incorporated. Helm still installs CRDs placed in a special `crds/` directory at chart installation, but will not to upgrade or delete CRDs through its normal upgrade process. Existing documentation warns that updated CRDs in the crds folder are skipped with only warnings, not applied.
Community feedback reflects disappointment at this omission. In a Reddit discussion shortly after the release, users asked if CRD behaviour had improved. One user commented “Still no improvements on the CRD front? ::(” noting that Helm remains unable to safely manage CRD lifecycles. Another user reported that their organisation’s tooling and CLI workflows rely on annotation-based CRDs, and adapting to any changes in Helm’s CRD logic will be non-trivial.
Other commentary, such as that from Heinan Cabouly, argues that GitOps tools like Argo CD had already solved some of Helm’s biggest workflow gaps years earlier, implying Helm 4 feels more like catch‑up than reinvention. Helm 4 is, however, still acknowledged as a significant milestone that improves the project’s long‑term viability rather than an incremental patch.
Practitioners and bloggers have welcomed Helm 4’s deployment safety improvements, especially new readiness-based controls that reduce race conditions between dependent components during rollouts. Pierre-Louis Gueugnon, writing for Enix, praises the smarter, content-based chart cache and performance improvements, which are seen as practical quality-of-life upgrades for teams doing frequent, large-scale deployments.
Looking forward, the Helm maintainers have indicated that features not initially adopted for v4 may be considered in minor releases or even Helm 5. The community will be watching closely for when CRD upgrades become safe, stable, and documented enough to be broadly adopted.
