How does Flux's source-controller and kustomize-controller work together?

Flux splits the responsibilities of fetching config and applying config into two separate controllers, connected through an intermediate Artifact object.

source-controller is responsible for watching external sources — Git repositories, Helm repositories, OCI registries, and S3-compatible buckets. When the source changes (new commit, new chart version, new image tag), the source-controller downloads the content, archives it as a compressed tarball, and stores a reference to it in a GitRepository (or HelmRepository, OCIRepository) status field as a versioned Artifact. Subsequent controllers consume this Artifact rather than fetching from the network themselves.

kustomize-controller watches Kustomization CRs. Each Kustomization references a source (typically a GitRepository) and specifies a path within it. When the source's Artifact revision changes, the kustomize-controller:

1. Downloads the Artifact tarball from source-controller.
2. Runs kustomize build on the specified path to render final manifests.
3. Validates the manifests (optional: dry-run or server-side validation).
4. Applies them to the cluster using server-side apply.
5. Monitors the health of applied resources and updates the Kustomization Ready condition.

# source-controller watches this repo
apiVersion: source.toolkit.fluxcd.io/v1
kind: GitRepository
metadata:
  name: gitops-config
  namespace: flux-system
spec:
  interval: 1m
  url: https://github.com/org/gitops-config.git
  ref:
    branch: main
---
# kustomize-controller deploys from this repo/path
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: apps-prod
  namespace: flux-system
spec:
  interval: 10m
  sourceRef:
    kind: GitRepository
    name: gitops-config
  path: ./apps/overlays/prod
  prune: true
  wait: true
  timeout: 5m