Atmos Vendoring

Atmos Component Vendoring

For scheduled native Component Updater pull requests, scopes/groups, GitHub permissions, and CI summaries, use references/component-updater.md.

Vendoring copies external components, stacks, and other artifacts into your repository. This gives you full control over when and how dependencies change, with visibility through git diff, an immutable audit trail, and the ability to apply emergency patches without waiting for upstream releases.

Atmos records completed installs in the committed vendor.lock.yaml receipt. The receipt contains credential-free declared and resolved sources, immutable artifact evidence, and the ordered per-file materialization inventory. It applies to both centralized vendor.yaml sources and legacy component.yaml sources and mixins.

Why Vendor

Vendoring is the checked-in model for remote component code: you copy the code into the repository, commit it, and control when updates happen. This provides:

• Visibility: See actual code changes via git diff, not just version bumps.
• Audit trail: Every update is a commit with full history for compliance.
• Emergency agility: Patch vulnerabilities immediately without waiting for upstream.
• Developer experience: Full IDE navigation, grep across all code, better onboarding.
• Deployment reliability: No network dependencies during terraform apply.

Atmos also supports component source provisioning for just-in-time fetching from stack configuration. Use the atmos-components skill for that model. Prefer vendoring when the fetched implementation should be reviewed and committed; prefer component source provisioning when the stack configuration should declare the remote source and Atmos should fetch it on demand.

Types of Vendoring

Atmos supports two approaches:

1. Vendor Configuration (vendor.yaml): A centralized manifest listing all dependencies. This is the recommended approach.
2. Component Manifest (component.yaml): A per-component manifest placed inside the component directory. This is the legacy approach.

vendor.yaml Manifest Format

The vendor.yaml file is a Kubernetes-style YAML configuration placed in the repository root (or the directory from which atmos vendor pull is executed):

apiVersion: atmos/v1
kind: AtmosVendorConfig
metadata:
  name: my-vendor-config
  description: Atmos vendoring manifest for ACME infrastructure
spec:
  imports:
    - "vendor/networking"
    - "vendor/security"

  sources:
    - component: "vpc"
      source: "github.com/cloudposse-terraform-components/aws-vpc.git?ref={{.Version}}"
      version: "1.398.0"
      targets:
        - "components/terraform/vpc"
      included_paths:
        - "**/*.tf"
        - "**/*.tfvars"
        - "**/*.md"
      excluded_paths:
        - "**/test/**"
      tags:
        - networking

    - component: "eks-cluster"
      source: "github.com/cloudposse-terraform-components/aws-eks-cluster.git?ref={{.Version}}"
      version: "2.15.0"
      targets:
        - "components/terraform/eks/cluster"
      tags:
        - compute

Top-Level Fields

• apiVersion: Always atmos/v1.
• kind: Always AtmosVendorConfig.
• metadata.name: Optional name for the vendor configuration.
• metadata.description: Optional description.
• spec.imports: List of additional vendor manifests to import (supports hierarchical imports and glob patterns).
• spec.sources: List of source definitions for components and artifacts to vendor.

Source Configuration

Each entry in spec.sources defines one component or artifact to vendor.

Source Fields

sources:
  - component: "vpc"
    source: "github.com/org/repo.git//path?ref={{.Version}}"
    version: "1.0.0"
    targets:
      - "components/terraform/vpc"
    included_paths:
      - "**/*.tf"
    excluded_paths:
      - "**/test/**"
    tags:
      - networking
    retry:
      max_attempts: 3
      initial_delay: 1s
      backoff_strategy: exponential

• component (string, optional): Component name used for atmos vendor pull -c <component> to vendor a single component. Also available as {{ .Component }} template variable.
• source (string, required): URL or path to the source. Supports Git, S3, HTTP/HTTPS, OCI, and local paths. Use {{ .Version }} template to inject the version.
• version (string, optional): Version identifier substituted into {{ .Version }} in source and targets.
• targets (list of strings, required): Local paths where files will be placed. Supports Go templates ({{ .Component }}, {{ .Version }}). Relative paths are resolved from the vendor.yaml location or base_path.
• included_paths (list of strings, optional): POSIX-style glob patterns for files to include. If not specified, all files are included.
• excluded_paths (list of strings, optional): POSIX-style glob patterns for files to exclude.
• tags (list of strings, optional): Tags for selective vendoring with atmos vendor pull --tags <tag>.
• retry (object, optional): Retry configuration for transient network errors.

Template Parameters

The source and targets fields support Go templates with these variables:

• {{ .Component }}: Value of the component field.
• {{ .Version }}: Value of the version field.

Example with versioned targets:

sources:
  - component: "vpc"
    source: "github.com/cloudposse-terraform-components/aws-vpc.git?ref={{.Version}}"
    version: "1.398.0"
    targets:
      - "components/terraform/{{ .Component }}/{{ .Version }}"

All Sprig template functions are available. For example, extracting major.minor version:

targets:
  - "components/terraform/{{ .Component }}/{{ (first 2 (splitList \".\" .Version)) | join \".\" }}"

Source Types

source: accepts Git (GitHub/GitLab/Bitbucket/SSH), OCI registries, Amazon S3, Google Cloud Storage, HTTP/HTTPS, and local paths -- see references/source-types.md for the full URL syntax and examples of each.

Authentication

Automatic Token Injection

Atmos automatically injects tokens for private Git repositories:

Enable GitLab/Bitbucket in atmos.yaml:

settings:
  inject_gitlab_token: true
  inject_bitbucket_token: true

SSH Authentication

source: "git@github.com:owner/private-repo.git?ref=v1.0.0"
source: "git@github.com:owner/private-repo.git?ref=v1.0.0&sshkey=~/.ssh/custom_key"

Include/Exclude Patterns

Use POSIX-style glob patterns to control which files are vendored:

included_paths:
  - "**/*.tf"          # All Terraform files recursively
  - "**/*.tfvars"      # All tfvars files
  - "**/*.md"          # All markdown files

excluded_paths:
  - "**/test/**"       # Exclude test directories
  - "**/*.yaml"        # Exclude YAML files
  - "**/examples/**"   # Exclude examples

Glob pattern syntax:

• * matches any characters within a single path segment.
• ** matches across multiple path segments recursively.
• ? matches exactly one character.
• [abc] matches any single character in the set.
• {a,b,c} matches any of the comma-separated patterns.

If included_paths is not specified, all files are included (minus any excluded_paths).

Imports in Vendor Manifests

Split the vendor.yaml into smaller files for maintainability:

# vendor.yaml
apiVersion: atmos/v1
kind: AtmosVendorConfig
spec:
  imports:
    - "vendor/networking"
    - "vendor/compute"
    - "vendor/security"
    - "vendor/**/*"           # Glob pattern: import all manifests recursively

Each imported file is a full AtmosVendorConfig manifest. Hierarchical imports are supported -- one manifest can import another, which imports another, etc. Import paths support glob patterns (*, **, ?, {a,b}).

Component Manifest (Legacy)

The legacy approach uses a component.yaml file inside the component directory:

# components/terraform/vpc/component.yaml
apiVersion: atmos/v1
kind: ComponentVendorConfig
metadata:
  name: vpc-vendor-config
  description: Vendoring config for VPC component
spec:
  source:
    uri: github.com/cloudposse-terraform-components/aws-vpc.git?ref={{.Version}}
    version: 1.398.0
    included_paths:
      - "**/*.tf"
      - "**/*.md"
    excluded_paths:
      - "**/context.tf"
  mixins:
    - uri: https://raw.githubusercontent.com/cloudposse/terraform-null-label/0.25.0/exports/context.tf
      filename: context.tf

Mixins (Legacy)

Mixins download additional files and overlay them on the vendored component. They are processed after the main source is downloaded, and they can overwrite source files with the same filename:

spec:
  mixins:
    - uri: https://raw.githubusercontent.com/cloudposse/terraform-null-label/0.25.0/exports/context.tf
      filename: context.tf
    - uri: https://example.com/terraform/custom-providers.tf
      version: 1.0.0
      filename: custom-providers.tf

Mixin fields:

• uri: URL to download (supports all go-getter protocols).
• filename: Local filename in the component directory.
• version: Optional version for {{ .Version }} substitution in the URI.

atmos vendor pull Command

# Vendor all sources from vendor.yaml
atmos vendor pull

# Vendor all sources (explicit flag)
atmos vendor pull --everything

# Vendor a specific component
atmos vendor pull -c vpc
atmos vendor pull --component eks-cluster

# Vendor by tags (vendor.yaml-declared source tags, matches ANY)
atmos vendor pull --tags networking
atmos vendor pull --tags networking,compute

# Vendor every component in a stack that has its own component.yaml
atmos vendor pull --stack plat-ue2-dev

# Vendor components whose stack metadata.labels match ALL pairs (matches --stack's resolution)
atmos vendor pull --labels tier=1,cost-center:platform

# Narrow a --stack/--labels selection by declared tags too
atmos vendor pull --stack plat-ue2-dev --tags networking

# Intentionally resolve mutable declared refs and replace their lock evidence
atmos vendor pull --refresh-lock

# Remove lock-owned files, preserving locally modified files by default
atmos vendor clean
atmos vendor clean --component vpc
atmos vendor clean --force

vendor pull reconciles the receipt as well as declared version pins: matching installed files skip a download; missing or checksum-mismatched files are rehydrated from the recorded immutable identity. --refresh-lock is the explicit mutable-ref refresh path. vendor clean only removes lock-owned paths, reports modified-file conflicts, and requires --force to remove them. Do not hand-delete a target directory or lock entry when a scoped clean/replay can preserve overlapping source and mixin ownership.