Skip to main content

Spacelift Integration

Atmos natively supports Spacelift. This is accomplished using the cloudposse/terraform-spacelift-cloud-infrastructure-automation terraform module that reads the YAML Stack configurations and produces the Spacelift resources.

Cloud Posse provides two terraform components for Spacelift support:

Stack Configuration

Atmos components support the following spacelift specific settings:

# enable the stack in Spacelift
workspace_enabled: true

administrative: true

# auto deploy this stack
autodeploy: true

# commands to run before init
before_init: []

# Specify which component directory to use
component_root: components/terraform/example

description: Example component

# whether to auto destroy resources if the stack is deleted
stack_destructor_enabled: false

worker_pool_name: null

# Do not add normal set of child policies to admin stacks
policies_enabled: []

# set explicitly below
administrative_trigger_policy_enabled: false

# policies to enable
- trigger-administrative-policy

OpenTofu Support

Spacelift is compatible with OpenTofu and configurable on a global and per stack or component basis.

To make OpenTofu the default, add the following to your top-level stack manifest:

# Use OpenTofu
terraform_workflow_tool: OPEN_TOFU

Similarly, to override this behavior, or to only configure it on specific components, add the following to the component configuration:

# Use OpenTofu
terraform_workflow_tool: OPEN_TOFU

For more details on Atmos support for OpenTofu see our integration page.

Spacelift Stack Dependencies

Atmos supports Spacelift Stack Dependencies in component configurations.

You can define component dependencies by using the settings.depends_on section. The section used to define all the Atmos components (in the same or different stacks) that the current component depends on.

The settings.depends_on section is a map of objects. The map keys are just the descriptions of dependencies and can be strings or numbers. Provide meaningful descriptions or numbering so that people can understand what the dependencies are about.

Each object in the settings.depends_on section has the following schema:

  • component (required) - an Atmos component that the current component depends on
  • namespace (optional) - the namespace where the Atmos component is provisioned
  • tenant (optional) - the tenant where the Atmos component is provisioned
  • environment (optional) - the environment where the Atmos component is provisioned
  • stage (optional) - the stage where the Atmos component is provisioned

The component attribute is required. The rest are the context variables and are used to define Atmos stacks other than the current stack. For example, you can specify:

  • namespace if the component is from a different Organization
  • tenant if the component is from a different Organizational Unit
  • environment if the component is from a different region
  • stage if the component is from a different account
  • tenant, environment and stage if the component is from a different Atmos stack (e.g. tenant1-ue2-dev)

In the following example, we specify that the top-level-component1 component depends on the following:

  • The test/test-component-override component in the same Atmos stack
  • The test/test-component component in Atmos stacks in the dev stage
  • The my-component component from the tenant1-ue2-staging Atmos stack
# If the `context` (namespace, tenant, environment, stage) is not provided,
# the `component` is from the same Atmos stack as this component
component: "test/test-component-override"
# This component (in any stage) depends on `test/test-component`
# from the `dev` stage (in any `environment` and any `tenant`)
component: "test/test-component"
stage: "dev"
# This component depends on `my-component`
# from the `tenant1-ue2-staging` Atmos stack
component: "my-component"
tenant: "tenant1"
environment: "ue2"
stage: "staging"
enabled: true


Refer to atmos describe dependents CLI command for more information.