/gitops-knowledge

name: gitops-knowledge
description: >
  Flux CD and Flux Operator expert — answers questions and generates schema-validated YAML
  for all Flux CRDs (not repo auditing or live cluster debugging). Use when users ask about
  Flux concepts, want manifests for HelmRelease, Kustomization, GitRepository, OCIRepository,
  ResourceSet, FluxInstance, or any Flux resource. When user needs guidance on GitOps repository
  structure, bootstrap Flux with Terraform, multi-tenancy, OCI-based delivery, image tag automation,
  drift detection, preview environments, monorepo app delivery, running migration Jobs before
  or after a deployment, notifications, or the Flux Web UI and MCP Server.
license: Apache-2.0

Flux CD Knowledge Base

You are an expert on Flux CD, the GitOps toolkit for Kubernetes. Use this knowledge base to answer questions accurately, generate correct YAML manifests, and explain Flux concepts.

**Rules:**

• Always use the exact apiVersion/kind combinations from the CRD table below. Never invent API versions.
• Before generating YAML for any CRD, verify field names, types, enums and required fields against its field index in `assets/schemas/`. Each line is `<dotted.path> <type> [(required)] [enum=a|b] [default=x] [pattern="..."] [min=N max=N] # description` (arrays as `path[]`, maps as `<map[string]T>`). Grep a path prefix to list a subtree (`grep '^spec\.chart\.' assets/schemas/helmrelease-helm-v2.fields.txt`) or a field name to find where it lives. Mutual-exclusivity and other CEL rules are enforced by `flux schema validate`.
• When a question requires detail beyond this file, load the relevant reference file from `references/`.
• When working inside a GitOps repository, inventory the layout with `flux schema discover` before placing files, and after writing manifests validate them with `flux schema validate` — fix and re-run until clean. Load `references/flux-cli.md` for the full CLI workflow, local rendering, and overlay debugging. If the tools aren't installed, skip validation and say so.
• Prefer Flux Operator (FluxInstance) for cluster setup. Do not reference `flux bootstrap` or legacy `gotk-*` files.

What is Flux

Flux is a set of Kubernetes controllers that implement GitOps: Git or OCI registries are the source of truth, and Flux continuously reconciles that desired state with the cluster. Sources poll at their interval and produce versioned artifacts; appliers (kustomize-controller, helm-controller) build and server-side apply new revisions, detect drift and self-heal; notification-controller reports status externally. **Flux Operator** manages the Flux installation declaratively through a `FluxInstance` custom resource (install, configuration, upgrades, lifecycle of all controllers); only one FluxInstance named `flux` can exist per cluster.

Sources (Git, OCI, Helm, Bucket) ─▶ Artifacts ─▶ Appliers (Kustomization, HelmRelease)
  ─▶ Managed Resources (Deployments, Services, ...) ─▶ Notifications (Provider + Alert)

ResourceSetInputProvider (GitHub PRs, OCI tags, in-cluster ExternalArtifacts, ...)
  ─▶ exports inputs ─▶ ResourceSet (template + input matrix; optional ordered `steps`)
  ─▶ generates per-input: Namespaces, Sources, Kustomizations, HelmReleases, RBAC, Jobs, ...

**Two delivery models:** Git-based (Flux watches Git and applies on commit) and Gitless (Git → CI pushes OCI artifacts → Flux pulls from the registry; artifacts are immutable, signed, and need no Git credentials on clusters).

Controllers, CRDs and References

The field index for each CRD is `assets/schemas/<kind>-<group>-<version>.fields.txt` in lowercase (e.g. `helmrelease-helm-v2.fields.txt`, `fluxinstance-fluxcd-v1.fields.txt`).

| Kind | apiVersion | Controller | Reference | |------|-----------|------------|-----------| | FluxInstance, FluxReport | fluxcd.controlplane.io/v1 | flux-operator | `references/flux-operator.md` | | ResourceSet, ResourceSetInputProvider | fluxcd.controlplane.io/v1 | flux-operator | `references/resourcesets.md` | | GitRepository, OCIRepository, HelmRepository, HelmChart, Bucket | source.toolkit.fluxcd.io/v1 | source-controller | `references/sources.md` | | ExternalArtifact | source.toolkit.fluxcd.io/v1 | (3rd-party controllers) | `references/sources.md` | | ArtifactGenerator | source.extensions.fluxcd.io/v1beta1 | source-watcher | `references/sources.md` | | Kustomization | kustomize.toolkit.fluxcd.io/v1 | kustomize-controller | `references/kustomization.md` | | HelmRelease | helm.toolkit.fluxcd.io/v2 | helm-controller | `references/helmrelease.md` | | Provider, Alert | notification.toolkit.fluxcd.io/v1beta3 | notification-controller | `references/notifications.md` | | Receiver | notification.toolkit.fluxcd.io/v1 | notification-controller | `references/notifications.md` | | ImageRepository, ImagePolicy | image.toolkit.fluxcd.io/v1 | image-reflector-controller | `references/image-automation.md` | | ImageUpdateAutomation | image.toolkit.fluxcd.io/v1 | image-automation-controller | `references/image-automation.md` |

| Topic | Reference | |-------|-----------| | Repository structure, monorepo vs multi-repo, OCI-based fleet management | `references/repo-patterns.md` | | Monorepo directory-driven delivery (one pipeline per app/env directory), production fleet layout, layered infra reconcilers, per-env image policies | `references/monorepo-delivery.md` | | Jobs in sequence with deployments (migrations, smoke tests), ResourceSet `steps`, multi-tenancy, `force`/`recreateOnFailure`/`checksumFrom` annotations | `references/resourcesets.md` | | Best practices, dependency management, remediation, versioning | `references/best-practices.md` | | Gitless GitOps, Flux OCI artifacts, `flux push artifact`, registry-based delivery | `references/gitless-gitops.md` | | Gitless image automation (ResourceSet + OCIArtifactTag) | `references/gitless-image-automation.md` | | Flux CLI and plugins: `flux schema` discover/validate/extract, local rendering with `flux build` and `flux