Helm Charts in Kustomize: Rough Edges

The kubectl kustomize command has some support for Helm via the helmCharts inflator, but it comes with rough edges.

The official Kustomize documentation itself says that although the helm-related fields are handy for experimentation and development, it’s best to avoid them in production, calling it “irresponsible to depend on a remote configuration that’s not under your control”. They even acknowledge that the --enable-helm flag is “useless as a reminder, since annoying things are immediately scripted away and forgotten.”
There’s a known bug where changing the chart version in your kustomization.yaml doesn’t actually pull the new version — Kustomize reuses the cached old chart, which can silently deploy the wrong version.
Charts without a values.yaml file cause Kustomize to crash, even though helm template handles them fine.
Kustomize can’t replace or merge ConfigMaps that come from the Helm generator, breaking a basic Kustomize workflow.
Kustomize’s valuesFile doesn’t support merging multiple values files like the Helm CLI does, so each environment needs a complete values file rather than just overrides.
When you use both values files and Kustomize patches for the same fields, “nobody knows which wins”, making debugging painful.

The community has largely landed on a hybrid approach, with most mature teams using Helm for third-party software and Kustomize for internal applications. The recommended pattern is Helm for deploying third-party applications like PostgreSQL, Redis, and Prometheus which have community-maintained charts, and Kustomize for internal configurations and a pure GitOps approach.

The community has landed on a pretty clear three-tier split:

Use helm install/upgrade for third-party stateful infrastructure — databases, message queues, monitoring stacks, ingress controllers. Helm is currently the only solution that supports grouping related manifests, dependency declaration, a registry of deployed applications, managing installations and upgrades as a whole, and built-in rollback to a previous version. When you use helm template for these, you miss all the advantages of Helm, especially the application registry aspect.

Use helm template for third-party stateless things where you want the chart’s expertise but don’t need lifecycle management — things like a one-off job, a CRD bundle, or a chart you want to fork and own going forward. The use case is: you want to see exactly what goes into your cluster, you want it in git, and you want to apply it with kubectl apply. The tradeoff is real though: charts have hooks that only run at specific lifecycle events, and helm template dumps all of them, so you might end up with uninstall batch jobs in your manifest if you’re not careful.

Use plain Kustomize for things you wrote yourself — your SolidStart apps, your API services, your custom CronJobs. For very simple deployments where you have a couple of Deployments and Services, introducing Helm might add more complexity than it removes — lots of sharp edges, little benefit.

So helm template occupies a narrow middle ground: third-party charts where you want git visibility but don’t need rollback or upgrade orchestration. For your setup specifically, that middle ground is probably things like cert-manager CRDs or a one-time infrastructure bootstrap — not your Postgres, and not your apps.

The honest answer is that for a homelab with a dozen sites, you probably only need two of the three: helm install for Postgres and any other infrastructure charts, Kustomize for everything you write. The helm template middle ground solves a problem you’re unlikely to hit at your scale.

Stick with helm template rendered to static YAML if you don’t trust the chart with your sanity, committed to your repo, with Kustomize handling overlays on top. You get the Bitnami chart’s expertise without any of the helmCharts generator bugs, and your Kustomize stays simple — just plain YAML in, patched YAML out. The helmCharts integration isn’t worth the debugging surface area, especially when the official docs themselves advise against it in production.