Why Atlantis Is Underadopted: A Technical Deep Dive

🪝 A few years ago, Atlantis felt like the obvious answer to “how do we run Terraform safely from pull requests?” Today, I mention it in a room full of platform engineers and get blank stares. This is an honest look at why — and whether that neglect is deserved.

1. Introduction

Infrastructure-as-Code changed how we manage cloud resources, but it introduced a new problem: how do teams collaborate on Terraform safely? Atlantis was one of the earliest, cleanest answers. Yet its adoption today lags well behind what its capabilities justify. This piece examines why.

2. What Atlantis Actually Does

Atlantis is a self-hosted application that automates Terraform via pull requests:

Get Aravindsri’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

How Atlantis handles a Terraform change:

1. PR opened → Atlantis automatically runs terraform plan
2. Plan posted → Output appears as a comment inside the PR for review
3. Workspace locked → Prevents concurrent, conflicting changes
4. Approval → A reviewer approves the proposed plan
5. atlantis apply → The change is applied and the lock is release

3. Why It Looked Like the Future

When I first adopted it, the wins were immediate:

• 🔒 State locking — no more “who’s applying right now?” Slack pings.
• 👀 Reviewable plans — reviewers see exactly what will change.
• 🗝️ Centralized credentials — no cloud secrets scattered across CI jobs.
• 💸 Free and open source — no per-seat licensing.

4. Architecture Overview

Understanding the friction requires understanding the setup:

Developer → GitHub PR → Webhook → Atlantis Server → Terraform → Cloud Provider

The Atlantis Server is the key component — and also the source of most adoption friction. It must be:

• Hosted somewhere (VM, container, Kubernetes)
• Reachable by your Git provider’s webhooks
• Maintained, upgraded, and secured over time

5. Why Adoption Is Lower Than It Should Be

5.1 Somebody has to run it

Self-hosting means infrastructure, uptime responsibility, and upgrade cycles. For small teams, that’s meaningful overhead for what is “just” a workflow tool.

5.2 Managed alternatives removed the pain

Terraform Cloud/HCP delivers PR-driven plans, remote state, locking, and policy-as-code — with zero servers to maintain. For teams that want the outcome, managed beats self-hosted.

5.3 GitHub Actions ate the middle

Many teams already live in GitHub Actions. A workflow that runs plan on PR and apply on merge is "good enough" — no new tool, no new attack surface to secure.

5.4 Mindshare moved on

Atlantis didn’t get worse. The conversation shifted toward managed platforms with bigger marketing footprints.

6. Comparison

🟦 Atlantis

• Setup effort: High (self-hosted)
• Cost: Free (open source)
• Maintenance: You own it
• Control / privacy: Full
• Vendor lock-in: None

🟩 Terraform Cloud / HCP

• Setup effort: Low (SaaS)
• Cost: Free tier → paid
• Maintenance: Vendor-managed
• Control / privacy: Limited
• Vendor lock-in: Higher

🟨 GitHub Actions

• Setup effort: Medium
• Cost: CI-minutes cost
• Maintenance: Vendor-managed
• Control / privacy: Medium
• Vendor lock-in: GitHub-tied

7. When Atlantis Still Wins

To stay honest — it’s far from obsolete:

• ✅ You want PR-native Terraform without a SaaS bill or lock-in.
• ✅ You need full control over the runtime environment.
• ✅ Compliance requires keeping state/plans in-house.

For those teams, Atlantis is arguably still the best option available.

8. Conclusion

Atlantis isn’t underadopted because it stopped being good. It’s underadopted because the market optimized for convenience, and a self-hosted tool loses the “easy” contest by default. “Easy” and “right” aren’t always the same thing — and for teams that value control and cost, Atlantis deserves a fresh evaluation.

Annexures:

1️⃣ The Terraform Collaboration Problem (Section 1)

flowchart TD
    A[Engineer 1] -->|terraform apply| S[(Shared State)]
    B[Engineer 2] -->|terraform apply| S
    C[Engineer 3] -->|terraform apply| S
    S -->|Conflict / Drift| X[💥 State Corruption]

Caption: The core problem Atlantis was built to solve — uncoordinated changes to shared state.

2️⃣ Atlantis Architecture & Flow (Section 4)

flowchart LR
    Dev[Developer] -->|Opens PR| PR[GitHub Pull Request]
    PR -->|Webhook| AT[Atlantis Server]
    AT -->|terraform plan| TF[Terraform]
    TF -->|API calls| CP[Cloud Provider]
    AT -->|Posts plan comment| PR
    Dev -->|atlantis apply| AT

Caption: The webhook → server → Terraform → cloud flow. The self-hosted server is both the power and the maintenance burden.

3️⃣ The Atlantis PR Lifecycle (Section 2)

stateDiagram-v2
    [*] --> PROpened
    PROpened --> PlanRunning: webhook triggers
    PlanRunning --> PlanPosted: plan output as comment
    PlanPosted --> Locked: workspace locked
    Locked --> Approved: reviewer approves
    Approved --> Applied: atlantis apply
    Applied --> [*]: lock released

Caption: The plan-lock-approve-apply lifecycle that made Atlantis loved.