Ordered Deployments

Atmos Pro understands the dependency relationships between your stacks and components and dispatches workflows in the correct order.


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.

With Ordered Deployments, you can:

Define dependencies between stacks and components

Ensure infrastructure is deployed in the correct order

Automate complex deployment workflows with confidence

Avoid race conditions in provisioning

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.

Ready to configure ordered deployments?

Visit the Atmos configuration page to set up ordered deployments.

The process starts when a developer makes some changes to the Atmos stacks or terraform modules in their infrastructure repository, opens a feature branch, and pushes the code changes to the feature branch.
On pull requests, Atmos Pro triggers atmos terraform plan:
  1. 1
    Developer Makes a Change
  2. 2
    Code Is Pushed to Feature Branch
  3. 3
    GitHub Actions Trigger Atmos Affected Stacks
  4. 4
    Atmos Uploads Affected Stacks
  5. 5
    Atmos Pro Dispatches Plan Workflows
  6. 6
    Atmos Pro Updates Status Comment
When code is pushed to a branch, Cloud Posse's Atmos Affected Stacks GitHub Action runs 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.