A Different Mental Model: Continuous Reconciliation
Atlantis is event-driven: it acts when a PR is opened or a comment is posted. The Flux TF-Controller is loop-driven: it continuously watches Git and continuously reconciles the real world to match the declared state. This is the same model Flux uses for Kubernetes application deployments, extended to Terraform.
If you are already running Flux to deploy applications to Kubernetes, TF-Controller lets you manage cloud infrastructure (RDS databases, S3 buckets, VPCs) using the same GitOps engine, the same RBAC model, and the same observability tooling — without running a separate Atlantis server.
How It Works
You define a Terraform custom resource (CR) in a YAML file and commit it to your Git repository — naming the module path within the referenced repo, which Git source to watch, how often to reconcile, whether plans require manual approval or apply automatically, and where the state backend lives. Flux detects the file, and the TF-Controller takes over.
What happens next:
- The TF-Controller sees the
TerraformCR. - It spins up a short-lived Runner pod inside the cluster to execute Terraform. The pod has the cloud credentials injected via Kubernetes secrets or IRSA (IAM Roles for Service Accounts).
- The Runner runs
terraform init,terraform plan, and (if approved)terraform apply. - The result is written back to the
TerraformCR's.statusfield, visible viakubectl describe terraform rds-production. - After
interval(1 hour in this example), the controller runs again. If someone manually changed the RDS instance class in the AWS console, the controller detects the drift and reverts it.
Atlantis vs. TF-Controller: Choosing the Right Tool
| Dimension | Atlantis | Flux TF-Controller |
|---|---|---|
| Trigger model | Event-driven (PR webhook) | Loop-driven (continuous reconciliation) |
| Drift correction | No — applies once on PR merge | Yes — re-applies on every interval |
| Approval workflow | PR comments (atlantis apply) |
Kubernetes CR annotation or auto |
| Prerequisites | Any Git provider + a server | Kubernetes cluster + Flux installed |
| Best for | Teams wanting PR-centric review | Teams already using Flux for apps |
| State visibility | Atlantis UI / PR comments | kubectl / Flux dashboard |
The key architectural difference is drift correction. Atlantis trusts that once a PR is merged and applied, the cloud stays in sync. TF-Controller does not trust this — it continuously verifies and corrects. For environments where manual console access is possible (e.g., during incidents), TF-Controller's drift correction is a stronger guarantee of consistency. The trade-off is that automatic drift correction can be alarming if not well understood: an engineer who makes a manual change to debug a production issue will find it reverted within the hour.