Atmos Pro enables you to define dependencies between your stacks and components, ensuring that infrastructure is provisioned in the correct sequence. This is crucial for complex environments where certain components must be available before others can be deployed.

During a plan (on pull requests), Atmos Pro dispatches plan workflows for all affected stacks respecting dependency order. However, because parent stacks haven't been applied yet, downstream plans may not fully reflect the final state — this is inherent to how Terraform planning works and is the same across every platform. Plans give you directional confidence, not a guaranteed preview of the final result.

During an apply (on merge), Atmos Pro enforces strict ordering: parent stacks are applied first, and child stacks only begin after their parents complete successfully. This ensures that each stack sees the real outputs of its dependencies, so your infrastructure is provisioned correctly and without race conditions.

For example, you can ensure that a VPC is created before a database is provisioned within it, or that a Kubernetes cluster is ready before applications are deployed to it. By defining these dependencies in your Atmos configuration, you can automate your deployment workflows with confidence, knowing that each part of your infrastructure will be deployed in the right order.

When code is pushed to a branch, a GitHub Actions workflow running inside the ghcr.io/cloudposse/atmos Docker container executes the atmos describe affected command to determine which stacks are affected by the code change.

Stacks are considered affected if their configuration changes, if there are any changes to the terraform code they are using, if any global configuration is changed, or if the stack is dependent on another stack that is affected.

Once the affected stacks have been determined with atmos, the GitHub Action uploads the list of affected stacks to the Atmos Pro API. The app then processes the list of affected stacks and determines the order in which stacks need to be deployed.

After determining the deployment order, Atmos Pro automatically dispatches the appropriate GitHub Actions workflows for each affected stack. Workflows are dispatched in dependency order—parent stacks are deployed first, followed by their dependents. This ensures that your infrastructure is provisioned safely and correctly, regardless of whether the trigger was a pull request, a merge, or a release event.