atlantis

Atlantis brings infrastructure changes into the same pull-request conversation as a code review. When someone proposes a Terraform change, Atlantis can run a plan showing the expected changes and post the result for the team to inspect. It can then run the apply step that changes the real infrastructure. Teams use it to avoid passing plans around manually, while keeping careful control of who can trigger that privileged work.

Current guidance

Atlantis connects infrastructure pull requests to Terraform planning and applying. Its upstream guide describes posting plan results back to the pull request and applying a saved plan. Pull-request approval is enforced only when configured: set the approved apply requirement where review must gate execution; command requirements are empty by default. This is an infrastructure workflow tool; installing it in Kubernetes does not make Terraform changes subject to Kubernetes admission policy.

Treat repository access as part of the execution boundary. The security documentation explains why planning untrusted Terraform can execute code. Restrict the repository allowlist, control who can edit server-side workflows, protect webhook secrets, and give the runtime credentials only the infrastructure permissions the selected repositories need. Review fork pull requests and custom workflow permissions before enabling automation.

Choose persistent storage for the working directory and plan files, and configure the Terraform backend and state locking independently of Atlantis project locks. Rehearse simultaneous changes, a failed apply, a server restart and plan expiry with a disposable backend. Review the current upstream Helm chart separately from the Atlantis image and Terraform or OpenTofu version; this page has not certified a particular chart, cloud credential model or production upgrade.