Atlantis automates terraform plan and terraform apply directly from pull request comments, but its directory locking is often confused with Terraform’s own state lock already documented: these are two independent mechanisms, each protecting against a different concurrency scenario.
What Atlantis actually locks
When a pull request triggers a terraform plan on a given directory, Atlantis places an application-level lock on that directory (and workspace combination), preventing a second pull request touching the same directory from running its own plan or apply until the first one is merged or closed.
# A second PR touching the same Terraform directory
# gets this message as long as the first PR stays open
This project is currently locked by an unapplied plan from pull #42
This lock lives at the Atlantis level itself, in its own internal database, entirely independent of any native Terraform mechanism.
What Terraform’s state lock locks, separately
Terraform’s state lock (managed by the remote backend, DynamoDB for S3, or natively for other backends) stops two simultaneous terraform apply runs from writing to the same state file at once, regardless of how those runs were triggered, whether through Atlantis, a regular CI pipeline, or a terraform apply run manually from a laptop.
Why the distinction matters
An operator who bypasses Atlantis’s PR lock (by running terraform apply manually while a PR stays open, for instance) doesn’t thereby bypass Terraform’s state lock: that second lock keeps applying, independent of Atlantis, protecting the state against a concurrent write corruption even when the first lock was ignored. Conversely, disabling or misconfiguring Terraform’s state lock doesn’t disable Atlantis’s PR lock at all, which keeps blocking a second pull request on the same directory as long as the first one stays open.
Takeaway
Atlantis locks a directory at the pull-request level, preventing two concurrent PRs from planning or applying against the same Terraform directory, a mechanism managed entirely in Atlantis’s own internal database. Terraform’s state lock separately protects against concurrent writes to the state file itself, regardless of how the run was triggered. Bypassing one of the two locks never disables the other: both mechanisms protect against distinct concurrency scenarios and operate independently of each other.