flux bootstrap github: Install Flux via Git
flux bootstrap github installs the Flux controllers and commits their manifests to a GitHub repo so Flux manages itself.
Bootstrap is the first command you run to adopt Flux: it installs the controllers and configures them to sync from a path in your Git repo.
What it does
flux bootstrap github creates (or uses) a GitHub repository, commits the Flux controller manifests under --path, installs them on the cluster, and configures a GitRepository and Kustomization so Flux continuously reconciles itself from Git.
Common usage
export GITHUB_TOKEN=ghp_...
flux bootstrap github \
--owner=acme \
--repository=fleet-infra \
--branch=main \
--path=clusters/production \
--personalOptions
| Flag | What it does |
|---|---|
| --owner <org/user> | GitHub owner of the repo |
| --repository <name> | Repository name (created if missing) |
| --path <dir> | Directory in the repo for this cluster |
| --personal | Repo belongs to a user account, not an org |
| --branch <name> | Git branch to commit to |
| --token-auth | Use HTTPS token auth instead of deploy-key SSH |
In CI
Bootstrap is idempotent: running it again reconciles drift in the Flux install, so a pipeline can run it on every change. The GITHUB_TOKEN needs repo scope to create the deploy key (or the repo, with --personal). Use --path per cluster to keep environments separate.
Common errors in CI
"✗ failed to get Git repository ...: 401 Bad credentials" means GITHUB_TOKEN is missing or lacks scope. "✗ install failed: ... timed out waiting for condition" means the controllers did not become ready; check cluster access and image pulls. "the server could not find the requested resource" can mean the kubeconfig points at the wrong cluster.
Using this in CI
A runner has no kubeconfig, no cached context, and no interactive auth. Every kubectl invocation in CI needs the context supplied explicitly, and most confusing CI failures here are the command running against the wrong cluster or no cluster at all.
# never rely on the ambient context on a runner
kubectl --context "$KUBE_CONTEXT" -n "$NAMESPACE" get pods
# confirm what you are actually connected to before mutating anything
kubectl config current-context
kubectl cluster-info
# fail fast instead of hanging on an unreachable API server
kubectl --request-timeout=30s get nodes