🤖 GitOps for Terraform With Atlantis and Spacelift

There’s a stage every Terraform team passes through where applies happen from laptops. Someone pulls main, runs terraform apply, and hopefully remembers to push the state lock release if it crashes. It works until it doesn’t — two people apply at once, a stale local state stomps a change, or someone applies a branch that was never reviewed. The fix isn’t more discipline. It’s taking apply off laptops entirely and making the pull request the apply workflow.

That’s GitOps for Terraform, and the two tools you’ll evaluate are Atlantis and Spacelift. I’ve run both. Here’s how they work and how to choose.

The model: plan on PR, apply on merge

The shared idea behind every Terraform GitOps tool is the same. You stop running Terraform locally and instead let a service run it in response to git events:

1. You open a pull request that changes .tf files.
2. The tool runs terraform plan automatically and posts the plan as a PR comment.
3. Reviewers read the actual plan, not just the code diff, and approve.
4. On approval (or on merge), the tool runs terraform apply from a controlled environment with the only copy of the credentials.

The wins are immediate: state locking is centralized, credentials never touch a laptop, every apply is tied to a reviewed PR, and the plan everyone reviewed is the plan that gets applied. Nobody can apply an unreviewed branch because nobody has the keys.

Atlantis: the open-source workhorse

Atlantis is a self-hosted, open-source server that listens for webhooks from your VCS. You run it yourself (a container, a pod, a VM), point your repos’ webhooks at it, and drive it with PR comments.

The interaction is comment-driven:

atlantis plan      # runs terraform plan, posts the result
atlantis apply     # runs terraform apply after approval

Configuration lives in an atlantis.yaml that maps directories to projects and workflows:

version: 3
projects:
  - name: prod-network
    dir: environments/prod/network
    workflow: default
    apply_requirements:
      - approved
      - mergeable

Those apply_requirements are the safety rail: this project can’t be applied until the PR is approved and mergeable. Atlantis is free, runs in your own infrastructure (so your state and credentials never leave your boundary), and is the right call when you want full control and don’t want a per-resource bill. The tradeoff is that you operate it — patching, scaling, and securing the server is your job.

Spacelift: the managed platform

Spacelift is a hosted product that does the same core loop but adds the things you’d otherwise build yourself: a policy engine (OPA-based) for fine-grained controls, drift detection that runs on a schedule, dependency graphs between stacks, managed state, and a UI for runs and approvals.

Where Atlantis gives you apply_requirements, Spacelift gives you Rego policies that can gate plans on arbitrary conditions:

package spacelift

# Require a second approval for any plan touching prod
deny[msg] {
  input.spacelift.stack.labels[_] == "env:prod"
  input.spacelift.run.policy_receipt.approvals < 2
  msg := "prod stacks require two approvals"
}

You’re trading self-hosting and cost for a platform that handles drift detection, multi-stack orchestration, and policy out of the box. For a team running dozens of stacks across many teams, that managed layer is often worth paying for. For a small team with a handful of stacks, it can be more platform than you need.

How to choose

The decision comes down to a few honest questions:

• Who operates the control plane? If you want it in your own infrastructure with no third party seeing your state, Atlantis. If you’d rather not run the server, Spacelift.
• How many stacks and teams? A few stacks: Atlantis is plenty. Dozens of stacks with cross-dependencies and drift detection needs: Spacelift’s orchestration earns its cost.
• How much policy do you need? Atlantis pairs fine with Conftest in the same workflow. If you want policy as a first-class, centrally-managed feature, Spacelift has it built in.
• Budget posture? Atlantis is free software you host. Spacelift is a subscription. Factor in the engineer-time of operating Atlantis when comparing.

There’s no wrong answer — both make Terraform safer than laptop applies. Pick based on operational appetite, not feature checklists.

Guardrails that matter regardless of tool

Whichever you choose, a few principles keep the GitOps flow honest:

• The plan in the PR is the apply. Make sure the tool applies the saved plan, not a fresh re-plan at apply time. Otherwise drift between review and apply sneaks in.
• Gate prod harder than dev. More approvals, stricter policy, maybe a separate workflow. The blast radius justifies the friction.
• Centralize state and locking. The whole point is one source of truth. No more laptop state.
• Keep credentials in the runner, nowhere else. If an engineer can still terraform apply prod from a laptop, you haven’t actually closed the door.
• Run drift detection. Scheduled plans that alert when reality diverges from code catch the console change before it surprises you.

The payoff

Moving Terraform to a pull-request workflow is one of the highest-leverage changes a growing team can make. Applies become reviewable, auditable, and serialized; credentials leave laptops; and the plan everyone read is the plan that runs. Whether you self-host Atlantis or buy Spacelift, the discipline is the same — and it scales in a way that laptop applies never will.

A GitOps pipeline reviews the plan; it still helps to have something reviewing the change for risk before it gets there. That’s why we built our AI code review tooling to flag dangerous infra diffs early. For more on running Terraform safely as a team, see the full Terraform guides.

Examples are illustrative. Validate any GitOps configuration in a non-production repo before pointing it at infrastructure you can’t afford to break.