Helm 3 Approaches End-of-Life as Project Sets Final Support Milestones for Helm 4 Transition

The Helm project maintainers have formalized the end-of-life roadmap for Helm 3 following the general availability of Helm 4. Under the updated transition schedule documented in project guidelines, the final minor release for Helm 3 is scheduled to ship on September 9, 2026. This release will be strictly limited to Kubernetes client library updates necessary to maintain compatibility with recent Kubernetes API releases, with no new functional features being backported. Security patching for critical vulnerabilities in Helm 3 will continue through February 10, 2027, after which all community maintenance, bug resolutions, and CVE fixes will permanently cease across the v3 development branch. This milestone carries significant consequences for enterprise platform teams, CI/CD pipeline maintainers, and site reliability engineers responsible for fleet-wide application delivery. Helm remains the foundational package management standard across managed Kubernetes environments such as Amazon EKS, Google GKE, and Microsoft Azure AKS. While Helm 4 is designed to preserve backwards compatibility for existing chart formats and in-cluster release secrets without forcing destructive data migrations, lingering on Helm 3 past the maintenance window creates compliance risks and exposes infrastructure pipelines to unpatched security vulnerabilities. Within the larger trajectory of the cloud-native ecosystem, the sunsetting of Helm 3 highlights an industry-wide transition toward declarative infrastructure convergence. Helm 3 relied heavily on client-side three-way merge computations to manage cluster state updates, an approach that often introduced friction and field-ownership conflicts when operating alongside continuous GitOps controllers such as Argo CD and Flux. Helm 4 addresses this long-standing technical debt by fully adopting Kubernetes Server-Side Apply (SSA) and the kstatus readiness evaluation framework, ensuring that the Kubernetes API server natively tracks field ownership and provides deterministic deployment status. In practice, organizations should initiate structured migration testing to transition build runners and developer environments to Helm 4. DevOps teams should review internal automation scripts, Helm plugins, and post-renderer configurations, as Helm 4 modernizes its extension subsystem around WebAssembly (Wasm) runtimes and tightens OCI registry authentication scopes. Because Helm 4 can interact directly with existing Helm 3 release metadata, teams should validate Helm 4 binaries against staging clusters, verify custom values and template execution, and update deployment pipelines well before security support expires in early 2027.