Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
A direct command skips the review prompt. Inspect the source before running it.
Design patterns are proven solutions for structuring infrastructure configuration in Atmos. They address organizational complexity by providing reusable approaches for multi-account, multi-region, enterprise-grade environments.
Extends basic pattern to deploy across multiple AWS regions. Each region gets its own stack file with region-specific settings (CIDR blocks, availability zones).
Use name_template: "{{.vars.environment}}-{{.vars.stage}}" in atmos.yaml to generate stack names like ue2-dev.
Organizational Hierarchy Configuration
Enterprise pattern for multiple organizations, OUs/tenants, and accounts. Uses _defaults.yaml files at each hierarchy level to create inheritance chains.
Groups components by infrastructure function (network, data, compute). Each layer imports its relevant catalog defaults. Different teams can own different layers. Environments import only the layers they need.
Pre-configured variants for specific use cases. Define abstract base components with metadata.type: abstract, then create archetypes that inherit from the base with use-case-specific settings.
Catalog Templates
Use Go templates in imports to dynamically generate component instances. Import the same template multiple times with different context values:
Use sparingly -- the templating engine is powerful but can reduce maintainability.
Inheritance Patterns
Component Inheritance
A component inherits configuration from a base using metadata.inherits:
components:terraform:vpc:metadata:component:vpcinherits:-vpc/defaults# Inherit all vars, then overridevars:max_subnet_count:2
Inheritance order: base component -> inherited components (in order) -> inline vars.
Abstract Components
Mark components as non-deployable blueprints with metadata.type: abstract. Prevents accidental atmos terraform apply on base configurations. Components inheriting from abstract bases are deployable by default.
# In catalogvpc/defaults:metadata:type:abstractvars:enabled:truenat_gateway_enabled:true
Multiple Component Instances
Deploy multiple instances of the same Terraform component in one environment by defining multiple Atmos components pointing to the same metadata.component:
Inherit from multiple abstract bases to compose configuration from independent concerns:
rds:metadata:component:rdsinherits:-base/defaults# Applied first-base/logging# Applied second-base/production# Applied last, highest precedence
Merge behavior: scalars -- later wins; maps -- deep merged; lists -- later replaces entirely.
Configuration Composition
Inline Configuration
Define components directly in stack manifests. Use for prototyping, single-environment deployments, or components unique to one stack.
Partial Component Configuration
Split a component's configuration across multiple files imported into the same stack. Useful for independently managing parts of complex configurations (e.g., EKS cluster defaults + Kubernetes version mixin).
Component Overrides
Apply configuration to a subset of components without affecting others using the overrides section. Overrides are file-scoped and do not get inherited.
# stacks/teams/platform.yamlimport:-catalog/vpc/defaults-catalog/eks/defaultsterraform:overrides:vars:tags:Team:Platform# Only applies to vpc and eks, not other teams' components
DRY Configuration with Locals
File-scoped variables that reduce repetition within a single stack file:
Locals are not inherited across imports. Use vars or settings for cross-file values.
Version Management Patterns
Continuous Version Deployment (Recommended)
Trunk-based strategy where all environments reference the same component path and converge through progressive automated rollout. Simplest approach with strongest feedback loops.
Folder-Based Versioning
Components organized in explicit folders (vpc/v1/, vpc/v2/). Environments reference specific version folders. Use metadata.name for stable workspace keys across version upgrades.
vpc:metadata:name:vpc# Stable identity (workspace key stays same)component:vpc/v2# Version can change freely
Release Tracks/Channels
Named channels (alpha/vpc, beta/vpc, prod/vpc) that environments subscribe to. Promote tracks instead of individual environment pins. Use label-based versioning schemes (maturity levels, environment names).
Strict Version Pinning
Explicit SemVer versions (vpc/1.2.3). Works with vendoring from external sources. Use number-based versioning schemes. Higher operational overhead but strongest audit trail.
Source-Based Version Pinning
Per-environment version control using the source field in stack configuration. Just-in-time vendoring without managing separate vendor manifests.
Automate copying components from external sources with vendor.yaml and atmos vendor pull. Provides local control, audit trail, and searchable codebase. Complements any deployment strategy.
Git Flow: Branches as Channels
Branch-based alternative where long-lived branches map to release channels. Promotions happen via merges. Best for teams already practicing Git Flow.
