Flux Operator Bootstrap Module for Terraform and OpenTofu #5870
Replies: 1 comment 14 replies
-
|
Hi @matheuscscp, This is extremely useful, thank you both for this! Bootstrapping I have a question about TF states for cluster instances: what's the intended process? Since the module is only used for bootstrapping clusters, are there any disadvantages to simply deleting the TF state after it's done? Would it be useful to keep it around, maybe to be able to force-override some values on a running cluster? If we wanted to keep TF state around, I guess the D2 repo example should be altered to support handling multiple cluster instances, where each one would have a small TF root module, referencing the module in |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
🚀 New on the Flux blog: bootstrapping Flux with Terraform, the right way.
If you've ever fought Terraform and Flux over who owns what after a cluster comes up, this one is
for you.
We just released a new Terraform module (also fully compatible with OpenTofu) that bootstraps Flux
Operator into a Kubernetes cluster — and then gracefully steps aside, letting Flux take over
steady-state reconciliation. No more drift loops, no more two-phase applies.
A few things it solves out of the box:
✅ Clean ownership handoff — Terraform owns the bootstrap, Flux owns everything after
✅ Same GitOps repo for Terraform inputs and Flux manifests
✅ Same root module as the cluster — no provider chicken-and-egg
✅ Secrets never land in Terraform state
✅ Prerequisites like CNI plugins and CSI drivers can be installed before Flux
Plus some groundwork for a SPIFFE/SPIRE integration coming in upcoming releases. 👀
Read it here 👉 https://fluxcd.io/blog/2026/04/terraform-flux-operator-bootstrap/
Beta Was this translation helpful? Give feedback.
All reactions