What does the flux bootstrap command actually do to a Git repository and to a cluster, and why is Flux installed this way instead of applying its manifests once?

## The bootstrap paradox A GitOps agent's premise is that everything in the cluster comes from Git. That immediately raises the question of the agent itself: something has to put the agent there, and if that something is a human running `kubectl apply` from a laptop, then the most privileged component in your delivery pipeline is the one piece that is not under review, not versioned, and not reproducible. `flux bootstrap` resolves this by making Flux its own first customer. ## What the command does ```bash flux bootstrap github \ --owner=my-org \ --repository=fleet \ --branch=main \ --path=clusters/production ``` Step by step: 1. **Generate the component manifests.** The CLI renders the controller Deployments, CRDs, RBAC and namespace for the Flux version it ships, into `<path>/flux-system/gotk-components.yaml`. 2. **Write the sync manifests.** Alongside it, `gotk-sync.yaml` contains a `GitRepository` for this repository and ref, and a `Kustomization` whose `path` is the directory just written. A `kustomization.yaml` ties them together so the directory builds as a unit. 3. **Commit and push.** Those files land in your repository on the given branch, as a real, reviewable commit. 4. **Apply to the cluster.** The components are applied directly so the controllers come up. This is the only imperative moment, and it is deliberately the last time. 5. **Set up access.** For the `github`/`gitlab` providers it can create the repository if absent and register a deploy key (read-only by default; `--read-write-key` when image automation needs to push back), storing the private key in a Secret named `flux-system` that the GitRepository references. `--token-auth` uses an HTTPS token in that Secret instead. The generic `flux bootstrap git` provider works with any Git host given a URL and credentials. Once that lands, the loop is closed: source-controller fetches the repo, kustomize-controller builds `<path>/flux-system`, and applies the very manifests that define the controllers doing the applying. ## Why self-management matters - **Upgrades are commits.** Re-run bootstrap with a newer CLI, or bump the version in the repo, and the running Flux applies the new components. The change is diffable, reviewable and revertable, and there is a record of when each cluster moved. - **Rebuild is repeatable.** Point bootstrap at a fresh cluster with the same repository and path and it converges to the same state. Disaster recovery becomes "create cluster, bootstrap, wait" rather than a document of remembered steps. - **Configuration is not special.** Controller resource limits, feature flags, a `--concurrent` tuning, or patches to the components are kustomize patches in that same directory, applied by the same mechanism as your workloads. - **Drift on Flux itself heals.** Because the Kustomization re-applies on its interval, a hand-edited controller Deployment reverts like anything else. ## The parts people get wrong **"Bootstrap is a one-time install."** It is idempotent and designed to be re-run — that is the documented upgrade path. Treating it as a one-shot leaves people hand-editing Deployments in `flux-system`, which the next reconcile promptly undoes. **"The path is arbitrary."** The `--path` is per-cluster by convention (`clusters/staging`, `clusters/production`) precisely so one repository can bootstrap several clusters, each with its own component set and its own top-level Kustomization that then points at shared directories. **"The deploy key is read-only, so nothing is at risk."** The key is read-only *for the repository*, but the controllers hold in-cluster RBAC to apply arbitrary manifests. Whoever can merge to that branch and path can change what runs in the cluster. Branch protection on the bootstrap path is a production control, not a nicety — this is the concrete reason the repository becomes as sensitive as the cluster. **"Bootstrap must run against the same repo as the apps."** It does not. A common layout separates a fleet repository (bootstrapped, cluster-level) from application repositories referenced by additional GitRepository/Kustomization pairs, so app teams never need write access to the path that defines the controllers. ## Bootstrapping and the rest of the toolkit After bootstrap, everything else is additive: more `GitRepository` or `OCIRepository` sources, more `Kustomization` objects layered with `dependsOn`, `HelmRelease` objects for charts, and notification resources for alerts. Nothing further needs the CLI's write access — the CLI becomes a debugging and forcing tool (`flux get`, `flux reconcile`, `flux diff`, `flux logs`) rather than an installation tool. That is the shape to describe in an interview: one imperative act at the beginning, declarative reconciliation forever after.