Atlantis vs the alternatives

TFC, Spacelift, env0, CI.

Every team that automates Terraform ends up at the same fork you hit about getting to work each morning: build, own, share, or hire. You can bolt a car together from parts (plain CI, short for continuous integration, meaning the pipeline scripts you write and babysit yourself). You can buy a car and maintain it (Atlantis). You can join a car-share that parks in your own driveway (CI-native tools like Digger). Or you can hire a chauffeur (managed platforms like HCP Terraform and Spacelift). All four get a Terraform plan onto a pull request. They differ in who does the maintenance, who holds the keys (literally, the cloud credentials), and who you phone when it breaks. The industry half-jokingly calls the whole category TACOS, for *Terraform Automation and COllaboration Software*. Eleven lessons in, you know what owning the car actually costs. That is what lets you judge the alternatives on trade-offs instead of tribal loyalty.

The four camps

Three families, plus a baseline you already own. Self-hosted open source is the Atlantis model: one server you run, driven entirely by comments on a pull request. *Terrakube* pushes the same idea further with a web interface, remote state storage, and a module registry, aiming to be an open-source Terraform Cloud. CI-native hybrids like *Digger* and *Terrateam* borrow the build machines you already pay for (usually GitHub Actions) to run terraform, and add a thin coordinator that handles locks and posts comments. No server sits there permanently holding cloud credentials. Managed platforms are vendor-run services that bundle remote state, policy engines, drift detection, RBAC (role-based access control, the rules for who may do what) and SSO (single sign-on, one company login for everything): *HCP Terraform* (HCP is HashiCorp Cloud Platform; the product was renamed from Terraform Cloud in 2024), *Spacelift*, *env0*, and *Scalr*. The baseline is plain CI: pipelines you write yourself.

Strip any comparison in this market down and you are left with three questions. Who runs the machine that executes terraform, and therefore holds your most powerful cloud credentials? Who stores the state file, with all the secrets baked into it? Who enforces policy, and in what language? Atlantis answers all three the same way: you. You run the server. You bring the backend (S3, GCS, or azurerm, meaning storage on Amazon, Google, or Azure). You wrote the Conftest policy checks you wired into the flow earlier in this course. Every alternative shifts at least one of those answers onto somebody else's computers.

What Atlantis deliberately leaves out

Atlantis is a kettle, not a kitchen. One binary written in Go, one job: turn webhook events (your Git host pinging your server whenever something happens) and pull request comments into locked terraform plan and apply runs. It does not store state. You bring a backend, and Atlantis holds a working copy while a run is in flight, nothing more. It has no drift detection, so nothing watches your cloud for changes made outside Terraform between pull requests. Access control is whatever your Git host already enforces. There is no single sign-on, no private module registry, no cost estimation, and the page it serves you is a lock index and a job log. Every one of those gaps is a paid line item on a managed platform's price list. Every one is also attack surface, data to back up, and weight Atlantis never has to carry. One gap it did close: Terraform's 2023 move to the Business Source License (BSL, a licence that blocks commercial competitors) spawned the *OpenTofu* fork under the Linux Foundation, and Atlantis added first-class OpenTofu support, selectable as the server's default Terraform distribution.

Plain CI: the thing you would have to build anyway

Before you give any product credit, price the parts-bin version. On the page it looks finished.

# The DIY pattern Atlantis replaces: plan on PR, apply on merge
name: terraform
on:
  pull_request:
    paths: ["infra/**"]
  push:
    branches: [main]
    paths: ["infra/**"]
 
permissions:
  contents: read
  pull-requests: write   # needed to post plan output as a comment
 
jobs:
  plan:
    if: github.event_name == 'pull_request'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: hashicorp/setup-terraform@v3
        with:
          terraform_version: "1.9.8"
      - run: terraform -chdir=infra init -input=false
      - run: terraform -chdir=infra plan -input=false -out=tfplan
      # Still missing: posting the plan as a PR comment, per-directory
      # locking, an interactive apply gate, stale-plan invalidation.
 
  apply:
    if: github.event_name == 'push'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: hashicorp/setup-terraform@v3
        with:
          terraform_version: "1.9.8"
      - run: terraform -chdir=infra init -input=false
      - run: terraform -chdir=infra apply -input=false -auto-approve

That workflow does plan, and it does apply. It also quietly skips everything the middle of this course was about. No per-project locking, so two pull requests can wrestle over one state file. The plan output never lands where reviewers actually read, which is the pull request itself. No interactive apply gate, so you get apply-on-merge-and-hope instead of a human commenting atlantis apply once the change is approved. Nothing scopes the plan to the directories that changed. Nothing throws away a stale plan when a new commit arrives. Each of those is buildable. Teams rebuild them constantly, and usually worse. Plain CI is still the right call when Terraform is a small slice of what you run, applies are rare, and having one pipeline system for everything beats running an extra server that fits Terraform better.

Renting the whole thing

HCP Terraform is the incumbent, the hotel chain of this market: remote state with locking and encryption, plan and apply driven from your version control system, a private module registry, and policy written in *Sentinel* (HashiCorp's own proprietary language) or in OPA (Open Policy Agent, an open-source policy engine). The free tier stops at 500 managed resources. Past that you pay per resource under management, a meter that climbs as your estate grows whether or not you ever run another plan. HashiCorp has belonged to IBM since early 2025. Set that next to the BSL relicense and you have the case study to reach for when someone asks what *vendor risk* means for a tool your deploys depend on. The migration itself is startlingly small: one cloud block and two commands.

$ cat infra/backend.tf
terraform {
  cloud {
    organization = "acme-corp"
    workspaces {
      name = "network-prod"
    }
  }
}
 
$ terraform login
# ...browser opens app.terraform.io; token saved to credentials.tfrc.json
Success! Terraform has obtained and saved an API token.
 
$ terraform -chdir=infra init
Initializing HCP Terraform...
HCP Terraform has been successfully initialized!
 
$ terraform -chdir=infra plan
Running plan in HCP Terraform. Output will stream here. Pressing Ctrl-C
will stop streaming the logs, but will not stop the plan running remotely.
 
To view this run in a browser, visit:
https://app.terraform.io/app/acme-corp/network-prod/runs/run-Kq8VbC3mTpXw2fUe
 
Plan: 2 to add, 0 to change, 0 to destroy.

Spacelift is the strongest commercial rival: policies in Rego (OPA's policy language) attached to every stage of a run's life, drift detection that can optionally fix what it finds, and *private workers* so credentials never leave your network. It also drives OpenTofu, Pulumi, CloudFormation, Ansible, and Kubernetes. env0 cares about the life of an environment, with TTLs (time to live, an expiry clock) on throwaway environments, plus cost tracking. Scalr ships an opinionated environment hierarchy and bills by *run* rather than by resource, free up to 50 runs a month and per-run after that, which is a deliberate jab at HCP's resource meter. The interesting newcomers are the CI-native hybrids. With *Digger* or *Terrateam*, terraform executes on your own GitHub Actions runners, so cloud credentials stay in the secret store your CI already has and there is no separate server to harden. The coordinator only sequences jobs, holds locks, and posts comments. You give up years of battle testing that Atlantis has and get back a smaller blast radius (less damage if a credential leaks) and a younger ecosystem.

Picking one, and closing the loop

The decision compresses well. Pick Atlantis when you want Terraform-native pull request automation fully under your own control: compliance says self-host, you have the platform people to run it, and the features you would otherwise pay for (drift detection, access control, a registry) already live elsewhere in your stack. Pick a managed platform when that feature list *is* the product you want, and metered pricing plus trusting a vendor both sit fine with you. Pick Digger or Terrateam when you like the Atlantis workflow but will not operate an always-on server holding credentials. Pick plain CI when Terraform is a side dish. One boundary worth drawing before you go shopping: Argo CD and Flux reconcile Kubernetes clusters from Git, a neighbouring problem covered in the GitOps courses, and not a rival answer for Terraform.

That warning is the shape of this whole course in miniature. You deployed a server and pointed webhooks at it. You drove plan and apply from pull request comments. You watched locks serialize work per project. You shaped behaviour with atlantis.yaml, projects, custom workflows, and autoplan. You put policy checks in the path. Then you drew the trust boundary with server-side config, cut the credentials down to size, and hardened the box. The real test is whether that entire chain holds together across a single pull request.

# 1. Server healthy?
$ curl -s https://atlantis.example.com/healthz
{"status":"ok"}
 
# 2. Open a Terraform-touching PR and drive it entirely from comments
$ gh pr create --title "network: widen node CIDR" --body "INFRA-142"
https://github.com/acme/infra/pull/312
 
# Autoplan fires on the webhook; or trigger it explicitly:
$ gh pr comment 312 --body "atlantis plan -d network"
 
# Atlantis replies on the PR:
#   Ran Plan for dir: `network` workspace: `default`
#   Plan: 2 to add, 0 to change, 0 to destroy.
#   * To apply this plan, comment: `atlantis apply -d network`
#   * To delete all plans and locks for the PR, comment: `atlantis unlock`
 
# 3. A teammate approves (apply_requirements: [approved, mergeable]), then:
$ gh pr comment 312 --body "atlantis apply -d network"
 
# Atlantis replies:
#   Ran Apply for dir: `network` workspace: `default`
#   Apply complete! Resources: 2 added, 0 changed, 0 destroyed.

Run that sequence clean, with the policy check blocking what it should, the lock index showing what you expect, and the apply gate refusing an unapproved pull request, and you have crossed from operating Atlantis to understanding it. Every alternative in this lesson sells features stacked on top of that same mechanism. You own the mechanism, which is precisely what qualifies you to decide whether to keep it.

Try this

Write a one-page comparison for your team: Atlantis, plain CI, and one managed TACOS product you could realistically buy. Score each on three things. How much maintenance does it cost you? Who ends up holding the cloud credentials? What does the pull request feel like for the person reviewing it?

# optional: skeleton CI plan for contrast
terraform plan -input=false -no-color
# ask: who holds cloud creds? who posts the plan? who can apply?

CI plan exit 0 — but apply still needs a human gate you invent
Atlantis — plan comment + apply comment + lock included
Managed TACOS — same ritual, less server toil, different price and data plane

Takeaway

TACOS names the category. Atlantis is the self-hosted, pull-request-native member of it. Choose on three axes: who holds the credentials, how much maintenance you can stomach, and which features you genuinely need (policy, drift, cost). Loyalty is not one of the axes.

Next: if you keep Atlantis, budget real time for hardening and upgrades. If you leave, move your project definitions and policy gates across on purpose, so apply authority never quietly slides back onto somebody's laptop.

Related