Skip to main content

Configure Dependencies

The dependencies section has four sibling keys: tools (required CLI versions), components (other Atmos components this one depends on), files (file paths whose changes affect this component), and folders (folder paths whose changes affect this component). Tool dependencies pin CLI versions like Terraform, kubectl, or helm; components defines execution ordering between Atmos components, and files/folders declare watch-paths used by atmos describe affected and CI/CD integrations.

Use Cases​

  • Tool Version Requirements: Ensure components use specific Terraform, kubectl, or helm versions
  • Team Consistency: Version-control tool requirements for reproducible deployments
  • CI/CD Reliability: Guarantee correct tool versions in automated pipelines
  • Execution Order: Deploy dependent components in the correct sequence
  • Impact Analysis: Let atmos describe affected find components impacted by changes to other components, files, or folders

Tool Dependencies​

The dependencies.tools section declares which CLI tool versions a component requires. Atmos automatically installs and uses the specified versions when executing the component.

Configuration Scopes​

Tool dependencies can be defined at multiple levels, with more specific levels taking precedence.

Global Level​

Tool versions defined at the root level apply to all components:

stacks/orgs/acme/_defaults.yaml
# Global tool dependencies
dependencies:
  tools:
    terraform: "1.9.8"      # All Terraform components use this version
    kubectl: "1.28.0"        # All kubectl commands use this version

Component-Type Level​

Tool versions defined under terraform, helmfile, packer, or ansible apply to all components of that type:

stacks/orgs/acme/plat/prod/_defaults.yaml
terraform:
  dependencies:
    tools:
      terraform: "1.9.8"     # All Terraform components use 1.9.8
      tflint: "0.44.1"       # All Terraform components use tflint 0.44.1

helmfile:
  dependencies:
    tools:
      helm: "3.13.0"         # All Helmfile releases use helm 3.13.0
      kubectl: "1.28.0"      # All Helmfile releases use kubectl 1.28.0

ansible:
  dependencies:
    tools:
      ansible: "2.16.0"      # All Ansible components use ansible 2.16.0

Component Level​

Tool versions defined within a component override all higher-level settings:

stacks/orgs/acme/plat/prod/us-east-1.yaml
components:
  terraform:
    vpc:
      dependencies:
        tools:
          terraform: "1.8.5"   # This component uses older Terraform version
          aws-cli: "2.13.0"    # Component-specific AWS CLI version

Version Resolution​

Tool dependencies support multiple version formats:

Exact version

Use a specific version: "1.9.8"

Latest version

Use the latest available version: "latest"

Semver constraint (planned)

Use semantic version ranges: ">=1.8.0", "~>1.9.0"

Inheritance and Merge Behavior​

Tool dependencies are merged from the most general to the most specific level:

  1. Global dependencies.tools (applies to all components)
  2. Component-type terraform.dependencies.tools (applies to all components of that type)
  3. Component components.terraform.<name>.dependencies.tools (applies to specific component)

More specific levels override less specific levels. For example:

Example: Version Override
# Global default
dependencies:
  tools:
    terraform: "1.9.8"

# Component-type override
terraform:
  dependencies:
    tools:
      terraform: "1.9.8"
      tflint: "0.44.1"     # Added for all Terraform components

# Component-specific override
components:
  terraform:
    legacy-vpc:
      dependencies:
        tools:
          terraform: "1.5.0"  # This component uses older version
          tflint: "0.44.1"    # Inherited from component-type level

Result:

  • Most Terraform components use Terraform 1.9.8
  • legacy-vpc component uses Terraform 1.5.0
  • All Terraform components use tflint 0.44.1

Integration with Toolchain​

Tool dependencies integrate seamlessly with the toolchain management system:

  1. Automatic Installation: When you run a component, Atmos installs the required tool versions automatically
  2. Version Isolation: Each component uses its declared versions, isolated from other components
  3. Cache Efficiency: Tools are cached and reused across components with the same version requirements

Example workflow:

# Component declares terraform: "1.9.8"
atmos terraform plan vpc -s prod

# Atmos automatically:
# 1. Checks if terraform 1.9.8 is installed
# 2. Installs it if missing (from toolchain registries)
# 3. Executes: terraform plan (using 1.9.8)

Complete Tool Dependencies Example​

stacks/orgs/acme/plat/prod/us-east-1.yaml
# Global tool dependencies (all components)
dependencies:
  tools:
    terraform: "1.9.8"
    kubectl: "1.28.0"

# Component-type dependencies (all Terraform components)
terraform:
  dependencies:
    tools:
      terraform: "1.9.8"      # Override global if needed
      tflint: "0.44.1"        # Terraform-specific tool
      tfsec: "1.28.0"         # Security scanning
      aws-cli: "latest"       # Use latest AWS CLI

# Component-type dependencies (all Helmfile releases)
helmfile:
  dependencies:
    tools:
      helm: "3.13.0"
      kubectl: "1.28.0"
      helmfile: "0.157.0"

# Component-specific dependencies
components:
  terraform:
    vpc:
      dependencies:
        tools:
          terraform: "1.9.8"    # Use default
          aws-cli: "2.13.0"     # Component needs specific AWS CLI version

    legacy-app:
      dependencies:
        tools:
          terraform: "1.5.0"    # Legacy component requires older version
          aws-cli: "2.10.0"

  helmfile:
    monitoring:
      dependencies:
        tools:
          helm: "3.13.0"
          kubectl: "1.28.0"

Component Dependencies​

The dependencies.components section declares ordering relationships between Atmos components. Use it to express that one component must be applied before another. These dependencies are used by atmos describe dependents to find downstream consumers, by atmos describe affected to propagate impact through the dependency graph, and by CI/CD integrations (such as Spacelift) to apply components in the correct order.

For the full reference — cross-stack dependencies, cross-type (kind) dependencies, merge behavior, and migration from settings.depends_on — see the dedicated Component Dependencies page.

Quick Example​

stacks/catalog/vpc.yaml
components:
  terraform:
    vpc:
      vars:
        name: vpc

    subnet:
      dependencies:
        components:
          - component: vpc     # subnet depends on vpc
      vars:
        vpc_id: !terraform.output vpc.vpc_id

File and Folder Dependencies​

The dependencies.files and dependencies.folders sibling keys declare path-based dependencies. When atmos describe affected detects a change to one of these paths, the declaring component is marked as affected — even when no component code or stack configuration changed.

Use this to wire components to external assets like Lambda source code, configuration files, or schema definitions that live outside the component directory.

stacks/catalog/lambda.yaml
components:
  terraform:
    lambda-function:
      dependencies:
        files:
          - configs/lambda-settings.json
        folders:
          - src/lambda/my-function
Legacy inline shape

The kind: file / kind: folder entries inside dependencies.components[] (shipped in v1.210.0) still parse and behave identically. New configurations should prefer the dependencies.files and dependencies.folders sibling keys for clarity.

Best Practices​

  1. Pin Versions Explicitly - Use exact versions ("1.9.8") instead of "latest" for production
  2. Consistent Team Standards - Define global defaults in _defaults.yaml files
  3. Component-Specific Overrides - Only override when necessary (legacy code, compatibility)
  4. Document Reasons - Add comments explaining why a component uses a different version
  5. Test Before Upgrading - Test tool version changes in dev/staging before production