What Is New in Helm 3.0 (summary table)
| Category | Key Highlights |
|---|---|
| New Features | No in‑cluster Tiller, Chart v2 format, Library charts, OCI registry support (experimental), 3‑way strategic merge, JSON schema validation |
| Repository Changes | Default repositories removed; users add repos manually (e.g., https://hub.helm.sh) |
| Compatibility | Most Helm‑2 charts still work; -n now maps to --namespace, crd‑install hooks replaced by crds/ folder |
| Security & Usability | Simplified release storage, removal of rarely‑used static template variables, tighter defaults |
| Deprecations | crd‑install hook, static variables like .Release.Time, default stable repo |
How does Helm 3 remove the need for Tiller?
Helm 3 runs entirely client‑side; it no longer installs a server component inside the cluster. All release information is stored as Kubernetes secrets, which simplifies RBAC and eliminates the extra attack surface that Tiller introduced.
Why this matters
In practice, you can manage releases with a single binary and standard Kubernetes permissions, reducing operational friction.
What are the main changes to the chart format?
Helm 3 introduces Chart v2, consolidating metadata into a single Chart.yaml file and adding support for library charts that act as reusable building blocks.
Why this matters
Developers get a cleaner structure and can share common templates without duplicating resources.
How have Helm repositories been redesigned?
Helm 3 ships with no default repositories. Users explicitly add charts via helm repo add, typically pointing at https://hub.helm.sh or private registries.
Why this matters
This shift gives teams full control over which chart sources are trusted, aligning with modern CI/CD pipelines.
What new upgrade and validation capabilities does Helm 3 provide?
Upgrades now use a 3‑way strategic merge patch, preserving manual edits, and chart values can be validated against a JSON schema defined in the chart.
Why this matters
It reduces drift between desired and live manifests and catches configuration errors early in the deployment process.
Is OCI registry support ready for production?
Helm 3 includes experimental support for storing charts in OCI‑compatible registries such as Docker Distribution. The feature is functional but flagged as experimental.
Why this matters
Teams can start consolidating container images and Helm charts in a single registry, simplifying artifact management.
FAQ
Can I run Helm 2 and Helm 3 side‑by‑side in the same cluster?
No. The two versions store releases differently and conflict when they try to manage the same resources.
How do I migrate existing releases from Helm 2 to Helm 3?
Use the official helm-2to3 plugin or follow the migration guide on the Helm website.
What happened to the crd‑install hook?
It was removed; place CRDs in a crds/ directory and Helm will install them before any other resources.
Why does the -n flag now map to --namespace?
Helm unified flag semantics to match kubectl, reducing confusion when scripting.
Do I need to sign my charts now?
Chart signing is optional, but Helm 3 can verify signatures stored as OCI artifacts or in chart repositories.
For more details, see the official Helm documentation: https://helm.sh/docs/.