# Atlantis (runatlantis/atlantis): Terraform plan and apply from pull request comments

> Atlantis is a self-hosted Go application that listens for Terraform pull request webhooks, runs plan, import and apply remotely, and comments the output back on the PR. Here is how it is wired, how to install it, and where it stops being the right tool.

**runatlantis/atlantis** — Terraform Pull Request Automation. Atlantis Terraform Pull Request Automation Resources What is Atlantis?

- Repository: https://github.com/runatlantis/atlantis
- Website: https://www.runatlantis.io
- Stars: 9,301 · Forks: 1,349
- Language: Go
- License: Apache-2.0
- Published: 2026-08-04 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/runatlantis-atlantis

## The problem Atlantis solves is the gap between a Terraform diff and a reviewer

Terraform changes are hard to review as text. A plan is the only artifact that shows what will actually happen, and it is produced by whoever runs the command, on their machine, with their credentials. Atlantis moves that step to a server. The README describes it as "a self-hosted golang application that listens for Terraform pull request events via webhooks", and the stated purpose is to run terraform plan, import and apply remotely and comment the output back on the pull request. The audience is teams where infrastructure changes go through code review, including reviewers who do not run Terraform themselves. The README's own justification list is short and specific: make Terraform changes visible to the whole team, let non-operations engineers collaborate, and standardize workflows. That last point is the real one. If five engineers run plan locally, they get five slightly different results depending on provider versions, environment variables and state freshness. One server removes that variance.

## How the webhook to comment loop actually works

The mechanism is a long-running server plus a set of repository-level configuration files. A pull request event arrives over HTTP, the server matches it against projects discovered in the repository, clones or fetches the code, runs the requested Terraform command in the right directory, and posts the result back as a comment. Apply is not automatic on merge: it is triggered by a comment on the pull request, which is why the project describes itself in terms of pull request automation rather than CI. The repository layout confirms the shape of the system: cmd/ and server/ hold the Go application, main.go is the entry point, docs/ and runatlantis.io/ hold the documentation site (a VitePress project, per package.json, with a website:dev script on port 8080 and a website:build script), and e2e/ plus playwright.config.cjs hold end-to-end tests. The Go module list is a useful map of what the server integrates with: go-github, a Gitea SDK, an Azure DevOps client, ghinstallation for GitHub App authentication, go-redis for the persistence layer, aws-sdk-go-v2 with the S3 service for remote state or storage, hc-install and terraform-config-inspect for locating and reading Terraform binaries and configuration, and tofudl, which points at OpenTofu download support. That dependency set tells you Atlantis is not a thin webhook proxy. It is a job runner with its own knowledge of Terraform versions, repository configuration and forge APIs.

## Installing Atlantis and getting a first plan comment

The README points to www.runatlantis.io/guide for getting started and to the releases page for the binary, and it does not reproduce install steps itself, so the guide is the authoritative source for flags and configuration. What the repository does show is the local development path, which is also the fastest way to see the loop work. The docker-compose.yml file is explicitly marked as being for local development and defines three services: redis, atlantis and ngrok. The ngrok service forwards to atlantis:4141, which is the port Atlantis listens on in this setup, and both atlantis and ngrok read an atlantis.env file that is not in the repository listing, so you supply it. The atlantis service builds from Dockerfile.dev and mounts ${HOME}/.ssh and the current directory read-only.

```bash
docker compose up
```

The redis service in that file starts with a password of test123 and persists to a named volume, which is fine for a laptop and obviously not for anything else. If you prefer to run the binary directly, the README sends you to the releases page rather than giving a package manager command, so there is no install one-liner to quote here. For production, the Dockerfile is the artifact that matters, and it is worth reading before you deploy: it pins ALPINE_TAG, DEBIAN_TAG and GOLANG_TAG by digest, and it takes Terraform versions as build arguments. TERRAFORM_1_15_VERSION is 1.15.9, TERRAFORM_1_16_VERSION is 1.16.0, DEFAULT_TERRAFORM_VERSION defaults to the 1.16 value, DEFAULT_OPENTOFU_VERSION is 1.12.6 and DEFAULT_CONFTEST_VERSION is 0.66.0. Those versions are baked in at build time, so the image you deploy determines which Terraform binaries exist inside it. Check that list against the version constraints in your own modules before you point a repository at the server.

## Where Atlantis is the wrong tool

The clearest limitation is architectural, not a bug: Atlantis is a server that must be reachable from your Git host. If your repositories live somewhere that cannot deliver a webhook to your network, the whole model collapses, and the ngrok service in the development compose file is a hint about how much of the setup depends on inbound connectivity. The second constraint is credentials. The server needs enough access to read repositories, comment on pull requests and run Terraform against your cloud accounts. That makes it a high-value target, and the repository reflects that concern with a SECURITY.md and a CODEOWNERS file, but the operational burden is yours. Third, Atlantis owns the apply path. Teams that already have a CI system holding state and cloud credentials now have two places where infrastructure can change, and reconciling them is a design decision the documentation will not make for you. Finally, the README is thin on failure behaviour. It does not document rollback, it does not describe what happens when a plan is stale relative to the branch, and it does not discuss concurrency beyond what the guide covers. If your workflow depends on those guarantees, read the full docs before committing, not the README.

## Atlantis compared with running Terraform in a general CI pipeline

The alternative most teams weigh is a general-purpose CI system such as GitHub Actions or GitLab CI running Terraform steps directly. The difference is where the trigger lives. In a CI pipeline, the unit of work is a job attached to a commit or a pull request event, and the output lands in the CI log or as a status check. In Atlantis, the unit of work is a comment on the pull request, and the output is a comment on the pull request. That sounds cosmetic and is not. A comment is readable by anyone with repository access, it persists in the conversation next to the diff, and it can be re-triggered without pushing a new commit. It also means the apply step is a deliberate human action inside the review thread rather than a merge event. The trade-off is that you now operate a stateful server with a database or Redis behind it, and you inherit its availability. A CI pipeline is someone else's uptime. Atlantis is yours.

## Maintenance, releases and what the Apache-2.0 licence means in practice

The project is not archived, and the last push to main was on 2026-08-20, the same day as the v0.47.1 release. The release cadence visible here is roughly two months between minor versions, with v0.46.0 on 2026-06-30, v0.47.0 on 2026-08-18 and v0.47.1 two days later. That is a normal patch-after-minor pattern. Upgrading means replacing a container image and restarting the server, and the pinned Terraform and OpenTofu versions inside that image are the part most likely to affect you, since a version bump can change plan output for the same configuration. The licence is Apache-2.0, which is permissive and includes an explicit patent grant; the repository carries a LICENSE file and package.json declares the same identifier for the documentation tooling. Apache-2.0 does not obligate you to publish modifications, but it does require preserving notices and the licence text. That is a summary of the licence text, not legal advice. If you are embedding Atlantis in a product or modifying it for distribution, have your own counsel read the file.

## Conclusion

Adopt Atlantis if your team already reviews Terraform through pull requests, wants plan output visible to everyone in the PR, and is willing to run and secure one more self-hosted service with credentials that can change infrastructure. Do not adopt it if you have no inbound webhook path to the host, or if your workflow is driven from a CI runner that already holds state and credentials and you do not want a second apply path. Before rolling it out, verify three things on a throwaway repository: that the webhook reaches the server and a plan comment appears, that your chosen backend and locking behaviour survive two concurrent pull requests, and which Terraform versions the image you deploy actually ships, since the Dockerfile pins versions through build arguments rather than resolving them at runtime.

## FAQ

### What is Atlantis (runatlantis/atlantis)?

It is a self-hosted Go application that listens for Terraform pull request events via webhooks, runs terraform plan, import and apply remotely, and comments the output back on the pull request.

### How do I install Atlantis?

The README points to www.runatlantis.io/guide for getting started and to the GitHub releases page for the latest release, and it does not list install commands itself. The repository's docker-compose.yml is marked as being for local development only and runs atlantis, redis and ngrok together.

### Which Terraform versions does the Atlantis Docker image include?

The Dockerfile takes Terraform versions as build arguments, with TERRAFORM_1_15_VERSION set to 1.15.9 and TERRAFORM_1_16_VERSION set to 1.16.0, and DEFAULT_TERRAFORM_VERSION defaulting to the 1.16 value. It also defines DEFAULT_OPENTOFU_VERSION as 1.12.6 and DEFAULT_CONFTEST_VERSION as 0.66.0.

### Which Git hosts can Atlantis connect to?

The Go module dependencies include go-github and ghinstallation for GitHub, a Gitea SDK and an Azure DevOps client, so those forge integrations are present in the codebase. The README itself does not enumerate supported hosts.

## Sources

- [Official documentation](https://www.runatlantis.io)
- [Official README](https://github.com/runatlantis/atlantis#readme)
- [Project repository](https://github.com/runatlantis/atlantis)
- [Release notes](https://github.com/runatlantis/atlantis/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/runatlantis-atlantis