Atlantis alternatives for OpenTofu and Terraform pull request automation
Atlantis made pull request automation for Terraform popular: comment, plan, review, apply. It is still a good fit for some teams. Here is where it shines, where it starts to hurt, and what the alternatives look like.
What Atlantis does
Atlantis is an open-source server that listens for pull request webhooks. When a pull request changes infrastructure code, it runs plan and posts the output as a comment. A reviewer reads it, approves the pull request, and someone comments atlantis apply. Atlantis then applies and comments the result, usually before the branch merges.
Teams like it because:
- it is free and open source;
- it keeps the whole workflow inside the pull request;
- it works with OpenTofu and Terraform; and
- it runs in your own network, next to private resources.
Where teams outgrow it
You operate it
Atlantis is a long-running server with write access to your cloud. You patch it, scale it, back it up, and keep its webhook endpoint reachable. When it is down, nobody ships infrastructure.
Credentials live on the server
Every repository Atlantis serves shares the server's cloud credentials unless you build per-project roles yourself. Any pull request that triggers a plan runs code on a machine that can usually reach production credentials.
State is still your problem
Atlantis doesn't store state. You still run an S3, Google Cloud Storage, or Azure backend with locking, versioning, and access controls, and you audit who can read it.
Apply before merge
The default workflow applies from the branch and merges afterwards. If the apply partly fails, the main branch no longer describes what is deployed until someone fixes it.
Governance is bolted on
Policy checks, audit trails, SSO, and fine-grained approval rules are possible but take configuration and extra tools.
The alternatives
| Option | You run | Good for |
|---|---|---|
| Atlantis | Server, state backend, credentials, policy | Teams that want full control and private network access |
| CI pipelines, such as GitHub Actions | Workflows, state backend, locking, approvals | A few stacks and a team comfortable owning the pipeline |
| A managed platform | Nothing but your configuration | Teams that want runs, state, policy, and audit as a service |
We compare the CI option in detail in OpenTofu in GitHub Actions vs a managed platform.
How StackShip handles the same workflow
- Pull requests get a speculative plan and policy check, reported as a GitHub check. They never apply and never receive sensitive variables or apply credentials.
- Merging to the tracked branch starts a plan for the merged commit, which waits for an owner or admin to approve. Main always describes what you asked to deploy.
- Credentials are short-lived and scoped per workspace and per phase, so pull request plans can get a read-only role.
- State is versioned, locked, and downloadable, with every raw download recorded in the audit log.
- Policy is Open Policy Agent (Rego), checked on every plan.
The trade-off is honest: StackShip is hosted, and its runs can't reach private networks. If your configuration must talk to resources reachable only inside your VPC, a self-hosted runner such as Atlantis is still the right tool.
Moving from Atlantis
- Export each project's state with
tofu state pulland push it into a new workspace. The migration guide shows the commands. - Map each
atlantis.yamlproject to a workspace. Itsdirbecomes the working directory and itswhen_modifiedpatterns become trigger paths. - Replace server credentials with one credential profile per workspace.
- Turn off Atlantis for that repository before the first StackShip apply, so only one system can change the infrastructure.