Courses Infrastructure as Code & automationAdvanced · GitOps for infrastructure

GitOps: Atlantis, Argo CD & Flux

Git as the source of truth for infra.

Advanced14 min · lesson 19 of 23

The last piece is how IaC actually gets applied to production. The risky pattern is a person running terraform apply from their laptop with production credentials; the mature pattern is GitOps — the repository is the source of truth, and applies happen automatically from Git through an audited, reviewed workflow, with no human holding production keys locally. You have seen GitOps for app delivery (Argo CD/Flux); the same principle applies to infrastructure, with Terraform-specific tools too.

GitOps for infrastructure

1open a PR

change the IaC

2auto plan

tool posts the plan on the PR

3review + merge

humans approve the diff

4auto apply

the tool applies from Git

No one runs apply locally. The plan is reviewed on the PR; merge triggers the apply. Git is the audit log.

Atlantis for Terraform

Atlantis is the classic GitOps tool for Terraform. It watches your pull requests: when you open one that changes Terraform, Atlantis runs terraform plan and posts the output as a PR comment, so reviewers see exactly what will change before approving. On merge (or an approving comment), Atlantis runs the apply — from the server, with the credentials held there, never on a developer’s machine. This gives you reviewed plans, an audit trail in the PR, locking so two PRs cannot apply conflicting changes, and centralized credentials. It is how many teams run Terraform safely at scale.

pull request (Atlantis flow)

# developer opens a PR changing main.tf, then comments:
atlantis plan
# Atlantis replies with the full plan:
#   Plan: 1 to add, 0 to change, 0 to destroy.  (reviewers read this)
# after approval:
atlantis apply
# Atlantis applies from the server — audited, locked, no local prod creds

Argo CD and Flux for reconciliation

For Kubernetes-based infrastructure (manifests, Helm, Kustomize, and Crossplane resources), Argo CD and Flux continuously reconcile the cluster to match Git — the pull-based model from the CI/CD course: an in-cluster agent watches the repo and applies changes, and reverts drift automatically. The distinction: Atlantis is plan/apply for Terraform triggered by PRs, while Argo/Flux continuously reconcile Kubernetes state. Many platforms use both — Atlantis for cloud infra via Terraform, Argo/Flux for what runs on the cluster — unified by the same principle that Git, not a person, is the source of truth.

GitOps moves the crown jewels to the Git repo and the runner

GitOps is a big security win — no production credentials on laptops, every change reviewed and audited — but it relocates the risk: whoever can merge to the infrastructure repo, or compromise the Atlantis/Argo runner, can change production. So protect the repo like production (branch protection, required reviews, code owners, signed commits), scope the runner’s credentials to the minimum, isolate it, and never let it run untrusted PR code with production access (the CI runner-isolation lesson applies directly). The audit trail and reviewed-plan gate are the payoff; the repo and runner are the new perimeter.

Scanning: Checkov, tfsec/Trivy,…Drift detection & remediation