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.

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.

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.