What's the fundamental difference between Helm's templating approach and Kustomize's overlay/patching approach, and when would you choose each?

Helm generates manifests from templates with unresolved template logic (Go templating, conditionals, loops) filled in by values — the base is incomplete until rendered. Kustomize starts from complete, valid, plain Kubernetes YAML and applies structured patches/overlays on top to produce variants — the base is always valid on its own, and environment differences are expressed as diffs from it, not template logic embedded within it. This difference shapes almost everything else about how each tool is used.

Helm's base is templates, which are not valid YAML on their own: a Helm chart's template files contain Go template syntax ({{ .Values.replicaCount }}, {{- if .Values.ingress.enabled }}) mixed into what looks like YAML but isn't valid YAML until rendered — you can't kubectl apply a chart's template file directly; it has to go through helm template/helm install first to become real manifests.

Kustomize's base is always complete, valid, plain YAML: a Kustomize base directory contains genuine, directly-kubectl apply-able Kubernetes manifests with no templating syntax at all — environment-specific variation is expressed entirely through separate overlay directories containing patches (strategic merge patches, JSON patches, or newer Kustomize-native patch syntax) that Kustomize applies on top of the base to produce the final manifests.

This difference shapes how "what will actually be deployed" is understood: with Helm, understanding the final output requires mentally (or actually) rendering the templates with specific values — the base files alone don't tell you the deployed result. With Kustomize, the base is already a real, readable set of manifests, and overlays are expressed as explicit, comparatively easy-to-read diffs from that known-good base — some teams find this more transparent, since there's no templating logic to trace through to understand what a given environment actually gets.

Helm's templating is more expressive for genuinely complex conditional logic: loops, conditionals, and helper functions across many interdependent values make Helm better suited to charts that need to express real complexity (a chart supporting many optional features, toggled via values) — Kustomize's patch-based model is comparatively limited for this kind of dynamic, conditional generation, since it's fundamentally about patching a fixed base, not generating varying structure from logic.

Helm has a packaging, versioning, and release-tracking model that Kustomize doesn't have natively: Helm charts are versioned, distributable packages with release history tracked in-cluster (helm history, helm rollback) — Kustomize has no equivalent packaging/release concept built in; it's purely a manifest-generation tool, typically used as one step in a broader GitOps pipeline (often via Argo CD or Flux, which handle the actual apply/tracking) rather than having Helm's more complete release-lifecycle feature set on its own.

Choosing between them often comes down to team preference and the actual complexity of variation needed: for genuinely complex, widely-distributed, reusable charts (especially third-party/open-source charts meant to serve many different consumers' needs), Helm's templating and packaging model fits well. For an organization managing its own, comparatively simpler environment-to-environment variations of its own internal manifests, Kustomize's patch-based transparency is often preferred specifically because there's no templating layer obscuring what's actually being deployed — and the two aren't even mutually exclusive, since Kustomize can post-process the output of helm template for teams wanting both.

• Helm's base is incomplete templates requiring rendering; Kustomize's base is always valid, directly-applicable YAML with variation expressed as patches on top.
• Helm's templating (conditionals, loops, helpers) is more expressive for genuinely complex, widely-varying configuration; Kustomize's patch model is comparatively more transparent but less expressive for that kind of complexity.
• Helm has built-in packaging, distribution, and release-tracking (helm history/helm rollback); Kustomize is purely a manifest-generation tool without an equivalent release-lifecycle model.
• The two can be combined (Kustomize patching the output of helm template) rather than being strictly mutually exclusive choices.

• Helm: Documentation
• Kustomize: Documentation