// the find
fluxcd/flux2-kustomize-helm-example
A GitOps workflow example for multi-env deployments with Flux, Kustomize and Helm.
A reference implementation showing how to structure a GitOps monorepo with Flux, Kustomize overlays for per-environment values, and Helm for packaging. Targets platform engineers setting up multi-cluster Kubernetes delivery for the first time. Maintained by the FluxCD team itself, so the patterns here are authoritative.
The base/overlay split for Helm values is well-executed — staging gets pre-releases and helm tests enabled, production pins to stable semver, and the diff between them is minimal YAML patches rather than duplicated files. The `dependsOn` chain (infra-controllers → infra-configs → apps) models real ordering constraints explicitly rather than hoping things come up in the right order. The `ArtifactGenerator` approach for splitting a monorepo into independently-reconcilable artifacts is a genuinely useful pattern for avoiding unnecessary reconciliation storms on large repos. CI runs both kubeconform validation and a real Kind e2e, which catches schema drift before it hits the cluster.
The example app is podinfo, which means zero of the interesting complexity — secrets management, image update automation, multi-tenant RBAC — is shown. Anyone adopting this for a real service hits those walls immediately and has to piece together patterns from other repos. Staging uses `version: '>=1.0.0-alpha'` which will auto-upgrade to anything including breaking pre-releases; fine for a demo, actively dangerous as a copy-paste pattern in production work. The Flux Operator section is bolted on at the end and covers a meaningfully different operational model without clearly flagging that it requires a separate commercial/community tool (`controlplaneio/flux-operator`), not the upstream FluxCD project. Secret injection is entirely absent — there is no SOPS, no External Secrets, nothing — so the example is incomplete for any real deployment.