Atlantis puts Terraform plan and apply in the pull request
Atlantis receives a webhook when Terraform code changes, runs terraform plan, and posts the output back to the pull request. An authorized reviewer can then comment atlantis apply to run the saved plan. The workflow makes proposed infrastructure changes visible beside the code and keeps execution off individual laptops. It also locks a directory and workspace until the pull request is merged or someone removes the lock.
The model works across GitHub, GitLab, Bitbucket, Azure DevOps, and Gitea. Teams can require approval or mergeability, add policy checks, pin tool versions, and define workflows for monorepos or unusual backends. GitHub showed 9,260 stars and 898 combined issues and pull requests when fetched. That open count is not a bug count, but it signals a large surface with many current integrations and operating patterns.
The service holds credentials powerful enough to change infrastructure
Atlantis needs VCS access to clone repositories and post results. It also needs the cloud and provider credentials used by Terraform, an HTTPS endpoint for webhooks, persistent working data, and a repository allowlist. The security guide recommends webhook secrets, web authentication, TLS, and restricted outbound access. These are baseline controls for a service whose normal job includes running code and changing remote infrastructure.
Apply approval does not make every earlier step safe. The official security page explains that a malicious provider or external data source can execute during terraform plan. Custom commands in atlantis.yaml are read from the pull-request branch rather than the trusted main branch. Public repositories are specifically discouraged. Server-side policy, provider controls, and egress restrictions have to protect the plan stage before any reviewer considers applying it.
What happened when we ran it
Our Node 22 sandbox installed 300 npm packages in 31 seconds and used 306 MB on disk. Npm audit reported 0 known vulnerabilities across that installed dependency set. The checkout at commit a655de6 contained 1,286 files, about 157,048 lines of source, and occupied 20.8 MB. It also had 18 CI workflow files, a Dockerfile, and a Compose file.
No build script or target was present for our npm harness, so that step was skipped. The same was true for tests: there was no npm test script or target to run. Atlantis is primarily a Go application, and these results should not be mistaken for a Go server build or its full test suite. Our run proves that the root npm dependency installation completed cleanly; it does not prove the server compiles or passes its own checks.
Version 0.47.1 fixed pull-request input reaching a shell
Release v0.47.1 was published on August 20, 2026 with one security change: it prevents pull-request input from reaching a shell under advisory GHSA-rjh2-4xgw-p2hj. That is a reason to stay current, especially when custom workflows and untrusted branch content share a process with infrastructure credentials. Pinning an older image because it already works can preserve exactly the class of input-handling flaw operators should remove quickly.
A separate issue filed on August 27 reports that Atlantis v0.47.1 exposed an unsanitized GitLab clone URL during a plan-status deserialization error. The URL included the access token, according to the redacted report. Treat that as an open report, not a confirmed universal behavior. GitLab operators should reproduce the error path safely, restrict log access, rotate any token that appears, and follow the issue before upgrading sensitive installations.
Two or more replicas add plan and lock failure modes
Atlantis can be deployed through a binary, Docker, Kubernetes, Helm, and documented cloud patterns. Scaling it changes the problem because a plan created on one replica must still be available when an apply lands on another. Shared locking and external plan storage address that need. They also introduce more state whose consistency matters at exactly the moment an approved infrastructure change is about to run.
Issue 6806 describes a 2-or-more-replica setup using Redis locks and S3 plan storage. A valid plan uploaded to S3 could be skipped when the apply replica already had a local pull directory without the plan file. The command then failed or, on another path, restored a plan inconsistent with local initialization state. High-availability buyers should rehearse cross-replica plan, apply, restart, and failed-autoplan sequences before calling the deployment ready.
Current activity is high, and upgrades still need rehearsals
The last push was August 28, 2026, 8 days after v0.47.1. New issues and pull requests were active on August 27. Atlantis is plainly maintained, and its documentation covers security, access credentials, deployment, repository policy, custom workflows, locking, upgrades, and several VCS providers. The size of the open queue reflects both adoption and the number of combinations the project supports.
One current upgrade report says BoltDB records created on v0.43.0 or earlier can fail to deserialize after moving to v0.44.0 or newer when policy approvals are stored in the older shape. The reported workaround is to re-plan affected pull requests. That is the kind of state migration a staging exercise catches. Atlantis is a sensible default for PR-centered Terraform, provided upgrades and credentials receive production-level care.