Helm vs Kustomize: When to Use Each (and When to Combine)

Helm and Kustomize both solve the same problem — configuring an app across environments — but with completely different philosophies.

Helm is templating plus release management

• Go templates with values; {{ .Values.image.tag }} gets substituted at install time.
• Built-in install, upgrade, rollback, and history — release state stored as a Kubernetes Secret in the cluster.
• Subcharts for dependencies; hooks for migrations; OCI distribution for sharing.
• Cost: learning Go templates plus Sprig; whitespace bugs; templating language layered on YAML.

Kustomize is pure YAML overlays

• A base of plain Kubernetes YAML; overlays are YAML patches applied via kustomization.yaml.
• Built into kubectl — kubectl apply -k ./overlays/prod.
• No templating language — your YAML linter works; engineers read Kubernetes YAML directly.
• Cost: no release history, no hooks, more verbose for deeply varied configurations.

When Helm wins

• Distributing an application for others to install — third-party charts like ingress-nginx, cert-manager, prometheus-stack.
• Apps with DB migrations or setup Jobs — hooks orchestrate them in the lifecycle.
• Native rollback and history — helm rollback + helm get manifest --revision N for incident review.
• Heavily parameterized apps with 50+ tunable values — values-driven beats patch-driven.

When Kustomize wins

• Internal microservices with straightforward environment overlays.
• Teams that prefer readable YAML without a templating DSL.
• Tight ArgoCD or Flux GitOps where Git is the sole source of truth and rollback = Git revert.
• Already using kubectl apply -k — no extra tooling to install.

The common pattern in practice

• Most teams combine both: Helm for third-party components (the charts already exist and are well-tested), Kustomize for their own microservices.
• ArgoCD Application spec handles both seamlessly — one repository can contain Helm values and Kustomize overlays side by side.
• Post-renderer pattern — helm template | kustomize build — patches a third-party chart without forking when needed config isn't exposed as a value.

Gotchas to call out

• Helm's 3-way merge silently reverts kubectl edits to Helm-managed fields on the next upgrade — don't manually edit; change the chart.
• Kustomize's configMapGenerator appends a hash suffix to ConfigMap names — surprising at first but crucial for pod restart on config change.
• Helm CRDs in crds/ are install-only — not upgraded; manage separately.
• In strict GitOps with ArgoCD in helm template mode, helm history is empty — rollback = Git revert, not helm rollback.