// the find
flux-iac/tofu-controller
A GitOps OpenTofu and Terraform controller for Flux
A Kubernetes controller that runs OpenTofu/Terraform reconciliation loops as part of a Flux GitOps pipeline. Instead of triggering Terraform from CI, you declare a `Terraform` CRD pointing at a Git source and the controller handles plan, approval, and apply in-cluster. Aimed at platform teams that want infrastructure changes to go through the same pull-request-and-reconcile flow as their app manifests.
1. Runner pod isolation: each Terraform execution spawns its own pod with mTLS back to the controller, which limits blast radius in multi-tenant clusters and prevents one runaway plan from blocking others. 2. Drift detection without auto-remediation is a first-class mode — you get alerts when state drifts without the controller auto-applying, which is exactly what cautious teams need before they trust full automation. 3. Branch planner posts `tofu plan` output as PR comments, replacing a significant chunk of Terraform CI boilerplate without requiring you to maintain custom GitHub Actions pipelines. 4. The test suite is unusually thorough — 100+ numbered integration test cases covering the full state machine including delete, drift, manual approve, health checks, and runner quota exhaustion.
1. Still v1alpha2 — the CRD API is not stable, and the renaming from Weave TF-Controller adds organizational history to track; Weaveworks going through financial trouble left this project in community hands mid-development, and it shows in some rough edges. 2. Running Terraform in-cluster means your cluster nodes or service accounts need IAM credentials to your cloud provider — that's a meaningful security perimeter to manage, and IRSA/workload identity setup is non-trivial to get right across cloud providers. 3. The controller + runner pod + gRPC architecture is substantially more operationally complex than a CI job; when something goes wrong you're debugging Kubernetes events, runner pod logs, and controller logs across three components. 4. State backend configuration is still on you — the controller doesn't abstract away remote state, so you're managing S3/GCS/Azure backends manually, which undermines some of the 'just GitOps it' promise.