Skip to main content

Stack Mixins

Mixins are reusable snippets of configurations (like regions, tags, etc) included in stack configurations to avoid repetition and enhance modularity. They allow for defining common settings, variables, or configurations once and applying them efficiently across various stacks.

Mixins are really just a Design Pattern that uses imports to alter the Stack in some deliberate way.


Mixins are treated the same as all other imports in Atmos, with no special handling or technical distinction.


Here are some use-cases for when to use mixins.

Mixins by Region

Mixins organized by region will make it very easy to configure where a stack is deployed by simply changing the imported mixin.

Consider naming them after the canonical region name for the cloud provider you're using.

For example, here's what it would look like for AWS. Let's name this file mixins/region/us-east-1.yaml. Now, anytime we want a Parent Stack deployed in the us-east-1 region, we just need to specify this import, and we'll automatically inherit all the settings for that region.

For example, let's define a mixin with the defaults for operating in the us-east-1 region:

region: us-east-1 # the canonical cloud region
availability_zones: # the designated availability zones to use in this region
- us-east-1a
- us-east-1b

Then we can use this mixin, anytime we deploy in us-east-1 to ensure we conform to the organization's standards.

- mixins/region/us-east-1

# ...

Mixins by Stage

Provide the default settings for operating in a particular stage (e.g. Dev, Staging, Prod) to enforce consistency.

For example, let's define the stage name and required tags for production in the mixin file named mixins/stage/prod.yaml

stage: prod
CostCenter: 12345

Now, anytime we want to provision a parent stack in production, we'll want to add this to the imports:

- mixins/stage/prod

# ...

Use Mixins for Naming Conventions

This simple example highlights a simple fix for one of the most common issues in enterprise organizations: naming inconsistency. Using a mixin is a great way for organizations ensure naming conventions are followed consistently.

For example, there are many ways developers will define production.

  • e.g. prd
  • e.g. prod
  • e.g. production
  • e.g. Production
  • e.g. Prod
  • e.g. PROD
  • etc

To avoid this situation, use the mixin mixins/stage/prod and always use the appropriate naming convention.