Deployment Locking

Prevent multiple workflows from running on the same deployment at the same time with deployment locking in Atmos Pro.


When working in a team, it's common for multiple pull requests to trigger workflows targeting the same deployment. But which one should run first? What happens if they overlap?
Deployment locking helps you avoid conflicts by making sure only one workflow can run on a given stack at a time.

With Deployment Locking, you can:

Prevent multiple deployments on the same stack

Avoid race conditions and state corruption

Ensure a stable and predictable deployment workflow

Forcefully unlock deployments when needed

Atmos Pro lets you place a lock on a specific deployment. While that deployment is locked, Atmos Pro will refuse to dispatch any new workflows targeting it. This prevents race conditions when multiple PRs are opened at once.
Locks are advisory—they don't block the actual atmos CLI from executing locally or in CI. They only affect whether Atmos Pro will dispatch a workflow for that stack.
  • A deployment can be either locked or unlocked—there is no concept of lock "ownership."
  • If a lock is active and hasn't expired, any new attempt to lock the same deployment will fail.
  • You can forcefully unlock a deployment using the unlock command.
  • All locks include a TTL (time to live), so they expire automatically after a set duration—even if someone forgets to unlock them.

Security Note

Deployment locking is for coordination, not security. It's meant to help teams avoid accidental overlap—not enforce access control.
Deployment locking is a critical feature that prevents multiple developers or CI/CD jobs from running atmos terraform apply on the same stack simultaneously. This ensures that your infrastructure state remains consistent and avoids potential conflicts or data corruption.
When a deployment starts, Atmos Pro acquires a lock on the stack being deployed. If another deployment attempts to start for the same stack, it will be forced to wait until the first deployment is complete and the lock is released. This mechanism is essential for maintaining a stable and predictable infrastructure automation workflow, especially in team environments.

Ready to configure deployment locking?

Visit the deployment locking configuration page to set it up.