git:20260723.30875df to git:20260901.c72ebb7

99 added, 269 removed. Audit A to A.

---

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, notifications, or the Flux Web UI and MCP Server.

+ 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

metadata:

github-path: skills/gitops-knowledge

- github-ref: refs/tags/v0.2.0

+ github-ref: refs/tags/v0.3.0

github-repo: https://github.com/fluxcd/agent-skills

- github-tree-sha: 904f1e61c0b3643aac75a3892ed4a4d0b1a37e96

+ github-tree-sha: d2ac2832df36d71727c39e1740db43760180d215

---

# 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, enum values, and required fields against its field index in `assets/schemas/` (see the CRD table below). Each line is `<dotted.path> <type> [(required)] [enum=a|b] [default=x] [pattern="..."] [min=N max=N] # description`, with arrays as `path[]` and string maps as `<map[string]T>`. Grep by path prefix to list a subtree (e.g. `grep '^spec\.chart\.' assets/schemas/helmrelease-helm-v2.fields.txt`) or grep a field name to find where it lives. Constraints the index doesn't carry (mutual-exclusivity and other CEL rules) are enforced by `flux schema validate`.

+ - 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 — the practice of using Git

- (or OCI registries) as the source of truth for declarative infrastructure and applications.

- Flux continuously reconciles the desired state stored in sources with the actual state of

- the cluster.

- **Flux Operator** manages the Flux installation declaratively through a `FluxInstance` custom

- resource. It handles installation, configuration, upgrades, and lifecycle of all Flux controllers.

- Only one FluxInstance named `flux` can exist per cluster.

- **How resources relate:**

+ 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)

- │

- ▼ produce artifacts

- Artifacts (tarballs, Helm charts, OCI layers)

- │

- ▼ consumed by

- Appliers (Kustomization, HelmRelease)

- │

- ▼ create/update

- Managed Resources (Deployments, Services, ConfigMaps, ...)

- │

- ▼ status reported to

- Notifications (Provider + Alert → Slack, Teams, GitHub, ...)

- ```

- **ResourceSet orchestration flow:**

+ Sources (Git, OCI, Helm, Bucket) ─▶ Artifacts ─▶ Appliers (Kustomization, HelmRelease)

+ ─▶ Managed Resources (Deployments, Services, ...) ─▶ Notifications (Provider + Alert)

- ```

- ResourceSetInputProvider (GitHub PRs, OCI tags, ...)

- │

- ▼ exports inputs

- ResourceSet (template + input matrix)

- │

- ▼ generates per-input

- Namespaces, Sources, Kustomizations, HelmReleases, RBAC, ...

+ 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 repositories and applies changes on commit.

- - **Gitless (OCI-based):** Git → CI pushes OCI artifacts → Flux pulls from registry. OCI artifacts

- are immutable, signed, and don't require Git credentials on clusters.

- ## Controllers and CRDs

- |------|-----------|------------|---------|

+ **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).

- ## How Flux Works

+ ## Controllers, CRDs and References

- ### Reconciliation Loop

+ 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`).

- Flux controllers run a continuous reconciliation loop:

+ |------|-----------|------------|-----------|

- 1. **Sources poll for changes** — source-controller checks Git repos, OCI registries, Helm repos,

- or S3 buckets at configured intervals and produces versioned artifacts.

- 2. **Appliers consume artifacts** — kustomize-controller and helm-controller detect new artifact

- revisions, build manifests (Kustomize overlays or Helm templates), and apply them to the cluster

- using server-side apply.

- 3. **Drift detection and self-healing** — Flux compares the desired state from the source with the

- live state in the cluster. When drift is detected, Flux corrects it automatically (if enabled).

- 4. **Notifications report status** — notification-controller sends events to external systems

- (Slack, Teams, GitHub commit status, etc.) based on Alert rules.

+ | 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 operator build`, overlay debugging | `references/flux-cli.md` |

+ | Terraform bootstrap of Flux Operator | `references/terraform-bootstrap.md` |

+ | Web UI, dashboard, SSO, OIDC, Dex, Keycloak, Entra ID, RBAC | `references/web-ui.md` |

+ | MCP Server, AI assistant integration, in-cluster deployment | `references/mcp-server.md` |

- ### Dependency Ordering

+ ## Ordering and Reactivity

- Use `dependsOn` to control reconciliation order. For example, install CRDs before CRs,

- or infrastructure before applications:

+ Use `dependsOn` to control reconciliation order (CRDs before CRs, infrastructure before apps):

```yaml

spec:

dependsOn:

- name: infra-controllers # wait for this Kustomization to be Ready

```

- ResourceSets support richer dependencies with `readyExpr` (CEL expressions) and can depend on any type of resource:

- ```yaml

- spec:

- dependsOn:

- - apiVersion: fluxcd.controlplane.io/v1

- kind: ResourceSet

- name: policies

- ready: true

- readyExpr: "status.conditions.filter(e, e.type == 'Ready').all(e, e.status == 'True')"

- ```

- For ordering *within* a single ResourceSet, use `spec.steps` (ordered named steps, each applied

- and health-checked before the next) instead of `spec.resources` — see `references/resourcesets.md`.

- ### Reactivity with Watch Labels

- By default, Flux controllers poll sources at the configured interval. To react immediately

- when a dependency changes, add the watch label to the upstream resource:

- ```yaml

- metadata:

- labels:

- reconcile.fluxcd.io/watch: Enabled

- ```

+ ResourceSet `dependsOn` entries take `apiVersion`/`kind`/`name`/`namespace` of any resource,

+ plus `ready: true` or a `readyExpr` CEL expression for custom readiness. For ordering *within*

+ a single ResourceSet, use `spec.steps` (ordered named steps, each applied and health-checked

+ before the next) instead of `spec.resources` — see `references/resourcesets.md`.

- When a ConfigMap or Secret with this label changes, any Kustomization or HelmRelease that

- references it via `postBuild.substituteFrom` or `valuesFrom` will reconcile immediately.

+ Controllers poll sources at their interval. To react immediately when a ConfigMap or Secret

+ referenced via `postBuild.substituteFrom` or `valuesFrom` changes, label it

+ `reconcile.fluxcd.io/watch: Enabled`.

## Decision Trees

### Which Source Type?

- **Git repo with Kustomize overlays or plain YAML** → `GitRepository`

- **OCI artifact (container image with manifests)** → `OCIRepository`

- **Helm chart from OCI registry** → `OCIRepository` with `layerSelector` for Helm media type

- **Helm chart from HTTPS Helm repo** → `HelmRepository` (default type)

- **S3/GCS/MinIO bucket** → `Bucket`

- **Monorepo that needs splitting** → `ArtifactGenerator` (creates `ExternalArtifact` per path)

+ - **Monorepo where every `apps/<app>/envs/<env>` directory gets its own pipeline automatically** → `ArtifactGenerator` `pathPattern` + `ResourceSetInputProvider` (`type: ExternalArtifact`) + `ResourceSet` templating a `Kustomization` per artifact — load `references/monorepo-delivery.md`

- **Helm chart + env-specific values from Git** → `ArtifactGenerator` (composes chart with values overlay)

- ### Kustomization vs HelmRelease?

+ ### Kustomization vs HelmRelease vs ResourceSet?

- - **Plain YAML or Kustomize overlays** → `Kustomization`

+ - **Plain YAML or Kustomize overlays, one deployment** → `Kustomization`

- **Helm chart** → `HelmRelease`

- - Both can deploy to remote clusters via `kubeConfig` and support `dependsOn`.

- ### ResourceSet vs Kustomization?

- - **One set of manifests, one deployment** → `Kustomization`

- - **Same template deployed for N inputs (tenants, components, environments)** → `ResourceSet`

- - ResourceSets generate resources from an input matrix; Kustomizations apply a fixed set of manifests.

+ - **Same template deployed for N inputs (tenants, components, environments)** → `ResourceSet` (generates resources from an input matrix; Kustomizations apply a fixed set of manifests)

+ - **Jobs that must run before/after a deployment (DB migration, smoke test, cache warmup)** → `ResourceSet` with `spec.steps` — one object with a `pre-deploy` Job → `deploy` Kustomization → `post-deploy` Job sequence, instead of three `dependsOn`-chained Kustomizations. See `references/resourcesets.md` (Step-Based Reconciliation).

+ - Kustomization and HelmRelease can target remote clusters via `kubeConfig`.

### How to Set Up GitOps from Scratch

- 1. Install Flux Operator (Helm chart or Terraform)

- 2. Create a `FluxInstance` named `flux` in the `flux-system` namespace

- 3. Configure `.spec.sync` to point to your Git repo or OCI registry

- 4. Organize manifests in the source repo using Kustomize base+overlay pattern

- 5. Create `Kustomization` resources to apply manifests from the source

- 6. Add `Provider` + `Alert` for notifications

+ Install Flux Operator (Helm chart or Terraform) → create a `FluxInstance` named `flux` in

+ `flux-system` with `.spec.sync` pointing at the Git repo or OCI registry → organize manifests

+ as Kustomize base+overlays → add `Kustomization` resources per component → add `Provider` + `Alert`.

## Canonical YAML Patterns

### 1. GitOps Pipeline (GitRepository + Kustomization)

```yaml

apiVersion: source.toolkit.fluxcd.io/v1

kind: GitRepository

metadata:

namespace: flux-system

spec:

interval: 5m

url: https://github.com/org/my-app.git

ref:

branch: main

secretRef:

---

apiVersion: kustomize.toolkit.fluxcd.io/v1

kind: Kustomization

metadata:

namespace: flux-system

spec:

interval: 10m

sourceRef:

kind: GitRepository

path: ./deploy/production

prune: true

wait: true

timeout: 5m

```

- ### 2. Helm from HTTPS Repository

- ```yaml

- apiVersion: source.toolkit.fluxcd.io/v1

- kind: HelmRepository

- metadata:

- name: metrics-server

- namespace: kube-system

- spec:

- interval: 1h

- url: https://kubernetes-sigs.github.io/metrics-server/

- ---

- apiVersion: helm.toolkit.fluxcd.io/v2

- kind: HelmRelease

- metadata:

- name: metrics-server

- namespace: kube-system

- spec:

- interval: 30m

- chart:

- spec:

- chart: metrics-server

- version: "3.x"

- sourceRef:

- kind: HelmRepository

- name: metrics-server

- values:

- args:

- - --kubelet-insecure-tls

- ```

- ### 3. Helm from OCI Registry (Recommended)

+ ### 2. Helm from OCI Registry (Recommended)

```yaml

apiVersion: source.toolkit.fluxcd.io/v1

kind: OCIRepository

metadata:

namespace: cert-manager

spec:

interval: 1h

url: oci://quay.io/jetstack/charts/cert-manager

layerSelector:

mediaType: "application/vnd.cncf.helm.chart.content.v1.tar+gzip"

operation: copy

ref:

semver: "1.x"

---

apiVersion: helm.toolkit.fluxcd.io/v2

kind: HelmRelease

metadata:

namespace: cert-manager

spec:

interval: 1h

chartRef:

kind: OCIRepository

install:

strategy:

retryInterval: 5m

upgrade:

strategy:

retryInterval: 5m

values:

crds:

enabled: true

```

- ### 4. FluxInstance with OCI Sync (Gitless GitOps)

+ For HTTPS Helm repositories use `HelmRepository` + `HelmRelease` with `spec.chart.spec`

+ (`chart`, `version: "3.x"`, `sourceRef`) instead of `chartRef` — see `references/helmrelease.md`.

+ ### 3. FluxInstance with OCI Sync (Gitless GitOps)

```yaml

apiVersion: fluxcd.controlplane.io/v1

kind: FluxInstance

metadata:

namespace: flux-system

spec:

distribution:

version: "2.x"

registry: "ghcr.io/fluxcd"

components:

- source-controller

- source-watcher

- kustomize-controller

- helm-controller

- notification-controller

cluster:

type: kubernetes

size: medium

multitenant: true

tenantDefaultServiceAccount: flux

networkPolicy: true

sync:

kind: OCIRepository

url: "oci://ghcr.io/my-org/fleet-manifests"

ref: "latest"

path: "clusters/production"

pullSecret: "registry-auth"

```

- ### 5. ResourceSet for Multi-Component Orchestration

- ```yaml

- apiVersion: fluxcd.controlplane.io/v1

- kind: ResourceSet

- metadata:

- name: apps

- namespace: flux-system

- spec:

- inputs:

- - tenant: "frontend"

- environment: "production"

- - tenant: "backend"

- environment: "production"

- resources:

- - apiVersion: v1

- kind: Namespace

- metadata:

- name: << inputs.tenant >>

- - apiVersion: source.toolkit.fluxcd.io/v1

- kind: OCIRepository

- metadata:

- name: apps

- namespace: << inputs.tenant >>

- spec:

- interval: 5m

- url: "oci://ghcr.io/my-org/apps/<< inputs.tenant >>"

- ref:

- tag: latest

- - apiVersion: kustomize.toolkit.fluxcd.io/v1

- kind: Kustomization

- metadata:

- name: apps

- namespace: << inputs.tenant >>

- spec:

- interval: 30m

- wait: true

- prune: true

- sourceRef:

- kind: OCIRepository

- name: apps

- path: "./<< inputs.environment >>"

- ```

- For the full multi-tenant pattern — per-tenant ServiceAccount + RoleBinding,

- `serviceAccountName` impersonation, `dependsOn`, and the `reconcileEvery` annotation —

- load `references/resourcesets.md`.

- ### 6. Image Automation

- Flux supports two delivery models for updating container images and Helm chart versions.

- Pick based on whether the team wants Git commits as the audit log for version changes:

+ ### 4. ResourceSet for Multi-Component Orchestration

- - **Git-based** — `ImageRepository` + `ImagePolicy` + `ImageUpdateAutomation` scan the

- registry and commit tag bumps back to Git via `$imagepolicy` YAML markers. Requires

- `image-reflector-controller` and `image-automation-controller` on the cluster. Load

- `references/image-automation.md`.

- - **Gitless** — `ResourceSet` + `ResourceSetInputProvider` (`type: OCIArtifactTag`)

- scans the registry and re-renders the `ResourceSet` directly, upgrading the downstream

- `HelmRelease` or `Kustomization` without touching Git. No bot credentials, no Git

- poll lag, no extra controllers. Recommended default for Flux Operator deployments.

- Load `references/gitless-image-automation.md`.

+ A `ResourceSet` lists `spec.inputs` (e.g. `tenant`/`environment` pairs) and `spec.resources`

+ templates that reference them with `<< inputs.tenant >>`; each input renders its own Namespace,

+ source and Kustomization/HelmRelease. For the full example and the multi-tenant pattern —

+ per-tenant ServiceAccount + RoleBinding, `serviceAccountName` impersonation, `dependsOn`,

+ and the `reconcileEvery` annotation — load `references/resourcesets.md`.

- Gitless is the better fit when the tag lives in Helm values, when tags should differ per

- cluster in a fleet, or when the team doesn't want a bot writing to the repo. Git-based is

- the better fit when PR-based approval of version bumps is required or when Git must remain

- the canonical record of every deployed version.

+ ### 5. Image Automation

- ### 7. Notifications (Slack, GitHub, Webhooks)

+ - **Git-based** — `ImageRepository` + `ImagePolicy` + `ImageUpdateAutomation` commit tag

+ bumps to Git via `$imagepolicy` YAML markers; requires `image-reflector-controller` and

+ `image-automation-controller`. Use when PR-based approval of bumps is required or Git must

+ record every deployed version. Load `references/image-automation.md`.

+ - **Gitless** — `ResourceSet` + `ResourceSetInputProvider` (`type: OCIArtifactTag`) re-renders

+ the downstream `HelmRelease`/`Kustomization` without touching Git: no bot credentials, no poll

+ lag, no extra controllers. Recommended default for Flux Operator; best when the tag lives in

+ Helm values or differs per cluster. Load `references/gitless-image-automation.md`.

- Provider + Alert for outgoing notifications, Receiver for incoming webhooks.

- Alert and Provider use `v1beta3`, Receiver uses `v1`.

+ ### 6. Notifications

- For Slack, GitHub commit status, webhook receivers, and all provider types,

+ `Provider` + `Alert` (`v1beta3`) for outgoing notifications, `Receiver` (`v1`) for incoming

+ webhooks. For Slack, GitHub commit status, webhook receivers, and all provider types,

load `references/notifications.md`.

## Common Mistakes

**Wrong template delimiters:**

- ResourceSet uses `<< inputs.field >>` — NOT `{{ .inputs.field }}` or `{{ inputs.field }}`

- Go templates `{{ }}` are only used in ImageUpdateAutomation `.spec.git.commit.messageTemplate`

**Mutual exclusivity:**

- HelmRelease: `spec.chart.spec` and `spec.chartRef` are mutually exclusive

- FluxInstance: only one per cluster, must be named `flux`

**HelmRelease strategy fields:**

- Install/upgrade strategy is at `spec.install.strategy.name` and `spec.upgrade.strategy.name`

- Always use `RetryOnFailure` — it retries without rollback or uninstall, avoiding downtime

- Do not use `RemediateOnFailure` or `spec.install.remediation` / `spec.upgrade.remediation`

**OCIRepository for Helm charts:**

- - When using OCIRepository to fetch Helm charts from OCI registries, set `layerSelector` to extract the chart:

- ```yaml

- layerSelector:

- mediaType: "application/vnd.cncf.helm.chart.content.v1.tar+gzip"

- operation: copy

- ```

+ - Set `layerSelector` (`mediaType: "application/vnd.cncf.helm.chart.content.v1.tar+gzip"`, `operation: copy`) to extract the chart, as in pattern 2.

+ **Jobs managed by a ResourceSet:**

+ - Job specs are immutable — annotate the Job with `fluxcd.controlplane.io/force: enabled` so a changed spec (new image tag) recreates it instead of failing the apply; add `fluxcd.controlplane.io/recreateOnFailure: enabled` only for idempotent Jobs.

+ - Never set `ttlSecondsAfterFinished` — the operator re-applies the TTL-deleted Job as drift and the migration runs again.

+ - Set `spec.wait: true` on a stepped ResourceSet, otherwise the final step is not health-checked.

+ **Post-build substitution pitfalls:**

+ - `substituteFrom` only resolves ConfigMaps/Secrets in the Kustomization's own namespace — copy cluster variables into tenant namespaces with `fluxcd.controlplane.io/copyFrom` (ResourceSet) rather than referencing `flux-system` from elsewhere.

+ - Kustomize `spec.images[].name` must match a plain image reference in the manifests (`image: frontend`); image rewriting runs at build time, before `${var}` substitution.

+ - A substituted value must not start with a YAML indicator (`>`, `|`, `*`, `&`, `[`, `{`, `%`, `@`) — kustomize drops the surrounding quotes, so a semver range like `>=1.0.0` yields invalid YAML. Use `x`, `1.x`, `~1.2.0`, `^1.2.0` or `x || >=0.0.0-0`.

**Drift control — pick the right knob:**

- Kustomization `spec.ignore` — exclude specific JSON-pointer fields from drift detection/apply (e.g. HPA `replicas`). Distinct from the `kustomize.toolkit.fluxcd.io/ssa: Ignore` annotation, which skips a whole object.

- HelmRelease `spec.driftDetection.ignore` — the HelmRelease equivalent, only active when `driftDetection.mode` is `warn`/`enabled`.

- ## Reference Index

- Load reference files and field indexes based on the question topic.

- Grep the field index for field-level lookups when generating YAML.

- | CRD | Reference | Field Index |

- |-----|-----------|--------|

- | FluxInstance | `references/flux-operator.md` | `assets/schemas/fluxinstance-fluxcd-v1.fields.txt` |

- | FluxReport | `references/flux-operator.md` | `assets/schemas/fluxreport-fluxcd-v1.fields.txt` |

- | ResourceSet | `references/resourcesets.md` | `assets/schemas/resourceset-fluxcd-v1.fields.txt` |

- | ResourceSetInputProvider | `references/resourcesets.md` | `assets/schemas/resourcesetinputprovider-fluxcd-v1.fields.txt` |

- | GitRepository | `references/sources.md` | `assets/schemas/gitrepository-source-v1.fields.txt` |

- | OCIRepository | `references/sources.md` | `assets/schemas/ocirepository-source-v1.fields.txt` |

- | HelmRepository | `references/sources.md` | `assets/schemas/helmrepository-source-v1.fields.txt` |

- | HelmChart | `references/sources.md` | `assets/schemas/helmchart-source-v1.fields.txt` |

- | Bucket | `references/sources.md` | `assets/schemas/bucket-source-v1.fields.txt` |

- | ExternalArtifact | `references/sources.md` | `assets/schemas/externalartifact-source-v1.fields.txt` |

- | ArtifactGenerator | `references/sources.md` | `assets/schemas/artifactgenerator-source-v1beta1.fields.txt` |

- | Kustomization | `references/kustomization.md` | `assets/schemas/kustomization-kustomize-v1.fields.txt` |

- | HelmRelease | `references/helmrelease.md` | `assets/schemas/helmrelease-helm-v2.fields.txt` |

- | Provider | `references/notifications.md` | `assets/schemas/provider-notification-v1beta3.fields.txt` |

- | Alert | `references/notifications.md` | `assets/schemas/alert-notification-v1beta3.fields.txt` |

- | Receiver | `references/notifications.md` | `assets/schemas/receiver-notification-v1.fields.txt` |

- | ImageRepository | `references/image-automation.md` | `assets/schemas/imagerepository-image-v1.fields.txt` |

- | ImagePolicy | `references/image-automation.md` | `assets/schemas/imagepolicy-image-v1.fields.txt` |

- | ImageUpdateAutomation | `references/image-automation.md` | `assets/schemas/imageupdateautomation-image-v1.fields.txt` |

- | Topic | Reference |

- |-------|-----------|

- | Repository structure, monorepo vs multi-repo, OCI-based fleet management | `references/repo-patterns.md` |

- | Best practices, dependency management, remediation, versioning | `references/best-practices.md` |

- | Web UI, dashboard, SSO, OIDC, Dex, Keycloak, Entra ID, RBAC | `references/web-ui.md` |

- | MCP Server, AI assistant integration, in-cluster deployment | `references/mcp-server.md` |

- | Terraform bootstrap of Flux Operator | `references/terraform-bootstrap.md` |

- | Flux CLI and plugins: `flux schema` discover/validate/extract, local rendering with `flux build` and `flux operator build`, overlay debugging | `references/flux-cli.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` |