Should I Bootstrap Flux with Terraform or the Flux CLI?

If Flux is the only thing you’re bootstrapping and you already have a working CI runner, the Flux CLI is usually the simplest option. Bootstrap is generally a one-time operation, and Flux can then manage its own manifests declaratively through Git. Using Terraform adds another layer unless you already use it to provision the surrounding infrastructure.

The main reason to use Terraform is repeatability and recovery. Consider whether you can recreate an entire environment with one documented process, including the permissions and secrets needed to run bootstrap. If rebuilding clusters, development environments, or disaster-recovery environments is important, managing the bootstrap declaratively may be worthwhile. Otherwise, the CLI is likely enough.

Another option is to install the Flux Operator with Helm and define a FluxInstance resource in your infrastructure repository. The operator can then reconcile that instance, which points Flux at the repository containing its configuration. From there, Flux manages its own setup through GitOps, so Terraform doesn’t need to remain involved.

Terraform and Flux can work together, especially when Terraform owns the cluster and related cloud resources. It can pass infrastructure values—such as certificate IDs, network information, or security group names—to Kubernetes through seeded secrets or other configuration. That can be useful, but it’s more of an integration pattern than a requirement for bootstrapping Flux.