# atmos > The runtime for infrastructure. This file contains links to documentation sections following the llmstxt.org standard. ## Table of Contents - [Validate Only What Changed](https://atmos.tools/changelog/affected-validation): Large repositories often have validation rules that are useful but expensive or noisy to run across every file on every pull request. That makes it tempting to skip validation exactly when a focused s - [Browse, Search, and Copy Any Atmos Agent Skill Before You Install It](https://atmos.tools/changelog/agent-skills-directory): Before you install a skill, you want to read what it does. Atmos agent skills did not let you do that. You had to install a skill first to read its full instructions. Or you had to find its file in th - [AI Agent Skills for Atmos](https://atmos.tools/changelog/ai-agent-skills): Atmos now ships 21 agent skills that give AI coding assistants deep knowledge of Atmos conventions, stack configuration, Terraform orchestration, authentication, validation, and more. Skills build on - [Use Claude Code, Codex CLI, or Gemini CLI as Atmos AI Providers](https://atmos.tools/changelog/ai-cli-providers): Atmos AI now supports **CLI providers** — invoke your locally installed Claude Code, OpenAI Codex, or Gemini CLI as AI backends. No API keys needed. Just use your existing subscription. - [AI-Powered Analysis for Atmos Commands with the Global --ai Flag](https://atmos.tools/changelog/ai-powered-analysis-with-global-ai-flag): Add `--ai` to any Atmos command and get instant AI-powered analysis of the output. Successful plans get summarized, errors get explained with step-by-step fixes — zero workflow changes required. - [Keep Installed AI Skills Up to Date](https://atmos.tools/changelog/ai-skill-update): Package managers normally tell you when an installed package is out of date and let you refresh just that one. Installed AI skills did not work that way: `atmos ai skill install` copies a bundled skil - [Ambient Credential Support for IRSA, IMDS, and ECS Task Roles](https://atmos.tools/changelog/ambient-credential-support): Atmos now supports ambient AWS credentials from IRSA, EC2 instance profiles, and ECS task roles via two new identity kinds: `ambient` (generic passthrough) and `aws/ambient` (AWS SDK default credentia - [Ansible Component Support](https://atmos.tools/changelog/ansible-component-support): Atmos now supports Ansible as a first-class component type, enabling unified orchestration of infrastructure provisioning (Terraform) and configuration management (Ansible) from the same stack manifes - [New !append YAML Function to Extend Inherited Lists](https://atmos.tools/changelog/append-yaml-function): Atmos now supports the `!append` YAML function, which **adds items to an inherited list** during stack merging instead of replacing it — giving you per-field control over list merging without changing - [Archive Step Type: Pack Zip/Tar Archives Without Shelling Out](https://atmos.tools/changelog/archive-step-type): Packaging a directory into a deployable archive — most commonly zipping a Lambda function's source into `handler.zip` before `terraform plan`/`apply` — has always meant reaching for a shell-based hook - [Artifactory Store Fix and Documentation Corrections](https://atmos.tools/changelog/artifactory-store-fix): Fixed an issue where retrieving values from Artifactory stores would fail when using nested paths, and corrected store documentation to accurately reflect supported backends. - [Ask AI: Conversational Search for Atmos Documentation](https://atmos.tools/changelog/ask-ai-search): Finding information in documentation shouldn't require knowing the exact terminology or page structure. With **Ask AI**, you can now ask natural language questions about Atmos and get intelligent, con - [Atmos Now Builds Atmos](https://atmos.tools/changelog/atmos-builds-atmos): Atmos now builds itself through a first-class Atmos command: - [See Atmos in Action](https://atmos.tools/changelog/atmos-demo-workflows): Start with the recording. - [Atmos Git: A Foundational Capability for GitOps Pipelines](https://atmos.tools/changelog/atmos-gitops): Atmos now treats Git as a foundational platform capability — on par with Toolchain, Auth, and Hooks — built to enable GitOps workflows where you need to commit artifacts to a source of truth: deployme - [Introducing the Atmos Media Kit](https://atmos.tools/changelog/atmos-media-kit): The official [Atmos Media Kit](/media-kit) is now available with downloadable logo assets, usage guidance, brand colors, and product language for teams writing about or building integrations with Atmo - [Just-in-time GitHub tokens for CI with Atmos Pro STS](https://atmos.tools/changelog/atmos-pro-github-sts): Fetching private Terraform modules, Atmos `source:` components, and vendored artifacts in CI has always meant handing a long-lived, over-privileged GitHub credential to your pipeline — a PAT, a machin - [Atmos Profiles: One Configuration, Multiple Contexts](https://atmos.tools/changelog/atmos-profiles): Stop fighting with different Atmos configurations for development, CI/CD, and production. Profiles let you switch contexts with a single flag while keeping your core configuration consistent. - [Compose YAML Functions in Templates with atmos.Resolve](https://atmos.tools/changelog/atmos-resolve-template-function): Atmos adds a new template function, `atmos.Resolve`, that evaluates any [Atmos YAML function](/functions/yaml) — like `!git.repository`, `!exec`, `!store`, or `!terraform.output` — at template-render - [Get the exact stack-manifest schema for the Atmos you have installed](https://atmos.tools/changelog/atmos-stack-schema-command): Editors, CI pipelines, and offline environments that want to validate stack manifests locally have had one option: fetch the JSON Schema from `atmos.tools` over the network and hope it matches whateve - [Introducing the Atmos Version Manager](https://atmos.tools/changelog/atmos-version-manager): Atmos now supports automatic version switching, making it easy to pin projects to specific Atmos versions and ensure consistency across teams. - [One Catalog for Every Version Pin: the Atmos Version Tracker](https://atmos.tools/changelog/atmos-version-tracker): Your infrastructure's versions live everywhere except one place. `actions/checkout@v4` in a dozen workflow files, `TOFU_VERSION=1.9.0` in a Dockerfile, `nginx:1.27` in a stack, `kubectl` wherever your - [atmos.yaml Gets a JSON Schema That Can't Go Stale](https://atmos.tools/changelog/atmos-yaml-schema): Editing `atmos.yaml` has always been a matter of trust. Misspell a key, indent a section one level too deep, or put a string where a map belongs, and nothing tells you — unknown keys are silently igno - [Auth and Utility Commands No Longer Require Stack Configurations](https://atmos.tools/changelog/auth-and-utility-commands-no-longer-require-stacks): Atmos auth, documentation, and workflow management commands now work independently of stack configurations, making it easier to use Atmos in CI/CD pipelines and alongside "native" Terraform workflows. - [Isolated Browser Sessions for Multi-Account Console Access](https://atmos.tools/changelog/auth-console-isolated-sessions): The `atmos auth console` command now supports isolated browser sessions, allowing you to have multiple cloud provider consoles open simultaneously — one per identity — without logout conflicts. - [Cloud Console Access with atmos auth console](https://atmos.tools/changelog/auth-console-web-access): Atmos now includes `atmos auth console`, a convenience command for opening cloud provider web consoles. Similar to `aws-vault login`, this command uses your authenticated Atmos identities to generate - [Auth Context: Centralizing Authentication State in Atmos](https://atmos.tools/changelog/auth-context-implementation): We've implemented a centralized authentication context system to enable **concurrent multi-provider identities** - allowing Atmos to manage AWS, GitHub, and other cloud provider credentials simultaneo - [Improved AWS IAM User Authentication: Automatic Recovery and Better Guidance](https://atmos.tools/changelog/auth-credential-invalidation-recovery): Atmos now automatically detects when your AWS IAM User credentials have been rotated or revoked and prompts you for new credentials inline. No more persistent authentication failures after credential - [GitHub Actions Format for Auth Credentials](https://atmos.tools/changelog/auth-env-github-format): The `atmos auth env` command now supports `--format=github` for direct output to `$GITHUB_ENV`, eliminating shell pipelines in CI workflows. - [AWS Region Now Exported by atmos auth env](https://atmos.tools/changelog/auth-env-region-export): The `atmos auth env` command now exports `AWS_REGION` and `AWS_DEFAULT_REGION` when region is configured in your identity settings. - [Seamless First Login with Provider Fallback](https://atmos.tools/changelog/auth-login-provider-fallback): `atmos auth login` now automatically falls back to provider authentication when no identities are configured, enabling seamless first-time login with `auto_provision_identities`. - [Auth Realm Isolation for Multi-Repository Workflows](https://atmos.tools/changelog/auth-realm-isolation): Atmos now supports credential realm isolation, preventing collisions when engineers work with multiple customer repositories using identical identity names. - [Required Identities for Multi-Account Components](https://atmos.tools/changelog/auth-required-concurrent-identities): Atmos identities now support `required: true`, enabling automatic authentication of multiple identities before Terraform runs — without prompting. - [New Guides for Atmos Auth: Leapp Migration and Geodesic Integration](https://atmos.tools/changelog/auth-tutorials-geodesic-leapp): We've published two comprehensive guides to help you adopt and integrate `atmos auth` into your workflows: migrating from Leapp and configuring Geodesic for seamless authentication. - [Authentication Experience Improvements](https://atmos.tools/changelog/auth-ux-improvements): We've made several quality-of-life improvements to Atmos authentication commands, making identity management smoother and more intuitive. - [Authentication Support for Workflows and Custom Commands](https://atmos.tools/changelog/authentication-for-workflows-and-custom-commands): We're excited to announce two major improvements to Atmos authentication: **per-step authentication for workflows** and **authentication support for custom commands**. These features enable you to sea - [Solving the Terraform Bootstrap Problem with Automatic Backend Provisioning](https://atmos.tools/changelog/automatic-backend-provisioning): We're excited to introduce **automatic backend provisioning** in Atmos, a feature that solves the Terraform bootstrap problem. No more manual S3 bucket creation, no more chicken-and-egg workarounds—At - [Backends Auto-Provisioned on Terraform Init](https://atmos.tools/changelog/automatic-backend-provisioning-on-init): Atmos now automatically provisions backends during `terraform init`, eliminating the need for a separate `backend create` command. When `provision.backend.enabled: true` is set, backends are created j - [AWS Assume Root Identity for Centralized Root Access](https://atmos.tools/changelog/aws-assume-root-identity): Atmos now supports the `aws/assume-root` identity kind, enabling secure, centralized management of root access across your AWS Organization using the STS AssumeRoot API. - [New !aws.organization_id YAML Function](https://atmos.tools/changelog/aws-organization-id-yaml-function): Access the AWS Organization ID directly in stack configuration with the new `!aws.organization_id` YAML function. - [Analyze AWS Security Findings and Map Them to Your Infrastructure](https://atmos.tools/changelog/aws-security-compliance): Atmos can now pull security findings from AWS Security Hub, map them to the exact Atmos components and stacks that manage the affected resources, and generate structured remediation reports — all from - [AWS Security Findings Now Export to SARIF and OCSF](https://atmos.tools/changelog/aws-security-sarif): The `atmos aws security analyze` command is the native Atmos command for turning AWS security findings into infrastructure-aware remediation guidance. It reads findings from AWS Security Hub and Amazo - [Zero-Configuration AWS SSO Identity Management](https://atmos.tools/changelog/aws-sso-identity-auto-provisioning): Atmos now automatically provisions AWS SSO permission sets as identities when you authenticate. Log in once, and all your available roles are instantly ready to use—no manual configuration required. - [One Browser Flow Unlocks Every AWS SSO Provider](https://atmos.tools/changelog/aws-sso-session-sharing): `atmos auth login` now performs **one** browser interaction per AWS SSO portal, no matter how many `aws/iam-identity-center` providers in your `atmos.yaml` point at it. Cached tokens also refresh sile - [Enhanced AWS SSO Authentication: Better UX with Styled Dialogs and Graceful Cancellation](https://atmos.tools/changelog/aws-sso-verification-code-display): We've significantly improved the AWS SSO authentication experience with styled verification code dialogs, animated status indicators, and proper Ctrl+C handling. - [AWS YAML Functions for Identity and Region](https://atmos.tools/changelog/aws-yaml-functions): Atmos now includes four AWS YAML functions that retrieve identity and region information directly in stack configurations: `!aws.account_id`, `!aws.caller_identity_arn`, `!aws.caller_identity_user_id` - [Azure AKS and ACR Authentication: Native kubectl and Docker Access Without the Azure CLI](https://atmos.tools/changelog/azure-aks-acr-authentication): Getting `kubectl` and `docker` working against Azure resources has always meant a side trip through the Azure CLI. `az aks get-credentials` writes a kubeconfig entry — and for AAD-enabled clusters, th - [Native Azure Authentication Support](https://atmos.tools/changelog/azure-authentication-support): We're thrilled to announce native Azure authentication support in Atmos! You can now authenticate to Azure using `atmos auth login` with device code flow, OIDC, and service principals - working identi - [Automatic Azure Backend Provisioning for Terraform State](https://atmos.tools/changelog/azure-backend-provisioning): Bootstrapping Terraform state on Azure has always meant a detour outside Terraform: before you can run a single `plan`, you have to hand-create a resource group, a storage account (with the right TLS, - [Azure Blob Storage Support for !terraform.state Function](https://atmos.tools/changelog/azure-blob-terraform-state-support): Atmos now supports Azure Blob Storage backends in the `!terraform.state` YAML function. Read Terraform outputs directly from Azure-backed state files without initializing Terraform—bringing the same b - [Azure Interactive Browser Authentication](https://atmos.tools/changelog/azure-interactive-auth): Atmos now supports the `azure/interactive` provider — the same interactive browser login `az login` uses (authorization code + PKCE on a localhost redirect). One command, `atmos auth login`, opens you - [Azure OIDC/Workload Identity Federation Provider](https://atmos.tools/changelog/azure-oidc-provider): Atmos now supports Azure OIDC/Workload Identity Federation for secure, secretless authentication in CI/CD pipelines. - [Background Container Services in Atmos Workflows](https://atmos.tools/changelog/background-container-services): Atmos workflows can now start long-running container services in the background, wait for them to become healthy, and tear them down automatically. Bring up an emulator, database, or registry with `ba - [Breaking Change: Empty base_path No Longer Defaults to Current Directory](https://atmos.tools/changelog/base-path-behavior-change): Starting with Atmos v1.202.0, empty or omitted `base_path` values in `atmos.yaml` now trigger git root discovery instead of defaulting to the current directory. Users with multiple Atmos projects in a - [Browser-Based Authentication for AWS IAM Users](https://atmos.tools/changelog/browser-based-auth-aws-user): Atmos now supports browser-based OAuth2 authentication as an automatic fallback for `aws/user` identities. When no static credentials or keychain entries are available, Atmos opens your browser for in - [Record and Render Terminal Sessions with Atmos Cast](https://atmos.tools/changelog/cast-record-render): Atmos can now record terminal sessions as asciicast files and render them into shareable formats for documentation, demos, and CI artifacts. - [Config Isolation with --chdir Flag](https://atmos.tools/changelog/chdir-config-isolation): The `--chdir` flag now correctly isolates configuration loading when changing to a directory with its own Atmos configuration. - [Chunked Uploads for Large Stack Payloads](https://atmos.tools/changelog/chunked-stack-uploads): Atmos now automatically chunks large payloads when uploading affected stacks and instances to Atmos Pro, eliminating HTTP 413 errors for large infrastructure repositories. - [Faster CI: Atmos Caches Your Toolchain, Providers, and Modules](https://atmos.tools/changelog/ci-build-cache): Atmos now plugs into your CI provider's native cache so your infrastructure pipelines run faster — automatically. Flip one setting and Atmos caches the toolchain it installs, the OpenTofu and Terrafor - [Toggle CI PR Comments with an Environment Variable](https://atmos.tools/changelog/ci-comments-env-var): You can now enable or disable CI PR comments per-pipeline using the `ATMOS_CI_COMMENTS_ENABLED` environment variable — no config file changes needed. - [Use Multiple GitHub Tokens in CI Workflows](https://atmos.tools/changelog/ci-github-token-override): When you're using a GitHub App token to manage GitHub resources with Terraform, you probably still want CI commit statuses to use the workflow's own token. Now you can — just set `ATMOS_CI_GITHUB_TOKE - [Collapsible CI Log Groups for Workflows and Custom Commands](https://atmos.tools/changelog/ci-log-groups): A workflow fails in CI. You open the run and you're staring at two thousand lines of undifferentiated output — `terraform init`, `plan`, and `apply` from every step mashed into one endless scroll, wit - [Validate GitHub Actions Workflows with Atmos](https://atmos.tools/changelog/ci-workflow-validation): A workflow can be valid YAML and still fail only after GitHub Actions tries to run it: a misspelled trigger filter, an invalid expression, or an action reference that does not make sense in context. T - [Component-Aware Stack Tab Completion](https://atmos.tools/changelog/component-aware-stack-completion): Tab completion for the `--stack` flag is now context-aware, filtering suggestions based on the component you specify. - [Document Components with metadata.description](https://atmos.tools/changelog/component-metadata-description): Component `metadata` now supports an optional `description` field, so you can document what a component is for right next to its configuration. Atmos preserves `description` as component metadata — it - [Smarter Component Selection in Interactive Prompts](https://atmos.tools/changelog/component-selection-filtering): Interactive component selection now filters out non-deployable components. - [Native Pull Requests for Vendored Component Updates](https://atmos.tools/changelog/component-updater-pull-requests): Keeping vendored components current across dozens of repositories doesn't scale as a manual habit. Someone has to notice a new upstream release, edit the right `version:` field without breaking a comm - [Component Workdir Isolation: The Foundation for Concurrent Terraform Operations](https://atmos.tools/changelog/component-workdir-isolation): If you've ever had two component instances pointing to the same base component, you've likely encountered the frustration: file conflicts, unexpected overwrites, and mysterious errors when running Ter - [Comprehensive Terraform Documentation and Enhanced Help System](https://atmos.tools/changelog/comprehensive-terraform-documentation): This release brings documentation improvements to Atmos, making it easier to understand and use Terraform commands. We've focused on comprehensive command documentation and automated screengrab genera - [New Comprehensive Version Management Documentation](https://atmos.tools/changelog/comprehensive-version-management-documentation): When you deploy infrastructure across multiple environments—dev, staging, production—you need a way to manage which version of each component runs where. Maybe your VPC module in dev is testing new CI - [Config Editions: Pin Your Defaults to a Date So Upgrades Never Surprise You](https://atmos.tools/changelog/config-editions): You upgrade a CLI tool and something changes that you never asked for. Output that used to page now scrolls past. An integration that used to run automatically now doesn't. Nothing in your configurati - [Smarter Type Handling for `atmos config set` and `atmos stack set`](https://atmos.tools/changelog/config-stack-type-inference): Editing a config value from the command line is supposed to be the easy path. Type `atmos stack set vars.replicas 5`, expect a `5`, move on. Except a value like that used to come back out the other si - [Remote Build Caching for Container Builds](https://atmos.tools/changelog/container-buildx-cache-and-driver): Container image builds get slower as a Dockerfile grows, and CI runners rarely keep a warm local cache between runs. Teams work around this with a handful of `docker/setup-buildx-action` and `docker/b - [Container Components and Compositions](https://atmos.tools/changelog/container-components): Atmos now has a first-class **container component kind**. Where a `type: container` workflow step is a procedural `docker run --rm`, a `components.container` entry is declarative, stack-scoped infrast - [A Typo in a Container Step's `with:` Block Used to Just... Do Nothing](https://atmos.tools/changelog/container-config-validation-and-workdir-path-encoding): You add `platforms: [linux/amd64]` to a container build step, run it, and nothing happens differently. No error, no warning — the field is just gone, like it was never written. You spend ten minutes c - [Copy any docs page as Markdown — atmos.tools now serves a raw .md alternate for every page](https://atmos.tools/changelog/copy-markdown-button): Every page on atmos.tools is now available as raw Markdown. Append `.md` to any docs URL and you'll get a clean, MDX-component-aware Markdown file ready to paste into an LLM, a ticket, or another doc. - [Boolean Flags with Default Values for Custom Commands](https://atmos.tools/changelog/custom-command-boolean-flags): Custom commands now support boolean flags with configurable default values. You can define `type: bool` flags that default to `true` or `false`, making it easier to handle special behavior triggers. - [Introducing 25+ Interactive Step Types for Workflows and Custom Commands](https://atmos.tools/changelog/custom-commands-step-types): Atmos now includes 25+ interactive step types for both workflows and custom commands. Build interactive CLI wizards, collect user input, display rich output, and control execution flow—all directly in - [Introducing Custom Component Types for Custom Commands](https://atmos.tools/changelog/custom-component-types): Atmos custom commands can now define their own component types beyond `terraform`, `helmfile`, and `packer`. Use Atmos's stack configuration system with any tool: Ansible, Kubernetes manifests, shell - [Custom hooks: zero-config security & cost scanners](https://atmos.tools/changelog/custom-hooks): Atmos hooks now have a **`kind`** system — the same `before.terraform.plan` / `after.terraform.plan` lifecycle you already know, but the dispatch is pluggable and built-in kinds ship for common tools. - [Custom Secrets Masking Patterns](https://atmos.tools/changelog/custom-secrets-masking): Provably safe secrets masking with custom patterns, comprehensive output coverage, and configurable replacement strings. - [Customize List Command Output to Explore Your Cloud Architecture](https://atmos.tools/changelog/customizable-list-command-output): Configure custom columns in atmos.yaml to tailor list command output to your team's needs - [Declarative File Generation for Terraform Components](https://atmos.tools/changelog/declarative-file-generation): Atmos now supports declarative file generation for Terraform components via the new `generate` section in stack configuration. - [Deferred YAML Function Evaluation in Merge](https://atmos.tools/changelog/deferred-yaml-functions-evaluation-in-merge): We've improved how Atmos handles YAML functions during merges across configuration layers. Atmos now postpones merging YAML functions until after the regular merge is done. This avoids the type confli - [Introducing Structured Component Dependencies](https://atmos.tools/changelog/dependencies-components): Atmos now supports a new `dependencies.components` format for declaring explicit component dependencies with support for cross-type dependencies, file/folder watching, and stack templates. - [File and Folder Dependencies](https://atmos.tools/changelog/dependencies-files-folders): Atmos now supports `dependencies.files` and `dependencies.folders` as first-class sibling keys for declaring path-based dependencies. Use them to mark a component as affected when shared files, genera - [atmos describe affected now detects providers, generate, backend changes, and more](https://atmos.tools/changelog/describe-affected-all-sections): The `atmos describe affected` command now compares **every** provisioned component section between refs — including `providers`, `required_providers` (provider versions), `generate`, `backend`, `auth` - [Zero-Config CI with Describe Affected Auto-Detection](https://atmos.tools/changelog/describe-affected-auto-detection): The `atmos describe affected` command now auto-detects the base commit in CI environments, eliminating the need for verbose flag wiring in your workflows. - [Fixed: Describe Affected Now Detects Component File Changes](https://atmos.tools/changelog/describe-affected-component-detection): Atmos now correctly detects component file changes when running `atmos describe affected`. A regression introduced in v1.195.0 caused changes to Terraform, Helmfile, or Packer component files to not b - [Describe Affected Now Detects Deleted Components and Stacks](https://atmos.tools/changelog/describe-affected-deleted-detection): Atmos now automatically detects components and stacks that have been deleted in your current branch compared to the target branch. This enables CI/CD pipelines to trigger `terraform destroy` workflows - [describe affected --format=matrix auto-routes to GITHUB_OUTPUT](https://atmos.tools/changelog/describe-affected-matrix-auto-output): `atmos describe affected --format=matrix` now writes to `$GITHUB_OUTPUT` automatically when CI is enabled, matching the behavior already shipped for `atmos list instances --format=matrix`. No more `-- - [Fixed: Describe Affected Now Detects Vendored Component Changes](https://atmos.tools/changelog/describe-affected-source-vendoring): Atmos now correctly detects file changes in components that use the `source` attribute for [just-in-time vendoring](https://atmos.tools/cli/commands/terraform/source/). Previously, components vendored - [Identity Flag Support for Describe Commands](https://atmos.tools/changelog/describe-commands-identity-flag): The `atmos describe` family of commands now supports the `--identity` flag, enabling runtime authentication when processing YAML template functions that access remote resources. This ensures that `!te - [Structured Diagnostics for Agentic Troubleshooting](https://atmos.tools/changelog/diagnostics-jsonl): Human logs are useful while you are watching a command run, but they are not enough when you need to diagnose subprocess execution, CI failures, or agent runs after the fact. - [Disable Identity Authentication with --identity=false](https://atmos.tools/changelog/disable-identity-authentication): You can now disable Atmos identity authentication by setting `--identity=false`, allowing you to use cloud provider SDK credential resolution instead. - [Documentation Reorganization: Learn, Reference, How-To](https://atmos.tools/changelog/documentation-reorganization): We've reorganized the Atmos documentation to better serve both newcomers and experienced users. Here's what changed and why. - [Dotenv Files with !include](https://atmos.tools/changelog/dotenv-include-support): Atmos now supports using dotenv files directly with the `!include` YAML function. - [ECR Authentication Integration: Automatic Docker Login for AWS Container Registries](https://atmos.tools/changelog/ecr-authentication-integration): We're introducing ECR authentication integration - automatic Docker login for AWS Elastic Container Registry as part of your Atmos authentication workflow. Configure once, authenticate everywhere. - [ECR Public Registry Authentication](https://atmos.tools/changelog/ecr-public-authentication): Atmos now supports authenticated pulls from `public.ecr.aws` via the new `aws/ecr-public` integration kind, eliminating Docker rate limits on public ECR images. - [EKS Kubeconfig Authentication: Native kubectl Access Without the AWS CLI](https://atmos.tools/changelog/eks-kubeconfig-authentication): Atmos now supports native EKS kubeconfig authentication through the integrations system. When you authenticate with an identity, Atmos automatically generates kubeconfig entries for linked EKS cluster - [Fixed: Invalid Backend Files from Empty Configuration](https://atmos.tools/changelog/empty-backend-config-validation): Atmos now validates that remote backend configurations are not empty before generating backend files. This prevents invalid Terraform configurations that would fail during `terraform init`. - [Enhanced Color Output Support and Code Quality Improvements](https://atmos.tools/changelog/enhanced-color-output-and-code-quality): This release brings powerful enhancements to color output in CI/CD environments and significant code quality improvements that make Atmos more maintainable and performant. - [!env Function Now Reads from Stack Manifest env Sections](https://atmos.tools/changelog/env-function-stack-manifest-support): The `!env` YAML function now supports reading environment variables from `env` sections defined in your stack manifests and Atmos configuration. This makes it easy to set defaults for environment vari - [Experimental Feature Controls](https://atmos.tools/changelog/experimental-feature-flag): Atmos now provides granular control over experimental features with the new `settings.experimental` configuration option—giving teams the flexibility to explore new capabilities safely while maintaini - [3.5× Faster Deep Merge for Stack Processing](https://atmos.tools/changelog/faster-deep-merge): Atmos stack processing is now up to **3.5× faster** for deep-merge operations — the hot path executed thousands of times per `atmos describe component`, `atmos terraform plan`, and every other command - [Faster Remote Stack Imports: Clone Once, Cache Across Runs](https://atmos.tools/changelog/faster-remote-stack-imports): Atmos now clones each remote (Git) stack-import source **once per run** instead of re-cloning it for every import that points at the same repository — and an optional `ttl` lets a warm cache (like the - [File-Scoped Locals: Simplify Stack Configuration with Temporary Variables](https://atmos.tools/changelog/file-scoped-locals): We're introducing **file-scoped locals** to Atmos stack configurations. Inspired by Terraform and Terragrunt, locals let you define temporary variables within a single file, reducing repetition and ma - [Fixed: File-Scoped Locals Now Resolve Templates Correctly](https://atmos.tools/changelog/file-scoped-locals-fix): The file-scoped locals feature introduced in v1.203.0 now correctly resolves `{{ .locals.* }}` templates in stack configurations. Previously, locals were defined but not integrated into the template p - [Flag-Aware Custom Commands and Dynamic Tables](https://atmos.tools/changelog/flag-aware-custom-commands): Custom command steps can now read their own command-line flags through `{{ .Flags. }}`, and the [`table`](/workflows/steps/type/table) step templates its `data`, `columns`, and `title` per-step. - [Flexible Keyring Backends: System, File, and Memory Storage for Credentials](https://atmos.tools/changelog/flexible-keyring-backends): Atmos Auth supports flexible keyring backends, giving you control over how authentication credentials are stored. Use your **system keyring** for native OS integration, **file-based keyrings** to shar - [New pkg/function Package for Format-Agnostic Function Registry](https://atmos.tools/changelog/function-registry-package): Introduces `pkg/function/`, a new format-agnostic function registry that consolidates YAML function handlers into a reusable package. - [GCP Authentication Support](https://atmos.tools/changelog/gcp-authentication-support): Atmos now supports first-class Google Cloud authentication alongside AWS and Azure, with provider-scoped file isolation and a unified auth experience. - [Geodesic: A Production-Ready DevOps Toolbox for Development Containers](https://atmos.tools/changelog/geodesic-production-ready-devcontainer): While Atmos supports any devcontainer configuration, **Geodesic is a proven DevOps toolbox** that's been battle-tested for almost 10 years. If you're looking for a production-ready development contain - [Atmos auto-detects GitHub Actions debug logging](https://atmos.tools/changelog/gha-debug-auto-promote): GitHub Actions has a built-in ["Re-run with debug logging"](https://github.blog/changelog/2022-05-24-github-actions-re-run-jobs-with-debug-logging/) button: when a workflow fails, you click it and the - [Gist: Build, Scan, Approve & Share AWS AMIs with Atmos + Packer](https://atmos.tools/changelog/gist-aws-ami-packer-github-actions): A common question from the community is: *how do I use Atmos with Packer to build AMIs, and automate the whole build → approve → share process?* We've published a new [**gist**](/gists/aws-ami-packer- - [atmos git clone Refuses Unsafe Fork Checkouts by Default](https://atmos.tools/changelog/git-clone-fork-pr-safety-gate): `atmos git clone` is Atmos's native replacement for `actions/checkout`. Mirroring the [`actions/checkout` v7 hardening](https://github.blog/changelog/2026-06-18-safer-pull_request_target-defaults-for- - [Git Repository Metadata YAML Functions](https://atmos.tools/changelog/git-repository-yaml-functions): Atmos now exposes Git **repository metadata** through dedicated YAML functions: `!git.repository`, `!git.owner`, `!git.name`, `!git.host`, and `!git.url`. These join the existing `!git.root`, `!git.sh - [Run Atmos from Any Subdirectory](https://atmos.tools/changelog/git-root-discovery): Atmos now automatically discovers your repository root and runs from there, just like Git. No more `cd`-ing back to the root directory. - [Git YAML Functions for Source Pinning](https://atmos.tools/changelog/git-yaml-functions): Atmos now includes core Git YAML functions for resolving repository metadata directly in stack and config processing: `!git.root`, `!git.sha`, `!git.branch`, and `!git.ref`. - [Native GitHub Actions Support for Atmos Toolchain](https://atmos.tools/changelog/github-actions-toolchain-path): Atmos toolchain now has native GitHub Actions support with the new `github` format for `atmos toolchain env`. - [GitHub Actions Output Format](https://atmos.tools/changelog/github-output-format): Atmos now supports a dedicated `github` output format for `atmos terraform output`, making it easier than ever to pass Terraform outputs between GitHub Actions steps. - [GKE Kubeconfig Authentication: Native kubectl and Helm Access Without gcloud](https://atmos.tools/changelog/gke-kubeconfig-authentication): Using an Atmos-managed GCP identity with GKE used to stop one step short of the cluster. The identity could authenticate Terraform and other GCP clients, but operators still needed `gcloud` or `gke-gc - [Global Environment Variables in atmos.yaml](https://atmos.tools/changelog/global-env-section): Atmos now supports a global `env` section in `atmos.yaml` that applies environment variables to all subprocesses spawned by Atmos, including Terraform, Helmfile, Packer, workflows, and custom commands - [Global `ignore_missing_template_values` for Stack Imports](https://atmos.tools/changelog/global-ignore-missing-template-values): Atmos now supports a global `templates.settings.ignore_missing_template_values` option in `atmos.yaml`, eliminating the need to set `ignore_missing_template_values: true` on every individual catalog i - [Stack-Wide Metadata Defaults: Set Labels and Tags Once](https://atmos.tools/changelog/global-metadata-defaults): Most components in a stack share the same cost center label or the same compliance-scope tag. `vars`, `env`, and `settings` can all be declared once at the stack level and inherited by every component - [Modernizing Helmfile EKS Integration](https://atmos.tools/changelog/helmfile-eks-modernization): Atmos helmfile commands now use the identity system for AWS authentication and provide more flexible EKS cluster name configuration. - [Clearer Help Sections and Error Explanations](https://atmos.tools/changelog/help-command-groups-error-formatting): Atmos help output now separates built-in commands from custom commands, and error output now makes explanations easier to scan without adding extra headings. - [Better Error Messages: Helpful Hints, Rich Context, and Enterprise Error Tracking](https://atmos.tools/changelog/helpful-errors): We've completely rebuilt Atmos error handling from the ground up to provide **helpful hints**, **rich context**, and **enterprise-grade error tracking**. When something goes wrong, you now get actiona - [Populate a Store From Infrastructure You Already Deployed](https://atmos.tools/changelog/hooks-on-terraform-output-and-refresh): Reference architectures live for years. By the time you wire up a store hook, most of what it should cover was already deployed — some of it before hooks existed, some of it by a process outside Atmos - [Run Any Step Type as a Lifecycle Hook](https://atmos.tools/changelog/hooks-step-types): Atmos hooks can now run any workflow step type. A new `kind: step` hook bridges the component lifecycle (before/after `terraform plan`, `apply`, `deploy`, `init`) to the same step registry that powers - [HTTP Step Type: Call HTTP Endpoints from Workflows and Custom Commands](https://atmos.tools/changelog/http-step-type): Workflows and custom commands now support a native `http` step type that performs an HTTP request — any verb, query-string parameters, headers, and a request body (raw or form/JSON) — with per-attempt - [Unified Import Adapter Registry](https://atmos.tools/changelog/import-adapter-registry): Atmos now includes a unified import adapter registry that provides a modular, extensible architecture for configuration imports. - [Improved Error Messages for Terraform HCL Syntax Errors](https://atmos.tools/changelog/improved-hcl-syntax-error-messages): Atmos now provides clear, actionable error messages when your Terraform components contain HCL syntax errors, instead of the misleading "component not found" message. - [Apply a Stack and Everything It Depends On](https://atmos.tools/changelog/include-dependencies-closure): Standing up an environment is rarely one `apply`. The stack you actually care about sits on top of prerequisites — a network layer in a shared stack, a database a few components down — and something h - [Initialize an Atmos project from a proven starting point](https://atmos.tools/changelog/init-real-starter-project): Initializing a project should establish a useful local starting point, not leave a developer with an empty directory and a list of conventions to reconstruct. Modern development platforms provide an i - [Real-Time Instance Status from Atmos CLI to Atmos Pro](https://atmos.tools/changelog/instance-status-upload): For teams using [Atmos Pro](https://atmos-pro.com), the Atmos CLI now pushes instance status directly to the Atmos Pro dashboard the moment a plan or apply completes. The dashboard reflects the real s - [Interactive File Generation for Terraform, Helmfile, and Packer](https://atmos.tools/changelog/interactive-file-generation): File generation now features interactive component and stack selection, plus cross-provisioner support for helmfile and packer. Run `atmos terraform generate files` without arguments and get an intuit - [Interactive Prompts for Missing Required Flags](https://atmos.tools/changelog/interactive-flag-prompts): Atmos now includes interactive prompts for missing required flags and positional arguments, making commands more discoverable and user-friendly. This feature is being gradually rolled out across comma - [Interactive Identity Selection for Auth Login](https://atmos.tools/changelog/interactive-identity-selection): Running `atmos auth login` without specifying an identity is now more user-friendly. When no `--identity` flag is provided, Atmos presents an interactive selector to choose from your configured identi - [Pick configuration profiles interactively with a bare --profile](https://atmos.tools/changelog/interactive-profile-selection): Naming things from memory is one of the more tedious parts of a CLI workflow. You know you want to switch configuration contexts before running a command, but you don't always remember every profile n - [Interactive Profile Suggestion for Missing Identities](https://atmos.tools/changelog/interactive-profile-suggestion): When an `--identity` can't be resolved in the currently loaded Atmos config, Atmos now checks whether the identity is defined in another profile — and either prompts you to switch or hints at the exac - [Interactive Workflow & Command Steps Now Run in CI](https://atmos.tools/changelog/interactive-steps-ci-defaults): You built a slick interactive workflow — `choose` an account, `input` a release tag, then deploy. It is perfect on your laptop. Then CI runs it and everything stops with `interactive terminal required - [Interactive Component and Stack Selection for Terraform Commands](https://atmos.tools/changelog/interactive-terraform-prompts): Terraform commands now feature interactive prompts for component and stack selection. Run `atmos terraform plan` without arguments and get an intuitive selector instead of an error message. - [Introducing Atmos AI: Your Infrastructure-Aware AI Assistant](https://atmos.tools/changelog/introducing-atmos-ai): We're excited to introduce **Atmos AI**, an intelligent assistant built directly into Atmos CLI that understands your infrastructure-as-code like no other AI assistant can. - [Introducing Atmos Auth: Native Cloud Authentication for Platform Teams](https://atmos.tools/changelog/introducing-atmos-auth): We're introducing `atmos auth` - native cloud authentication built directly into Atmos. After years of solving the same authentication problems repeatedly across different tools and teams, we've built - [Introducing atmos auth list: Visualize Your Authentication Configuration](https://atmos.tools/changelog/introducing-atmos-auth-list): We're excited to announce a powerful new command for managing authentication in Atmos: `atmos auth list`. This command provides comprehensive visibility into your authentication configuration, making - [Introducing atmos auth shell: Isolated Shell Sessions for Secure Multi-Identity Workflows](https://atmos.tools/changelog/introducing-atmos-auth-shell): We're excited to introduce `atmos auth shell`, a new command that makes working with multiple cloud identities more secure. - [Introducing atmos init and atmos scaffold: Get Started in Seconds](https://atmos.tools/changelog/introducing-atmos-init-and-scaffold): We're excited to announce two new commands that dramatically simplify getting started with Atmos: `atmos init` and `atmos scaffold`. These commands eliminate the manual setup process and help you boot - [Introducing Atmos LSP: IDE-Native Infrastructure Configuration](https://atmos.tools/changelog/introducing-atmos-lsp): We're excited to introduce **Atmos LSP**, bringing IDE-quality features directly to your infrastructure configuration workflow—no context switching, no manual validation, no documentation hunting. - [Introducing atmos auth logout: Secure Credential Cleanup](https://atmos.tools/changelog/introducing-auth-logout): We're excited to announce a new authentication command: **`atmos auth logout`**. This command provides secure, comprehensive cleanup of locally cached credentials, making it easy to switch between ide - [Introducing --chdir: Simplify Your Multi-Repo Workflows](https://atmos.tools/changelog/introducing-chdir-flag): We're excited to announce a new global flag that makes working with Atmos across multiple repositories and directories significantly easier: `--chdir` (or `-C` for short). - [Introducing the Command Registry Pattern: Toward Pluggable Commands](https://atmos.tools/changelog/introducing-command-registry-pattern): We're excited to announce the first step in a major architectural evolution for Atmos: the **Command Registry Pattern**. This foundational change will eventually enable **pluggable commands**, allowin - [Introducing Emulators: Run Real Cloud Infrastructure Locally](https://atmos.tools/changelog/introducing-emulators): A big challenge for infrastructure developers is how hard it is to iterate locally. Every `terraform apply` needs a real cloud account, costs real money, and touches a live environment. And in many en - [Introducing Gists: Community Recipes for Atmos](https://atmos.tools/changelog/introducing-gists): Atmos now has a dedicated space for community-contributed recipes called **Gists** — creative patterns showing how to combine Atmos features in ways that go beyond standard documentation. - [Injecting Terraform Values into Kustomize Without Hand-Editing Overlays](https://atmos.tools/changelog/kustomize-gitops-delivery): Kustomize expects the files it consumes to have exact, reserved names. A remote base or component can only be included if the location it points to contains a file with one of a handful of recognized - [Introducing atmos list affected: A Better Way to See What Changed](https://atmos.tools/changelog/list-affected-command): Quickly identify which components and stacks are affected by your changes with the new `atmos list affected` command. - [List Command Query Syntax and Multi-Tool Installation](https://atmos.tools/changelog/list-and-toolchain-enhancements): New query syntax for `atmos list components` and support for installing multiple tools at once with `atmos toolchain install`. - [New List Configuration and Stack Filtering](https://atmos.tools/changelog/list-components-behavior-clarification): The `atmos list components` command now correctly shows unique component definitions, supports stack filtering, and uses a new dedicated configuration namespace. - [Visualize Component Dependencies as a Tree](https://atmos.tools/changelog/list-dependencies): The new `atmos list dependencies` command renders the dependency relationships between your components as a tree — showing, for every component, both what it **depends on** and what **depends on it**. - [list and describe Commands Degrade Gracefully by Default](https://atmos.tools/changelog/list-describe-graceful-degradation): Reading `!terraform.state` and `!terraform.output` can fail to resolve for a dozen different reasons — the backend hasn't been applied yet, your credentials aren't configured, you don't have access to - [Matrix Output for List Instances](https://atmos.tools/changelog/list-instances-matrix): `atmos list instances` now supports `--format=matrix`, producing GitHub Actions-compatible JSON for driving parallel CI/CD jobs — the same format already available in `atmos describe affected`. - [`atmos list instances`: --stack, --filter, and --query now work](https://atmos.tools/changelog/list-instances-stack-filter-query): Three documented flags on `atmos list instances` were silently ignored: `--stack`, `--filter`, and `--query`. They now do what the docs say. - [Full Template and YAML-Function Control for `atmos list`](https://atmos.tools/changelog/list-process-flags): Every `atmos list` subcommand that processes stack manifests now accepts `--process-templates` and `--process-functions` (with matching `ATMOS_PROCESS_TEMPLATES` / `ATMOS_PROCESS_FUNCTIONS` env vars), - [Selective YAML Function Bypass with --skip on `atmos list`](https://atmos.tools/changelog/list-skip-flag): Every `atmos list` subcommand that processes stack manifests now accepts `--skip ` and the matching `ATMOS_SKIP` env var, mirroring the surface already exposed by `atmos describe affect - [New !literal YAML Function for Template Passthrough](https://atmos.tools/changelog/literal-yaml-function): Atmos now supports the `!literal` YAML function, which preserves values exactly as written without any template processing. This solves a common pain point when passing template syntax to downstream t - [Run Terraform Tests Locally Against Cloud Emulators](https://atmos.tools/changelog/local-terraform-tests-with-emulators): Terraform's native testing framework (`*.tftest.hcl`) is great — until you hit a `run` block with `command = apply`. Those blocks create **real** infrastructure, so running them means a cloud account, - [Locals Context Access](https://atmos.tools/changelog/locals-context-access): Locals can access `{{ .settings }}`, `{{ .vars }}`, and `{{ .env }}` from the same file during template resolution. - [YAML Functions in Locals](https://atmos.tools/changelog/locals-yaml-functions): Locals now support YAML functions like `!env`, `!exec`, `!store`, `!terraform.state`, and `!terraform.output`. - [Fixing Gatekeeper SIGKILLs on Downloaded Toolchain Verifiers](https://atmos.tools/changelog/macos-toolchain-verifier-trust): On macOS, Atmos would sometimes install a verifier CLI (like `cosign`, used to check signatures on downloaded toolchain binaries) through `verifier_install: auto`, checksum-verify it successfully — an - [Breaking Change: macOS Now Uses ~/.config for XDG Paths](https://atmos.tools/changelog/macos-xdg-cli-conventions): Atmos now follows CLI tool conventions on macOS, using `~/.config`, `~/.cache`, and `~/.local/share` instead of `~/Library/Application Support`. This ensures seamless integration with Geodesic and con - [Configure MCPs once in Atmos, use it from Claude Code, Codex, and Gemini](https://atmos.tools/changelog/mcp-for-ai-coding-assistants): Claude Code, OpenAI Codex CLI, and Google Gemini CLI all speak MCP, but each wants its own config format, its own credentials flow, and its own idea of where binaries live. This post shows how to cent - [Connect Atmos to MCP Servers — Use Cloud Tools Without Reimplementing Them](https://atmos.tools/changelog/mcp-server-integrations): Atmos can now connect to external MCP servers and use their tools directly in AI conversations. Configure any MCP server in `atmos.yaml`, and its tools appear alongside native Atmos tools in `atmos ai - [Manage MCP Servers Without Hand-Editing YAML](https://atmos.tools/changelog/mcp-server-management-commands): Getting Atmos connected to an MCP server, or letting your AI assistant call Atmos's own tools, used to mean opening `atmos.yaml` and hand-writing a `mcp.servers` entry — then, separately, remembering - [MCP Servers No Longer Need a Second Flag to Do Anything](https://atmos.tools/changelog/mcp-tools-always-available): You set `mcp.enabled: true`, ran `atmos mcp start`, and got: `failed to initialize AI components: tools are disabled`. MCP was on. Why did anything else need to be "enabled" for a command whose entire - [Metadata Inheritance](https://atmos.tools/changelog/metadata-inheritance): Metadata now inherits from base components, just like `vars` and `settings`. - [Stable Workspace Keys with metadata.name](https://atmos.tools/changelog/metadata-name-workspace-keys): New `metadata.name` field provides stable Terraform state paths when using versioned component folders. - [New Migration Guides: Your Path to Atmos](https://atmos.tools/changelog/migration-guides): We've added comprehensive migration guides to help teams adopt Atmos regardless of their starting point. - [Multi-Cloud Documentation and Design Patterns](https://atmos.tools/changelog/multi-cloud-docs): Atmos has always been cloud agnostic, but our documentation hasn't always reflected that. This release adds comprehensive multi-cloud documentation including a new design pattern for organizing stacks - [Native CI Integration: Rich Plan Summaries Without Extra Actions](https://atmos.tools/changelog/native-ci-integration): When you see complex bash scripts and conditional logic in GitHub Actions workflows, that's a signal: the underlying tool wasn't designed for CI. Atmos now has built-in CI integration that makes the s - [Plan-then-Deploy in CI: Planfile Storage and Automatic Drift Verification](https://atmos.tools/changelog/native-ci-planfile-verification): Atmos native CI now supports the full plan-then-deploy workflow with planfiles: `atmos terraform plan --ci` uploads the planfile to durable storage, and `atmos terraform deploy --ci` automatically dow - [Native Container Image Summaries in CI](https://atmos.tools/changelog/native-container-image-ci-summaries): Atmos container builds and pushes now write rich image summaries directly to the CI job summary when native CI is enabled. Use `type: container` workflow steps or `atmos container build/push` componen - [Native Container Steps in Atmos Workflows](https://atmos.tools/changelog/native-container-steps): Atmos workflows and custom commands can now run containers natively. A new `type: container` step builds images, pushes them to registries, and runs containerized tools — Docker or Podman — through th - [Native Dev Container Support: Solving "Works on My Machine" Once and For All](https://atmos.tools/changelog/native-devcontainer-support): Running Atmos and managing cloud infrastructure inevitably means depending on dozens of tools—Terraform, kubectl, Helmfile, AWS CLI, and many more. But here's the problem every platform team faces: ** - [Native Helm Components and `atmos helmfile template`](https://atmos.tools/changelog/native-helm-components): Atmos now treats Helm as a first-class component type. Define a Helm release — local chart, remote repository chart, or OCI chart — in your stack configuration, then `template`, `diff`, `apply`, and ` - [Native Kubernetes Components: Render, Apply, and Publish to GitOps Repos](https://atmos.tools/changelog/native-kubernetes-components): Atmos now treats Kubernetes as a first-class component type. Define Kubernetes objects — inline manifests, files, directories, or Kustomize overlays — in your stack configuration, then `render`, `diff - [Fixed: Nested Maps in Terraform Backend Configurations](https://atmos.tools/changelog/nested-backend-maps-support): Atmos now properly handles nested maps in Terraform backend configurations when using HCL format. This fixes an issue where complex backend settings like `assume_role` were silently dropped. - [oci:// Sources Now Work with JIT Auto-Provisioning](https://atmos.tools/changelog/oci-source-jit-provisioning): A component with an `oci://` source and `provision.workdir.enabled: true` failed the moment you ran any Terraform operation against it. JIT auto-provisioning (the `before.terraform.init` hook) failed - [AI Skills, Now Bundled in the Atmos Binary](https://atmos.tools/changelog/offline-ai-skill-catalog): The official Atmos [agent skills](/cli/commands/ai/skill) are now embedded directly in the Atmos binary. `atmos ai skill install ` works **fully offline** — no network call, no Git clone — and ` - [Run Ordered Steps in Lifecycle Hooks](https://atmos.tools/changelog/ordered-steps-hooks): Atmos lifecycle hooks can now run an ordered list of steps with `kind: steps`. Use it when one lifecycle event needs sequencing but the orchestration should stay local to the component being operated - [Packer Directory-Based Templates for Multi-File Configurations](https://atmos.tools/changelog/packer-directory-based-templates): Atmos now supports directory-based Packer templates by default. Instead of requiring a single HCL template file, you can organize your Packer configurations across multiple files following HashiCorp's - [Pager Default Behavior Corrected](https://atmos.tools/changelog/pager-default-correction): We've identified and corrected a regression in Atmos where the pager was incorrectly enabled by default, contrary to the intended behavior documented in a previous release. - [Parallel and Matrix Steps for Atmos Workflows](https://atmos.tools/changelog/parallel-matrix-workflow-steps): Atmos workflows can now run independent work concurrently with first-class `parallel` and `matrix` control steps. Add dependency-aware fan-out, readable grouped or live-prefixed output, and explicit f - [Faster, Safer Parallel Toolchain Installs](https://atmos.tools/changelog/parallel-toolchain-installs): Atmos toolchain installs can now run independent packages in parallel. Batch installs use four workers by default, while preserving the compact terminal UI: every active package keeps its own spinner, - [Parent Directory Search and Git Root Discovery](https://atmos.tools/changelog/parent-directory-search-and-git-root-discovery): Atmos now searches parent directories for `atmos.yaml` and discovers `.atmos.d/` at the git repository root, making it easier to run commands from anywhere in your project. - [Split One Logical Stack Across Focused Manifests](https://atmos.tools/changelog/parent-scoped-multi-file-stacks): Large stacks eventually turn into a shared bottleneck. Network, platform, and application owners all need to contribute components, but putting every change in one manifest makes reviews noisy and par - [Path-Based Component Resolution for Terraform, Helmfile, Packer, Describe, and Validate Commands](https://atmos.tools/changelog/path-based-component-resolution): Atmos now supports using filesystem paths instead of component names for all component commands. Use `.` for the current directory, relative paths like `./vpc` or `../eks`, or absolute paths. This mig - [Path-Based Custom Commands](https://atmos.tools/changelog/path-based-custom-commands): Atmos custom commands now support path-based names. Instead of writing a deeply nested command tree just to describe a command path, you can put the full command path in `name`. - [Test PR Features with --use-version](https://atmos.tools/changelog/pr-artifact-installation): Test features from any Atmos pull request or commit SHA without compiling from source or manually downloading artifacts. - [Server-Side Commits via Atmos Pro GitHub App](https://atmos.tools/changelog/pro-commit): Atmos now supports **server-side commits** via the Atmos Pro GitHub App. The new `atmos pro commit` command sends your changes to Atmos Pro, which creates the commit using its GitHub App installation - [Atmos Pro: Instances API Migration to Query Parameters](https://atmos.tools/changelog/pro-instances-api-query-params): Updated the Atmos Pro integration to use query parameters for the instances API endpoint, fixing issues with stack and component names containing slashes and improving API compatibility. - [Atmos Pro now reports check status on GitHub merge queue commits](https://atmos.tools/changelog/pro-merge-queue-support): `atmos describe affected --upload` now works under `GITHUB_EVENT_NAME=merge_group`, so Atmos Pro can correctly conclude check runs on the synthetic commits GitHub creates when a PR enters a merge queu - [Introducing the Atmos Product Roadmap](https://atmos.tools/changelog/product-roadmap): We're sharing the [Atmos Product Roadmap](/roadmap)—a transparent view of where we've been, where we're headed, and what's coming next. Infrastructure teams evaluating Atmos often ask *"What's the lon - [Profiles Can Now Import Shared Configuration](https://atmos.tools/changelog/profile-imports): Auth profiles and team defaults are often managed centrally, but workload or app repositories still need to use them. Until now, that usually meant copying profile YAML into each repository and keepin - [Configuration Provenance Tracking: Know Where Every Value Comes From](https://atmos.tools/changelog/provenance-tracking): We've shipped a feature that developers working with complex infrastructure configurations have been asking for: **provenance tracking**. With the new `--provenance` flag in `atmos describe component` - [New !random YAML Function: Generate Random Values in Your Configurations](https://atmos.tools/changelog/random-yaml-function): Need to generate random port numbers, worker IDs, or other numeric values in your Atmos configurations? The new `!random` YAML function makes it easy. - [Remote Stack Imports](https://atmos.tools/changelog/remote-stack-imports): Atmos now supports importing stack configurations from remote URLs. Reference shared configurations from GitHub, S3, GCS, or any HTTP endpoint directly in your stack files. - [Check Workflow Prerequisites with require and assert](https://atmos.tools/changelog/require-assert-step): Workflows often depend on tools, files, and directories being present before they run. Without a first-class check, those prerequisites tend to hide inside brittle shell snippets and ad hoc command ch - [Retry Support for Vendoring and Source Operations](https://atmos.tools/changelog/retry-support-vendoring): Atmos now supports automatic retry with exponential backoff for vendoring and source operations. This makes component downloads more resilient to transient network failures, connection resets, and Git - [Safe Logout: Preserve Keychain Credentials by Default](https://atmos.tools/changelog/safe-logout-preserves-keychain): `atmos auth logout` now preserves keychain credentials by default for faster re-authentication. Only session data is cleared. Use `--keychain` to permanently delete credentials. - [Atmos Can Finally Speak for Itself](https://atmos.tools/changelog/say-step): Workflows now have a `say` step type that speaks a message out loud using text-to-speech — an audible cue for when a long-running workflow finishes or needs your attention, even after you've switched - [Generate Verifiable Terraform Provenance SBOMs](https://atmos.tools/changelog/sbom-provenance): Compliance reviews often start with a deceptively simple question: what exactly is in this infrastructure release? Answering it by hand means reconciling vendored sources, provider locks, module downl - [Scaffolds turn your golden paths into a platform product](https://atmos.tools/changelog/scaffold-conditional-generation-and-hooks): Platform teams build golden paths so application teams can begin with the right architecture, guardrails, and operational conventions. A GitHub template repository is an excellent way to distribute th - [Generate one file per selection with matrix](https://atmos.tools/changelog/scaffold-matrix): Every file a scaffold template declares renders at most once. `when:` can skip a file, but it can never multiply one. You could work around that by authoring every combination up front and letting `wh - [Keep your formatting through atmos scaffold --update](https://atmos.tools/changelog/scaffold-merge-driver): Atmos scaffolds can perform genuinely complex three-way merges of YAML templates: keys can merge intelligently, and comments and local customizations are preserved when changes don't conflict. That ca - [Scanner Findings as Inline PR Annotations and Code Scanning Alerts](https://atmos.tools/changelog/scanner-annotations-and-code-scanning): Security scanner hooks (Checkov, Trivy, KICS) can now surface findings as **inline GitHub annotations** on the pull request diff and upload them to **GitHub Code Scanning** (the Security tab) — native - [Security Scanner Findings Now Surface in the CI Job Summary](https://atmos.tools/changelog/scanner-findings-in-ci-job-summary): Security scanner hooks (Checkov, Trivy, KICS) now write their findings to the GitHub Actions job step summary automatically — so scan results show up in the pipeline run instead of being buried in the - [Introducing Secrets Management in Atmos](https://atmos.tools/changelog/secrets-management): Atmos now has first-class **secrets management**: you declare the secrets each component depends on, provision their values per environment, and reference them at runtime with a single YAML function. - [Critical Fix: Proper Shell Argument Quoting in Custom Commands](https://atmos.tools/changelog/shell-argument-quoting-fix): We've fixed a critical bug in how Atmos handles arguments passed to custom commands via `{{ .TrailingArgs }}`. This fix improves security and ensures whitespace and special characters are preserved co - [Source Cache TTL for JIT-Vendored Components](https://atmos.tools/changelog/source-cache-ttl): Atmos now supports a `ttl` field on component source configuration to control how long cached JIT-vendored sources are reused before automatically re-pulling from the remote. This is especially useful - [List Components with Source Configuration](https://atmos.tools/changelog/source-list-command): Atmos now includes a `source list` command to display components with source configuration. Both `--stack` and `[component]` arguments are optional, allowing flexible filtering across your infrastruct - [Source Provisioner UX Improvements](https://atmos.tools/changelog/source-provisioner-ux): The source provisioner now provides better visual feedback with spinners during auto-provisioning, interactive confirmation prompts for delete operations, and interactive stack selection when `--stack - [SSE-C Encryption Support for Remote State Lookups](https://atmos.tools/changelog/sse-c-support): The `!terraform.state` YAML function now supports reading from S3 buckets encrypted with customer-provided keys (SSE-C). - [Explicit Stack Names in Stack Manifests](https://atmos.tools/changelog/stack-manifest-name-override): You can now specify an explicit `name` field in stack manifests to override the logical stack name. This is especially useful when migrating from other tools like Terragrunt, or when your infrastructu - [Stack Name Identity and Zero-Config Defaults](https://atmos.tools/changelog/stack-name-identity): Atmos now enforces a single canonical identity per stack and supports zero-config stack naming using filenames. These changes make Atmos easier for newcomers while providing explicit control for advan - [Read, Write, and Delete Store Values from the CLI and Workflows](https://atmos.tools/changelog/store-crud-and-workflow-writes): A build step often creates a value that a different step needs later. Examples are an image tag, a build number, or a deployment marker. In the past, you had only bad ways to pass this value along. Yo - [Identity-Based Authentication for Stores](https://atmos.tools/changelog/store-identity-support): Atmos stores now support identity-based authentication. You can configure stores to authenticate using the same named identities from `atmos auth` instead of relying on default credential chains. - [Tags and Labels: a First-Class Way to Categorize and Select Anything in Atmos](https://atmos.tools/changelog/tags-and-labels): Your stack hierarchy picks one way to organize your infrastructure — org, account, region, component type — and it can only pick one. `vpc` in `stacks/orgs/acme/prod/network.yaml` tells you where it l - [Custom Commands and Workflows Are Now a Complete Task Runner Replacement](https://atmos.tools/changelog/taskfile-convergence): If you've ever tried to move a `Taskfile.yml` over to Atmos, you've hit the gap: `deps:` had no clean equivalent in custom commands, `sources:`/`generates:` up-to-date checking didn't exist at all, an - [Templated Import Paths: Pin Imports from a Single Variable](https://atmos.tools/changelog/templated-import-paths): Atmos now renders Go templates in stack **import paths** using `settings`, `vars`, and `env` defined by **earlier imports in the same manifest**. You can pin a remote import's Git `?ref=` — or pick a - [Pace Terminal Output for Demos and Recordings](https://atmos.tools/changelog/terminal-speed): Terminal demos and recordings are hard to follow when a command dumps hundreds of lines instantly. The output may be correct, but viewers cannot read it and recording tools capture a wall of text inst - [Customize Your Terminal with Atmos Themes](https://atmos.tools/changelog/terminal-themes): Atmos now includes 350+ terminal themes to customize your CLI experience. Choose from popular themes like Dracula, Solarized, or GitHub Dark, or browse the complete collection to find one that matches - [Dependency-Ordered Execution for Terraform --all Flag](https://atmos.tools/changelog/terraform-all-dependency-order): The `--all` flag now executes Terraform components in dependency order. Run `atmos terraform apply --all -s ue2-dev` and components are automatically processed from their `dependencies.components` rel - [Fix: terraform plan/apply --all actually runs in dependency order](https://atmos.tools/changelog/terraform-all-dependency-order-wired-up): `atmos terraform plan --all` and `apply --all` now execute components in dependency (topological) order, as originally documented. Until this fix, the `--all` flag was processing components in a non-d - [Fixed: Terraform CLI Flags Restored After Registry Migration](https://atmos.tools/changelog/terraform-cli-flags-restored): Several terraform CLI flags that were not working after version 1.202.0 have been restored. These flags were inadvertently broken during the command registry migration. - [Terraform Cloud Backend Support for !terraform.output](https://atmos.tools/changelog/terraform-cloud-output-function): The `!terraform.output` YAML function now works seamlessly with Terraform Cloud and Terraform Enterprise backends, enabling cross-component dependencies without switching backend types. - [Comprehensive Documentation for Terraform Commands](https://atmos.tools/changelog/terraform-command-documentation): We've added comprehensive documentation for all 35 Terraform commands in Atmos, making it easier to understand how to orchestrate Terraform with stack-based configurations. Each command now has dedica - [Improved Terraform Command Architecture for Better Validation and Help](https://atmos.tools/changelog/terraform-command-registry-pattern): Atmos terraform commands now use a modern registry pattern that improves flag validation, provides better help text, and sets the foundation for enhanced developer experience across all terraform subc - [Component Mocks for Terraform YAML Lookups](https://atmos.tools/changelog/terraform-component-mocks): Cross-component Terraform lookups are useful precisely when an application component needs the outputs of something like a VPC, cluster, or database. They can also make a local plan or configuration r - [Recover from transient Terraform errors automatically with component retry](https://atmos.tools/changelog/terraform-component-retry): Provider downloads fail. Registries return 502s. State backends time out. None of that is your code's fault, but when it happens during `atmos terraform plan` in CI, the only recovery has always been - [Terraform DAG Concurrency](https://atmos.tools/changelog/terraform-dag-concurrency): Atmos Terraform bulk commands now run through a dependency graph, with optional bounded concurrency for plans and deterministic ordering for multi-component runs. - [Bulk `terraform init --all` and `--affected`](https://atmos.tools/changelog/terraform-init-bulk-execution): Bulk commands like `terraform apply`, `plan`, and `destroy` could already run across every component in dependency order with `--all`, but `init` couldn't — reinitializing a whole stack meant scriptin - [Lifecycle hooks for terraform init, and --skip-hooks now works for before-* events](https://atmos.tools/changelog/terraform-init-hooks-and-skip-hooks-fix): Atmos now supports `before.terraform.init` and `after.terraform.init` lifecycle hooks, and `--skip-hooks` is finally honored for *before-* hooks across `plan`, `apply`, and `deploy`. - [New --format Flag for Terraform Output](https://atmos.tools/changelog/terraform-output-format): The `atmos terraform output` command now supports a `--format` flag, making it easy to export Terraform outputs in various formats for use in CI/CD workflows, scripts, and configuration files. - [Zero-Config Terraform Provider Caching](https://atmos.tools/changelog/terraform-provider-caching): Atmos now automatically caches Terraform providers across all components, dramatically reducing `terraform init` times and network bandwidth. This feature is enabled by default with zero configuration - [Testing Custom Terraform Providers with Atmos Components](https://atmos.tools/changelog/terraform-provider-development): If you develop Terraform providers, you can now test them locally with Atmos-managed components using Terraform's development overrides feature. This enables rapid iteration without publishing develop - [Manage the Terraform CLI Config from atmos.yaml](https://atmos.tools/changelog/terraform-rc-management): Atmos can now manage the **Terraform/OpenTofu runtime configuration (RC)** for you. Declare it once under `components.terraform.rc`, and Atmos writes a temporary CLI config file and points the subproc - [Terraform Registry Cache: Reproducible Infrastructure Builds](https://atmos.tools/changelog/terraform-registry-cache): Atmos can now transparently **cache Terraform and OpenTofu providers and modules** behind a single feature flag. Turn it on and repeated runs — local or CI — stop re-downloading the same artifacts, ke - [Pin Terraform and Provider Versions in Stack Configuration](https://atmos.tools/changelog/terraform-required-providers): You can now pin Terraform and provider versions directly in your stack configuration. Atmos generates `terraform_override.tf.json` files with `required_version` and `required_providers` blocks, giving - [Just-in-Time Component Vendoring with source](https://atmos.tools/changelog/terraform-source-provisioner): Atmos now supports just-in-time (JIT) vendoring of components directly from stack configuration using the top-level `source` field. This works for **Terraform**, **Helmfile**, and **Packer** component - [Fixed: !terraform.state with Disabled Workspaces](https://atmos.tools/changelog/terraform-state-workspaces-disabled-fix): The `!terraform.state` YAML function now correctly reads Terraform state when workspaces are disabled (`components.terraform.workspaces_enabled: false` in `atmos.yaml`). Previously, Atmos looked for s - [Terraform state migrations with tfmigrate](https://atmos.tools/changelog/terraform-tfmigrate): Refactoring Terraform code leaves state behind. Rename a resource, or move it between root modules, and every plan shows a destroy-and-recreate for infrastructure that never changed. You can fix this - [Enforce Terraform Conventions with the tflint Hook Kind](https://atmos.tools/changelog/tflint-hook-kind): Consistent, idiomatic Terraform doesn't happen by accident — it takes a linter enforcing the same conventions on every component, every run. Atmos already runs security and cost scanners as component - [Help Text Now Respects Your Terminal Theme](https://atmos.tools/changelog/theme-aware-help): Atmos help text now automatically adapts to your configured theme, providing a consistent and visually cohesive experience across all commands. Whether you're using a dark theme like Dracula or a ligh - [Theme Commands Migrated to StandardFlagParser](https://atmos.tools/changelog/theme-commands-environment-variables): The theme commands have been migrated to use the modern `StandardFlagParser` infrastructure, bringing them in line with other Atmos commands. - [Toolchain registry adds github_archive and github_content support](https://atmos.tools/changelog/toolchain-aqua-archive-and-content): Atmos's Aqua-compatible toolchain registry now understands two more package types: `github_archive` and `github_content`. Tools that ship as a source tarball (like `adr-tools` and `tfenv`) or as a sin - [Script-Friendly Output for atmos toolchain get](https://atmos.tools/changelog/toolchain-get-plain-json-output): Pulling a tool's version into a script usually means scraping decorated terminal output. A checkmark here, a color code there, maybe a table row — and now the one-liner that used to grab a version str - [Native Toolchain Management with Aqua Registry Integration](https://atmos.tools/changelog/toolchain-management): Atmos now includes native toolchain management that seamlessly integrates with the Aqua registry ecosystem — giving you access to hundreds of pre-configured CLI tools without the overhead of external - [Toolchain now installs aws-cli, Node, and other multi-file tools correctly](https://atmos.tools/changelog/toolchain-multi-file-tools): You pinned `aws/aws-cli` in your toolchain, ran `atmos toolchain install`, and saw a green checkmark — then `aws --version` died with `Failed to load Python shared library`. Or you pinned `nodejs/node - [Atmos Toolchain Now Verifies Package Checksums and Signatures](https://atmos.tools/changelog/toolchain-package-verification): Atmos toolchain installs now verify downloaded packages before extraction when registry metadata provides checksums, signatures, or attestations. - [Toolchain proxies install only the commands you use](https://atmos.tools/changelog/toolchain-proxies): Installing every tool a repository might eventually need makes project setup slow and wasteful. Atmos toolchain proxies provide on-demand, just-in-time installation instead: invoking a configured comm - [atmos toolchain update: Move a Pinned Tool Forward Safely](https://atmos.tools/changelog/toolchain-update-command): Pinning a CLI tool to an exact version is good practice — until it's time to move forward. Then it means opening `.tool-versions` by hand, going to check the tool's release page, picking a version, an - [Topic-Specific CLI Help](https://atmos.tools/changelog/topic-specific-cli-help): Atmos help showed too much at once. A simple command like `atmos terraform plan --help` explained the command, its examples, its own flags, compatibility flags, and every inherited global flag, which - [Terminal Steps: tty, interactive, and exec for Custom Commands and Workflows](https://atmos.tools/changelog/tty-interactive-steps): Custom command and workflow shell steps now support docker-style `tty` and `interactive` fields — plus a new `exec` step type that replaces the Atmos process entirely — so commands like `aws ssm start - [Unified Task Runner for Custom Commands](https://atmos.tools/changelog/unified-task-runner): Custom commands now support structured task syntax with per-step configuration including timeouts, retry logic, working directories, and authentication identities. - [New !unset YAML Function to Delete Inherited Keys](https://atmos.tools/changelog/unset-yaml-function): Atmos now supports the `!unset` YAML function, which **removes a key entirely** from a stack configuration during inheritance and merging. It's the clean way to drop a value that a parent stack or imp - [Unsupported YAML Function Validation](https://atmos.tools/changelog/unsupported-yaml-function-validation): Atmos now detects unsupported and misspelled YAML function tags before configuration processing continues. Invalid tags return a clear error with the supported Atmos YAML functions, so typos fail fast - [Install Atmos from a Branch or Tag with ref:](https://atmos.tools/changelog/use-version-ref): `--use-version` now accepts a `ref:` prefix, so you can run the latest build of any branch or tag — like `ref:main` — without looking up a commit SHA. - [Manage Vendored Dependencies Locally](https://atmos.tools/changelog/vendor-diff-and-update): Package managers normally let you discover available updates, review their impact, and apply them locally. Vendored Atmos components did not: the only updater was a GitHub Action, so there was no nati - [Verify Vendored Files Never Silently Drift](https://atmos.tools/changelog/vendor-lock-verify): Vendoring pulls external code into your own repository so it's reviewable, diffable, and not subject to an upstream registry going away. But once those files land on disk, nothing has watched them sin - [Select Vendored Components by Stack, Label, or Tag](https://atmos.tools/changelog/vendor-stack-flag): A CI job deploying the dev stack shouldn't need to vendor every component in the repository -- just the ones dev actually uses. Production deploys have the same problem in reverse: pulling in componen - [Per-Target Version Overrides in Vendor Manifests](https://atmos.tools/changelog/vendor-target-version-overrides): Vendor targets now accept optional version overrides, enabling multiple versions of the same component from a single source entry. - [Command Aliases for Vendor and Workflow List](https://atmos.tools/changelog/vendor-workflow-list-aliases): Atmos now supports `atmos vendor list` and `atmos workflow list` as aliases for their `atmos list vendor` and `atmos list workflows` counterparts. - [Version-Aware JIT Source Provisioning with TTL](https://atmos.tools/changelog/version-aware-jit-provisioning): Atmos now supports intelligent version-aware JIT (Just-In-Time) source provisioning with automatic re-provisioning on version changes and TTL-based cleanup for stale workdirs. - [Enforce Atmos Version Requirements with Version Constraints](https://atmos.tools/changelog/version-constraint-validation): Atmos now supports version constraint validation, allowing you to specify required Atmos version ranges in your `atmos.yaml` configuration. When your configuration requires specific features or behavi - [Browse and Explore Atmos Releases from Your Terminal](https://atmos.tools/changelog/version-list-show-commands): We're introducing two new commands for exploring Atmos releases: `atmos version list` and `atmos version show`. Browse release history with date filtering, inspect artifacts, and keep your infrastruct - [Pin your manifest schema to an Atmos release, not a moving target](https://atmos.tools/changelog/versioned-manifest-schema): Upgrading the `atmos` binary has always meant upgrading your schema validation too, whether you wanted to or not. The JSON Schema published at `atmos.tools/schemas/atmos/atmos-manifest/1.0/...` is a s - [Welcome to the Atmos Changelog](https://atmos.tools/changelog/welcome): We're excited to launch the Atmos Changelog—your go-to source for feature announcements, technical deep dives, and best practices for managing cloud infrastructure at scale. - [Workflow Environment Variables](https://atmos.tools/changelog/workflow-environment-variables): Workflows now support environment variables at both workflow and step levels with hierarchical merging. - [Workflow File Auto-Discovery: Run Workflows Without Specifying Files](https://atmos.tools/changelog/workflow-file-auto-discovery): The `atmos workflow` command now automatically discovers workflow files, eliminating the need to specify `--file` for uniquely named workflows. This developer experience improvement makes running work - [Use Tags and Labels with Workflows](https://atmos.tools/changelog/workflow-tags-and-labels): Atmos workflows already supported `--stack`. They now also support `--tags` and `--labels`, forwarding those selectors to every nested `type: atmos` step. - [Working Directory Support for Commands and Workflows](https://atmos.tools/changelog/working-directory-support): Custom commands and workflow steps can now specify a `working_directory` to control where they execute. - [Preserve Directory Hierarchy in Terraform State Buckets](https://atmos.tools/changelog/workspace-prefix-separator): You can now preserve `/` in component names when Atmos auto-generates backend key prefixes — keeping your state bucket organized to match your component directory structure. - [Edit Atmos config, stacks, and vendor manifests without breaking YAML](https://atmos.tools/changelog/yaml-editing-config-stack-vendor): Atmos can now read and edit your YAML — `atmos.yaml`, stack manifests, and `vendor.yaml` — through first-class commands that **preserve comments, anchors, YAML functions, and Go templates**. No more ` - [Atmos Now Detects Circular Dependencies in YAML Functions](https://atmos.tools/changelog/yaml-function-circular-dependency-detection): Atmos now detects circular dependencies in YAML function calls and provides a clear call stack showing exactly where the cycle occurs. - [YAML Key Delimiter for Dot Notation in Stack Files](https://atmos.tools/changelog/yaml-key-delimiter): Atmos now supports expanding dotted YAML keys into nested maps in stack configuration files. Enable the `key_delimiter` setting in `atmos.yaml` to use concise dot notation like `metadata.component: vp - [YQ Default Values Now Work Reliably in YAML Functions](https://atmos.tools/changelog/yq-defaults-yaml-functions): We've fixed an issue where YQ default values (using the `//` fallback operator) in `!terraform.state` and `!terraform.output` YAML functions were not being evaluated when components weren't provisione - [Zero-Configuration Terminal Output: Write Once, Works Everywhere](https://atmos.tools/changelog/zero-config-terminal-output): Atmos now features intelligent terminal output that adapts to any environment automatically. Developers can write code assuming a full-featured terminal, and Atmos handles the rest - capability detect - [Atmos AI](https://atmos.tools/ai/): AI-powered capabilities for Atmos infrastructure management - [Claude Code Integration](https://atmos.tools/ai/claude-code-integration): Use Claude Code with Atmos via MCP server for development workflows - [MCP Server Integration](https://atmos.tools/ai/mcp-server): Connect Atmos AI tools to any MCP-compatible client - [AI Troubleshooting](https://atmos.tools/ai/troubleshooting): Troubleshoot common issues with the Atmos AI Assistant - [Best Practices](https://atmos.tools/best-practices/): Learn the opinionated "Best Practices" for using Atmos - [Component Best Practices](https://atmos.tools/best-practices/components): Learn the opinionated "Best Practices" for using Components with Atmos - [Stacks Best Practices](https://atmos.tools/best-practices/stacks): Learn the opinionated "Best Practices" for using Stacks with Atmos - [Terraform Best Practices with Atmos](https://atmos.tools/best-practices/terraform): Learn the opinionated "Best Practices" for using Terraform with Atmos - [Atmos Cheatsheet](https://atmos.tools/cheatsheet): ```shell atmos list stacks ``` ``` ├── atmos.yaml - [CLI Commands Cheat Sheet](https://atmos.tools/cheatsheets/commands): CLI Commands Cheat Sheet - [Components Cheatsheet](https://atmos.tools/cheatsheets/components): ``` ├── atmos.yaml ├── components │   └── myapp │   ├── main.tf │   ├── outputs.tf │   - [Stacks Cheatsheet](https://atmos.tools/cheatsheets/stacks): ``` ├── atmos.yaml ├── components │   └── myapp │   ├── main.tf │   ├── outputs.tf │   - [Vendoring Cheatsheet](https://atmos.tools/cheatsheets/vendoring): ``` ├── atmos.yaml ├── vendor.yaml └── components └── myapp ├── main.tf ├── - [Native CI](https://atmos.tools/ci/): Native CI/CD integration for GitHub Actions and other CI providers - [Job Summaries](https://atmos.tools/ci/job-summaries): Rich Markdown job summaries for Terraform plan, apply, test, Kubernetes, Helm, and Helmfile operations - [Planfile Storage](https://atmos.tools/ci/planfile-storage): Store and verify Terraform planfiles across CI pipeline stages - [Atmos CLI](https://atmos.tools/cli/): This command starts an interactive UI to select an Atmos command, component and stack. Press "Enter" to execute the command - [atmos](https://atmos.tools/cli/commands/): Atmos CLI Commands - [atmos about](https://atmos.tools/cli/commands/about): Learn about Atmos - [atmos ai ask](https://atmos.tools/cli/commands/ai/ask): Ask the AI assistant a question directly from the command line - [atmos ai chat](https://atmos.tools/cli/commands/ai/chat): Start an interactive AI chat session with the Atmos AI assistant - [atmos ai exec](https://atmos.tools/cli/commands/ai/exec): Run Atmos and shell commands via AI prompts non-interactively for automation and CI/CD integration - [atmos ai sessions](https://atmos.tools/cli/commands/ai/sessions): Manage AI chat sessions including list, clean, export, and import operations - [atmos ai skill](https://atmos.tools/cli/commands/ai/skill): Manage AI skills including install, list, update, and uninstall operations - [atmos ai](https://atmos.tools/cli/commands/ai/usage): AI-Powered Assistant for Atmos - [atmos ansible playbook](https://atmos.tools/cli/commands/ansible/playbook): Use this command to run an Ansible playbook for an Atmos component in a stack, applying configuration changes to target hosts. - [atmos ansible](https://atmos.tools/cli/commands/ansible/usage): Use these subcommands to interact with [Ansible](https://docs.ansible.com/ansible/latest/index.html) for automating infrastructure configuration, application deployment, and orchestration. Use this command to display the currently installed Ansible version and configuration information. - [atmos atlantis generate repo-config](https://atmos.tools/cli/commands/atlantis/generate-repo-config): Use this command to generate a repository configuration for Atlantis. - [atmos atlantis](https://atmos.tools/cli/commands/atlantis/usage): Atmos Atlantis Commands - [atmos auth console](https://atmos.tools/cli/commands/auth/console): Open cloud provider web console in your default browser using authenticated credentials. - [atmos auth env](https://atmos.tools/cli/commands/auth/env): Export temporary cloud credentials as environment variables for the selected identity. - [atmos auth exec](https://atmos.tools/cli/commands/auth/exec): Execute a command with authentication environment variables set for the selected identity. - [atmos auth list](https://atmos.tools/cli/commands/auth/list): List all configured authentication providers and identities with their relationships and chains. - [atmos auth login](https://atmos.tools/cli/commands/auth/login): Authenticate to cloud providers using an identity defined in atmos.yaml. - [atmos auth logout](https://atmos.tools/cli/commands/auth/logout): Remove locally cached credentials and session data - [atmos auth shell](https://atmos.tools/cli/commands/auth/shell): Launch an interactive shell with authentication environment variables configured for the selected identity. - [atmos auth](https://atmos.tools/cli/commands/auth/usage): Atmos Authentication Commands - [atmos auth user](https://atmos.tools/cli/commands/auth/user/): Manage cloud provider user credentials in the local keychain. - [atmos auth user configure](https://atmos.tools/cli/commands/auth/user/configure): Configure static AWS user credentials and store them securely in your system keychain. - [atmos auth validate](https://atmos.tools/cli/commands/auth/validate): Validate the authentication configuration in atmos.yaml for syntax and logical errors. - [atmos auth whoami](https://atmos.tools/cli/commands/auth/whoami): Show current authentication status for the selected identity. - [atmos aws compliance](https://atmos.tools/cli/commands/aws/compliance/): AWS compliance commands for generating posture reports against industry frameworks - [atmos aws compliance report](https://atmos.tools/cli/commands/aws/compliance/report): Generate compliance posture reports against industry frameworks like CIS AWS, PCI DSS, SOC2, HIPAA, and NIST - [atmos aws ecr login](https://atmos.tools/cli/commands/aws/ecr-login): Login to AWS ECR registries using Atmos integrations or explicit registry URLs. - [atmos aws eks token](https://atmos.tools/cli/commands/aws/eks-token): Generate an EKS bearer token for kubectl using Atmos identities. - [atmos aws eks](https://atmos.tools/cli/commands/aws/eks/): AWS EKS commands for managing Elastic Kubernetes Service clusters - [atmos aws eks update-kubeconfig](https://atmos.tools/cli/commands/aws/eks/update-kubeconfig): Use this command to download `kubeconfig` from an EKS cluster and saves it to a file. - [atmos aws security](https://atmos.tools/cli/commands/aws/security/): AWS security commands for analyzing findings and mapping them to Atmos components - [atmos aws security analyze](https://atmos.tools/cli/commands/aws/security/analyze): Analyze AWS security findings and map them to Atmos components and stacks with optional AI-powered remediation guidance - [atmos aws](https://atmos.tools/cli/commands/aws/usage): Atmos AWS Commands - [atmos azure acr login](https://atmos.tools/cli/commands/azure/acr-login): Login to Azure Container Registry using Atmos integrations or explicit registry login server URLs. - [atmos azure aks](https://atmos.tools/cli/commands/azure/aks/): Azure AKS commands for managing Azure Kubernetes Service clusters - [atmos azure aks update-kubeconfig](https://atmos.tools/cli/commands/azure/aks/update-kubeconfig): Download kubeconfig from an AKS cluster and save it to a file. - [atmos azure aks token](https://atmos.tools/cli/commands/azure/azure-aks-token): Generate an AKS bearer token for kubectl using Atmos identities. - [atmos azure](https://atmos.tools/cli/commands/azure/usage): Atmos Azure Commands - [atmos cast play](https://atmos.tools/cli/commands/cast/play): Play an asciicast recording in the terminal. - [atmos cast render](https://atmos.tools/cli/commands/cast/render): Render an asciicast recording to GIF, MP4, HTML, ASCII, PNG, or JPEG. - [atmos cast](https://atmos.tools/cli/commands/cast/usage): Play and render Atmos asciicast recordings. - [atmos ci](https://atmos.tools/cli/commands/ci/): CI/CD integration commands for GitHub Actions and other CI providers. - [atmos ci cache](https://atmos.tools/cli/commands/ci/cache/): Manage the CI build cache — restore and save the toolchain and other regenerable artifacts across CI jobs. - [atmos ci cache delete](https://atmos.tools/cli/commands/ci/cache/delete): Delete a CI cache entry by key. - [atmos ci cache list](https://atmos.tools/cli/commands/ci/cache/list): List CI cache entries. - [atmos ci cache paths](https://atmos.tools/cli/commands/ci/cache/paths): Print the cache key and paths for use with actions/cache. - [atmos ci cache restore](https://atmos.tools/cli/commands/ci/cache/restore): Restore the CI cache into the well-known cache directory. - [atmos ci cache save](https://atmos.tools/cli/commands/ci/cache/save): Save the well-known cache directory to the CI cache. - [atmos ci status](https://atmos.tools/cli/commands/ci/status): Show CI status for current branch, similar to gh pr status. - [atmos ci validate](https://atmos.tools/cli/commands/ci/validate): Validate GitHub Actions workflow files with the built-in actionlint integration. - [atmos completion](https://atmos.tools/cli/commands/completion): Use this command to generate completion scripts for `Bash`, `Zsh`, `Fish` and `PowerShell`. - [atmos composition](https://atmos.tools/cli/commands/composition/usage): List, validate, and operate first-class composition lifecycles. - [atmos config delete](https://atmos.tools/cli/commands/config/config-delete): Delete a value from atmos.yaml by dot-notation path. - [atmos config format](https://atmos.tools/cli/commands/config/config-format): Format the active atmos.yaml file. - [atmos config get](https://atmos.tools/cli/commands/config/config-get): Read a value from the effective Atmos configuration by dot-notation path. - [atmos config list](https://atmos.tools/cli/commands/config/config-list): List editable atmos.yaml setting paths. - [atmos config schema](https://atmos.tools/cli/commands/config/config-schema): Print the JSON Schema Atmos uses to validate atmos.yaml. - [atmos config set](https://atmos.tools/cli/commands/config/config-set): Set a value in atmos.yaml by dot-notation path while preserving comments, anchors, and templates. - [atmos config validate](https://atmos.tools/cli/commands/config/config-validate): Validate atmos.yaml against its JSON Schema. - [atmos config](https://atmos.tools/cli/commands/config/usage): Read and edit your atmos.yaml configuration using dot-notation paths while preserving comments, anchors, YAML functions, and templates. - [atmos container](https://atmos.tools/cli/commands/container/usage): Build, run, and operate persistent, stack-scoped container components. - [atmos describe affected](https://atmos.tools/cli/commands/describe/affected): This command produces a list of the affected Atmos components and stacks given two Git commits. - [atmos describe component](https://atmos.tools/cli/commands/describe/component): Use this command to describe the complete configuration for an Atmos component in an Atmos stack. - [atmos describe config](https://atmos.tools/cli/commands/describe/config): Use this command to show the final (deep-merged) CLI configuration of all `atmos.yaml` file(s). - [atmos describe dependents](https://atmos.tools/cli/commands/describe/dependents): This command produces a list of Atmos components in Atmos stacks that depend on the provided Atmos component. - [atmos describe edition](https://atmos.tools/cli/commands/describe/edition): Use this command to show the active edition pin and every default it rolls back. - [atmos describe locals](https://atmos.tools/cli/commands/describe/locals): Use this command to display the locals defined in Atmos stack manifests. - [atmos describe stacks](https://atmos.tools/cli/commands/describe/stacks): Use this command to show the fully deep-merged configuration for all stacks and the components in the stacks. - [atmos describe](https://atmos.tools/cli/commands/describe/usage): Describe Atmos Configurations - [atmos describe workflows](https://atmos.tools/cli/commands/describe/workflows): Use this command to show all configured Atmos workflows. - [atmos devcontainer](https://atmos.tools/cli/commands/devcontainer/): Manage development containers for Atmos workflows - [atmos devcontainer attach](https://atmos.tools/cli/commands/devcontainer/attach): Attach to a running devcontainer - [atmos devcontainer config](https://atmos.tools/cli/commands/devcontainer/config): Show devcontainer configuration - [atmos devcontainer exec](https://atmos.tools/cli/commands/devcontainer/exec): Execute a command in a running devcontainer - [atmos devcontainer list](https://atmos.tools/cli/commands/devcontainer/list): List available devcontainers - [atmos devcontainer logs](https://atmos.tools/cli/commands/devcontainer/logs): Show logs from a devcontainer - [atmos devcontainer rebuild](https://atmos.tools/cli/commands/devcontainer/rebuild): Rebuild a devcontainer from scratch - [atmos devcontainer remove](https://atmos.tools/cli/commands/devcontainer/remove): Remove a devcontainer - [atmos devcontainer shell](https://atmos.tools/cli/commands/devcontainer/shell): Launch a shell in a devcontainer - [atmos devcontainer start](https://atmos.tools/cli/commands/devcontainer/start): Start a devcontainer - [atmos devcontainer stop](https://atmos.tools/cli/commands/devcontainer/stop): Stop a running devcontainer - [atmos docs generate](https://atmos.tools/cli/commands/docs/generate): Generate documentation artifacts based on a named section under `docs.generate` in atmos.yaml - [atmos docs](https://atmos.tools/cli/commands/docs/usage): Use this command to open the Atmos docs - [atmos emulator down](https://atmos.tools/cli/commands/emulator/down): Stop and remove an emulator's container - [atmos emulator exec](https://atmos.tools/cli/commands/emulator/exec): Run a command in an emulator container - [atmos emulator list](https://atmos.tools/cli/commands/emulator/list): List emulators and their status in a clean table - [atmos emulator logs](https://atmos.tools/cli/commands/emulator/logs): Stream an emulator container's logs - [atmos emulator ps](https://atmos.tools/cli/commands/emulator/ps): List running emulators in a stack - [atmos emulator reset](https://atmos.tools/cli/commands/emulator/reset): Stop an emulator and wipe its persisted state - [atmos emulator up](https://atmos.tools/cli/commands/emulator/up): Start (or reuse) an emulator's long-running container - [atmos emulator](https://atmos.tools/cli/commands/emulator/usage): Manage cloud-API emulators (Floci, MiniStack, k3s, OpenBao) - [atmos env](https://atmos.tools/cli/commands/env): Output environment variables configured in atmos.yaml - [GKE kubeconfig authentication](https://atmos.tools/cli/commands/gcp/gke/): Provision a GKE kubeconfig from an Atmos-managed GCP identity. - [atmos gcp gke token](https://atmos.tools/cli/commands/gcp/gke/token): Emit a Kubernetes ExecCredential from an Atmos-managed GCP identity. - [atmos gcp](https://atmos.tools/cli/commands/gcp/usage): Native Atmos commands for Google Cloud authentication. - [atmos git clean](https://atmos.tools/cli/commands/git/clean): Remove managed Git repository workdirs safely. - [atmos git clone](https://atmos.tools/cli/commands/git/clone): Clone or reconcile a managed Git repository, an ad hoc URI, or the current CI repository. - [atmos git commit](https://atmos.tools/cli/commands/git/commit): Stage managed paths and create a commit in a managed Git repository. - [atmos git diff](https://atmos.tools/cli/commands/git/diff): Show changes between the working tree and HEAD in a managed Git repository. - [atmos git hooks](https://atmos.tools/cli/commands/git/hooks/): Manage local Git hooks that delegate to Atmos workflows and custom commands. - [atmos git hooks install](https://atmos.tools/cli/commands/git/hooks/install): Install local .git/hooks shims that delegate to atmos git hooks run. - [atmos git hooks run](https://atmos.tools/cli/commands/git/hooks/run): Run a local Git hook command configured under git.hooks. - [atmos git hooks uninstall](https://atmos.tools/cli/commands/git/hooks/uninstall): Remove Atmos-generated local Git hook shims. - [atmos git init](https://atmos.tools/cli/commands/git/init): Initialize a managed Git repository from scratch, optionally seeded from another repository. - [atmos git list](https://atmos.tools/cli/commands/git/list): List Git repositories configured under git.repositories. - [atmos git pull](https://atmos.tools/cli/commands/git/pull): Fast-forward pull a managed Git repository or a local path. - [atmos git push](https://atmos.tools/cli/commands/git/push): Push commits to a remote Git repository with bounded retry and no force push. - [atmos git status](https://atmos.tools/cli/commands/git/status): Show the working tree status of a managed Git repository or a local path. - [atmos git](https://atmos.tools/cli/commands/git/usage): GitOps enablement for Atmos — make automated Git commits easy, safe, and conventional both locally and in CI across every project. - [atmos helm apply](https://atmos.tools/cli/commands/helm/apply): Install or upgrade a Helm release (`helm upgrade --install`) for a component in a stack, using values resolved from your stack configuration. With `--target`, `apply` instead delivers th - [atmos helm delete](https://atmos.tools/cli/commands/helm/delete): Uninstall a Helm release (`helm uninstall`) for a component in a stack. Deleting a release that does not exist is a no-op. - [atmos helm deploy](https://atmos.tools/cli/commands/helm/deploy): Deploy a Helm release for a component in a stack. `deploy` is an alias for [`apply`](/cli/commands/helm/apply): it installs or upgrades the release (`helm upgrade --install`), or deliver - [atmos helm diff](https://atmos.tools/cli/commands/helm/diff): Show a real unified diff between the chart Atmos would render and a baseline — the currently deployed release, a local manifest file, or the manifests in your GitOps deployment repositor - [atmos helm plan](https://atmos.tools/cli/commands/helm/plan): Preview the changes a Helm apply would make. `plan` is an alias for [`diff`](/cli/commands/helm/diff): it renders the chart client-side and shows a unified diff against a baseline (the d - [atmos helm plugin](https://atmos.tools/cli/commands/helm/plugin): Install and list Helm CLI plugins (such as `helm-diff` and `helm-secrets`) in an Atmos-managed `HELM_PLUGINS` directory. Atmos installs the plugins declared by a component automatically - [atmos helm repo list](https://atmos.tools/cli/commands/helm/repo-list): List Helm repositories associated with native Helm components. - [atmos helm template](https://atmos.tools/cli/commands/helm/template): Render a Helm chart to Kubernetes manifests without touching a cluster. `template` resolves the stack's `values`, `values_files`, chart reference, and version, then renders the chart in- - [atmos helm](https://atmos.tools/cli/commands/helm/usage): Deploy Helm charts as first-class Atmos components — local charts, remote repository charts, and OCI charts — using the same stack-based workflow you use for Terraform and Kubernetes. At - [atmos helmfile generate varfile](https://atmos.tools/cli/commands/helmfile/generate-varfile): Use this command to generate a varfile for a `helmfile` component in a stack. - [atmos helmfile source](https://atmos.tools/cli/commands/helmfile/source/): Manage helmfile component sources with JIT vendoring - [atmos helmfile source delete](https://atmos.tools/cli/commands/helmfile/source/delete): Remove vendored source directory - [atmos helmfile source describe](https://atmos.tools/cli/commands/helmfile/source/describe): Show source configuration for a component - [atmos helmfile source list](https://atmos.tools/cli/commands/helmfile/source/list): List Helmfile components with source configuration - [atmos helmfile source pull](https://atmos.tools/cli/commands/helmfile/source/pull): Vendor component source from source configuration - [atmos helmfile template](https://atmos.tools/cli/commands/helmfile/template): Render all Helm releases defined in a Helmfile component to Kubernetes manifests by running `helmfile template` with the generated values file. The rendered manifests are written to stdo - [atmos helmfile](https://atmos.tools/cli/commands/helmfile/usage): Use these subcommands to run `helmfile` commands. - [atmos help](https://atmos.tools/cli/commands/help): - [atmos init](https://atmos.tools/cli/commands/init): Initialize a complete Atmos project from a built-in or catalog template. - [atmos kubernetes apply](https://atmos.tools/cli/commands/kubernetes/apply): Apply the Kubernetes objects for a stack-configured component to the target cluster. - [atmos kubernetes delete](https://atmos.tools/cli/commands/kubernetes/delete): Delete the Kubernetes objects managed by a stack-configured component from the target cluster. - [atmos kubernetes deploy](https://atmos.tools/cli/commands/kubernetes/deploy): Deploy a stack-configured Kubernetes component to the target cluster (workflow-friendly alias for apply). - [atmos kubernetes diff](https://atmos.tools/cli/commands/kubernetes/diff): Show what would change in the cluster for a stack-configured Kubernetes component using a server-side dry run. - [atmos kubernetes plan](https://atmos.tools/cli/commands/kubernetes/plan): Give Kubernetes components a Terraform-style preview step. `plan` shows what a stack-configured component would create or change before you approve the deployment workflow. - [atmos kubernetes render](https://atmos.tools/cli/commands/kubernetes/render): Render the final Kubernetes manifests for a stack-configured component without touching the cluster. - [atmos kubernetes](https://atmos.tools/cli/commands/kubernetes/usage): Render, validate, diff, plan, apply, deploy, and delete Kubernetes components in Atmos stacks. - [atmos kubernetes validate](https://atmos.tools/cli/commands/kubernetes/validate): Validate rendered Kubernetes manifests offline by default, with optional server-side dry-run checks. - [atmos list affected](https://atmos.tools/cli/commands/list/affected): Use this command to list affected components and stacks between Git commits in a table format - [atmos list components](https://atmos.tools/cli/commands/list/components): Use this command to list Atmos components - [atmos list dependencies](https://atmos.tools/cli/commands/list/dependencies): Use this command to visualize dependency relationships between Atmos components. - [atmos list editions](https://atmos.tools/cli/commands/list/editions): Use this command to list the journal of default changes between Atmos editions. - [atmos list instances](https://atmos.tools/cli/commands/list/list-instances): Use this command to list all Atmos component instances across stacks - [atmos list metadata](https://atmos.tools/cli/commands/list/list-metadata): Use this command to list component metadata across all stacks - [atmos list values](https://atmos.tools/cli/commands/list/list-values): Use this command to list component values across all stacks - [atmos list vars](https://atmos.tools/cli/commands/list/list-vars): Use this command to list component variables across all stacks - [atmos list vendor](https://atmos.tools/cli/commands/list/list-vendor): Use this command to list all vendored components and modules - [atmos list workflows](https://atmos.tools/cli/commands/list/list-workflows): Use this command to list all workflows defined in your Atmos project - [atmos list settings](https://atmos.tools/cli/commands/list/settings): Use this command to list component settings across all stacks - [atmos list sources](https://atmos.tools/cli/commands/list/sources): List all components with source configuration across all component types - [atmos list stacks](https://atmos.tools/cli/commands/list/stacks): Use this command to list all Stack configurations or stacks for a specified component - [atmos list themes](https://atmos.tools/cli/commands/list/themes): List available terminal themes for markdown rendering - [atmos list](https://atmos.tools/cli/commands/list/usage): List Atmos Stacks and Components - [atmos lsp start](https://atmos.tools/cli/commands/lsp/start): Start the Atmos LSP server for IDE integration - [atmos mcp add](https://atmos.tools/cli/commands/mcp/add): Add an MCP server to mcp.servers in atmos.yaml - [atmos mcp export](https://atmos.tools/cli/commands/mcp/export): Export .mcp.json from atmos.yaml MCP server configuration - [atmos mcp install](https://atmos.tools/cli/commands/mcp/install): Install configured MCP servers into MCP-capable AI clients - [atmos mcp list](https://atmos.tools/cli/commands/mcp/list): List configured external MCP servers - [atmos mcp remove](https://atmos.tools/cli/commands/mcp/remove): Remove an MCP server from mcp.servers in atmos.yaml - [atmos mcp restart](https://atmos.tools/cli/commands/mcp/restart): Restart an external MCP server - [atmos mcp start](https://atmos.tools/cli/commands/mcp/start): Start the Atmos MCP server for AI client integration - [atmos mcp status](https://atmos.tools/cli/commands/mcp/status): Show status of all configured MCP servers - [atmos mcp test](https://atmos.tools/cli/commands/mcp/test): Test connectivity to an external MCP server - [atmos mcp tools](https://atmos.tools/cli/commands/mcp/tools): List tools exposed by an external MCP server - [atmos mcp uninstall](https://atmos.tools/cli/commands/mcp/uninstall): Remove installed MCP servers from AI client config files - [atmos packer build](https://atmos.tools/cli/commands/packer/build): Packer - [atmos packer init](https://atmos.tools/cli/commands/packer/init): Packer - [atmos packer inspect](https://atmos.tools/cli/commands/packer/inspect): Packer - [atmos packer output](https://atmos.tools/cli/commands/packer/output): Packer - [atmos packer source](https://atmos.tools/cli/commands/packer/source/): Manage packer component sources with JIT vendoring - [atmos packer source delete](https://atmos.tools/cli/commands/packer/source/delete): Remove vendored source directory - [atmos packer source describe](https://atmos.tools/cli/commands/packer/source/describe): Show source configuration for a component - [atmos packer source list](https://atmos.tools/cli/commands/packer/source/list): List Packer components with source configuration - [atmos packer source pull](https://atmos.tools/cli/commands/packer/source/pull): Vendor component source from source configuration - [atmos packer](https://atmos.tools/cli/commands/packer/usage): Packer - [atmos packer validate](https://atmos.tools/cli/commands/packer/validate): Packer - [atmos packer version](https://atmos.tools/cli/commands/packer/version): Packer - [atmos pro commit](https://atmos.tools/cli/commands/pro/commit): Use this command to commit changes via the Atmos Pro GitHub App, ensuring commits trigger CI workflows. - [atmos pro lock](https://atmos.tools/cli/commands/pro/lock): Use this command to lock a stack in Atmos Pro so that it cannot be planned or applied by another process (pull request, CI/CD, etc.) - [atmos pro unlock](https://atmos.tools/cli/commands/pro/unlock): Use this command to unlock a stack in Atmos Pro that has previously been locked by the lock command. - [atmos pro](https://atmos.tools/cli/commands/pro/usage): Atmos Pro Commands - [atmos profile list](https://atmos.tools/cli/commands/profile/profile-list): List available configuration profiles - [atmos profile show](https://atmos.tools/cli/commands/profile/profile-show): Show detailed information about a configuration profile - [atmos profile](https://atmos.tools/cli/commands/profile/usage): Manage configuration profiles for environment-specific settings - [atmos sbom](https://atmos.tools/cli/commands/sbom/usage): Generate provenance and software bills of materials for Terraform dependency evidence managed by Atmos. - [atmos scaffold generate](https://atmos.tools/cli/commands/scaffold/generate): Generate or update files from an AtmosScaffoldConfig template. - [atmos scaffold list](https://atmos.tools/cli/commands/scaffold/list): List available scaffold templates configured in atmos.yaml. - [atmos scaffold](https://atmos.tools/cli/commands/scaffold/usage): Generate, validate, and update template-driven boilerplate with versioned Atmos scaffold manifests. - [atmos scaffold validate](https://atmos.tools/cli/commands/scaffold/validate): Validate versioned AtmosScaffoldConfig template manifests before generation. - [atmos secret delete](https://atmos.tools/cli/commands/secret/delete): Remove a declared secret's value from its backend, with a confirmation prompt. - [atmos secret exec](https://atmos.tools/cli/commands/secret/exec): Run a command with a component's declared secrets injected as environment variables. - [atmos secret get](https://atmos.tools/cli/commands/secret/get): Retrieve a declared secret's value, optionally extracting a nested field with a YQ path. - [atmos secret import](https://atmos.tools/cli/commands/secret/import): Bring existing secret values under management — from a file, or from an existing store coordinate. - [atmos secret init](https://atmos.tools/cli/commands/secret/init): Provision declared secrets for a stack and component, prompting for any that are missing. - [atmos secret keygen](https://atmos.tools/cli/commands/secret/keygen): Generate an age key for a SOPS-backed secrets vault, in-process, with no manual age-keygen. - [atmos secret list](https://atmos.tools/cli/commands/secret/list): List declared secrets for a stack and component along with their initialization status. - [atmos secret pull](https://atmos.tools/cli/commands/secret/pull): Download initialized declared secrets to a local .env or JSON file for development. - [atmos secret push](https://atmos.tools/cli/commands/secret/push): Upload secret values from a local file, failing if any key is not declared. - [atmos secret set](https://atmos.tools/cli/commands/secret/set): Set a declared secret's value from an argument, standard input, or an interactive prompt. - [atmos secret shell](https://atmos.tools/cli/commands/secret/shell): Launch an interactive shell with a component's declared secrets in the environment. - [atmos secret](https://atmos.tools/cli/commands/secret/usage): Declare, provision, and resolve secrets backed by cloud secret stores or SOPS-encrypted files. - [atmos secret validate](https://atmos.tools/cli/commands/secret/validate): Validate that every required declared secret is initialized in its backend. - [atmos stack config](https://atmos.tools/cli/commands/stack/config/): Read, edit, and list component config in stack manifests — the canonical CRUD+list interface for stack component config. - [atmos stack config delete](https://atmos.tools/cli/commands/stack/config/delete): Delete a component-relative value from the stack manifest that defines it. - [atmos stack config format](https://atmos.tools/cli/commands/stack/config/format): Format the manifest files that define a stack component. - [atmos stack config get](https://atmos.tools/cli/commands/stack/config/get): Read a component-relative value from a stack and show which manifest defines it. - [atmos stack config list](https://atmos.tools/cli/commands/stack/config/list): List editable component config paths for a stack. - [atmos stack config set](https://atmos.tools/cli/commands/stack/config/set): Set a component-relative value in the stack manifest that defines it, preserving comments, anchors, and templates. - [atmos stack delete](https://atmos.tools/cli/commands/stack/stack-delete): Delete a component-relative value from the stack manifest that defines it. - [atmos stack format](https://atmos.tools/cli/commands/stack/stack-format): Format the manifest files that define a stack component. - [atmos stack get](https://atmos.tools/cli/commands/stack/stack-get): Read a component-relative value from a stack and show which manifest defines it. - [atmos stack schema](https://atmos.tools/cli/commands/stack/stack-schema): Print the JSON Schema Atmos uses to validate stack manifests. - [atmos stack set](https://atmos.tools/cli/commands/stack/stack-set): Set a component-relative value in the stack manifest that defines it, preserving comments, anchors, and templates. - [atmos stack validate](https://atmos.tools/cli/commands/stack/stack-validate): Validate stack manifests against the atmos-manifest JSON Schema. - [atmos stack](https://atmos.tools/cli/commands/stack/usage): Read and edit component values in stack manifests using provenance to find the file that defines each value, preserving comments, anchors, YAML functions, and templates. - [atmos store delete](https://atmos.tools/cli/commands/store/delete): Remove a value from a store, with a confirmation prompt. - [atmos store get](https://atmos.tools/cli/commands/store/get): Retrieve a value from a store, scoped to the same stack and component it was set with. - [atmos store list](https://atmos.tools/cli/commands/store/list): List the store backends configured in atmos.yaml, or the key/value pairs stored inside one. - [atmos store set](https://atmos.tools/cli/commands/store/set): Write a value to a store from an argument, standard input, or an interactive prompt. - [atmos store](https://atmos.tools/cli/commands/store/usage): Read, write, delete, and list raw values in configured store backends. - [atmos support](https://atmos.tools/cli/commands/support): Show Atmos support options - [atmos terraform apply](https://atmos.tools/cli/commands/terraform/apply): Use this command to apply Terraform changes for an Atmos component in a stack. Supports both direct applies and applying from previously generated planfiles. - [atmos terraform cache](https://atmos.tools/cli/commands/terraform/cache/): Transparently cache Terraform/OpenTofu providers and modules, and manage the cache. - [atmos terraform cache delete](https://atmos.tools/cli/commands/terraform/cache/delete): Delete a specific cached object by its cache key. - [atmos terraform cache list](https://atmos.tools/cli/commands/terraform/cache/list): List cached Terraform providers and modules. - [atmos terraform cache mirror](https://atmos.tools/cli/commands/terraform/cache/mirror): Pre-seed the registry cache with providers for multiple platforms. - [atmos terraform cache prune](https://atmos.tools/cli/commands/terraform/cache/prune): Remove stale cached registry metadata. - [atmos terraform cache stats](https://atmos.tools/cli/commands/terraform/cache/stats): Show cache size, object count, and provider/module breakdown. - [atmos terraform cache trust](https://atmos.tools/cli/commands/terraform/cache/trust): Trust the registry cache proxy certificate in the OS trust store (required once on macOS and Windows). - [atmos terraform cache untrust](https://atmos.tools/cli/commands/terraform/cache/untrust): Remove the registry cache proxy certificate from the OS trust store. - [atmos terraform clean](https://atmos.tools/cli/commands/terraform/clean): Clean up Terraform files for an Atmos component in a stack - [atmos terraform console](https://atmos.tools/cli/commands/terraform/console): Use this command to open an interactive Terraform console for an Atmos component in a stack, with all component variables and configuration pre-loaded. - [atmos terraform deploy](https://atmos.tools/cli/commands/terraform/deploy): Use this command to deploy Terraform changes for an Atmos component in a stack with auto-approval. This combines plan and apply operations in a single command. - [atmos terraform destroy](https://atmos.tools/cli/commands/terraform/destroy): Use this command to destroy Terraform-managed infrastructure for an Atmos component in a stack. This operation removes all resources managed by the component. - [atmos terraform fmt](https://atmos.tools/cli/commands/terraform/fmt): Use this command to format Terraform HCL configuration files for an Atmos component to canonical format and style. - [atmos terraform force-unlock](https://atmos.tools/cli/commands/terraform/force-unlock): Use this command to manually unlock the Terraform state for an Atmos component in a stack when automatic unlocking fails. - [atmos terraform generate](https://atmos.tools/cli/commands/terraform/generate/): Generate Terraform backend configuration and variable files - [atmos terraform generate backend](https://atmos.tools/cli/commands/terraform/generate/backend): Use this command to generate a Terraform backend config file for an Atmos terraform component in a stack. - [atmos terraform generate backends](https://atmos.tools/cli/commands/terraform/generate/backends): Use this command to generate the Terraform backend config files for all Atmos terraform components in all stacks. - [atmos terraform generate files](https://atmos.tools/cli/commands/terraform/generate/files): Generate auxiliary configuration files for Terraform components - [atmos terraform generate planfile](https://atmos.tools/cli/commands/terraform/generate/planfile): Use this command to generate a Terraform planfile for an Atmos [component](/components) in a [stack](/stacks) and convert it to JSON or YAML format for review. - [atmos terraform generate varfile](https://atmos.tools/cli/commands/terraform/generate/varfile): Use this command to generate a `.tfvar.json` variable file for an Atmos [component](/components) in a [stack](/stacks) with all configured values. - [atmos terraform generate varfiles](https://atmos.tools/cli/commands/terraform/generate/varfiles): Use this command to generate the Terraform varfiles (`.tfvar`) for all Atmos terraform components in all stacks. - [atmos terraform get](https://atmos.tools/cli/commands/terraform/get): Use this command to download and update Terraform modules for an Atmos component. This ensures all module dependencies are available locally. - [atmos terraform graph](https://atmos.tools/cli/commands/terraform/graph): Use this command to generate a visual dependency graph for an Atmos component's Terraform resources in a specific stack. - [atmos terraform import](https://atmos.tools/cli/commands/terraform/import): Use this command to import existing infrastructure resources into the Terraform state for an Atmos component in a stack. - [atmos terraform init](https://atmos.tools/cli/commands/terraform/init): Use this command to initialize the Terraform working directory for an Atmos component in a stack. This prepares the component for other Terraform operations. - [atmos terraform lint](https://atmos.tools/cli/commands/terraform/lint): Lint Terraform components with TFLint - [atmos terraform login](https://atmos.tools/cli/commands/terraform/login): Use this command to authenticate with Terraform Cloud or Terraform Enterprise for an Atmos component in a stack. - [atmos terraform logout](https://atmos.tools/cli/commands/terraform/logout): Use this command to remove Terraform Cloud or Terraform Enterprise credentials for an Atmos component in a stack. - [atmos terraform metadata](https://atmos.tools/cli/commands/terraform/metadata): Use this command to retrieve Terraform metadata functions for an Atmos component in a stack. - [atmos terraform migrate](https://atmos.tools/cli/commands/terraform/migrate): Run Terraform state migrations with tfmigrate. - [atmos terraform migrate apply](https://atmos.tools/cli/commands/terraform/migrate-apply): Apply Terraform state migrations with tfmigrate. - [atmos terraform migrate list](https://atmos.tools/cli/commands/terraform/migrate-list): List Terraform component tfmigrate context and history settings. - [atmos terraform migrate plan](https://atmos.tools/cli/commands/terraform/migrate-plan): Preview Terraform state migrations with tfmigrate. - [atmos terraform modules](https://atmos.tools/cli/commands/terraform/modules): Use this command to list all Terraform modules used by an Atmos component in a stack. - [atmos terraform output](https://atmos.tools/cli/commands/terraform/output): Read Terraform output values for an Atmos component from the state file - [atmos terraform plan](https://atmos.tools/cli/commands/terraform/plan): Use this command to generate a Terraform execution plan for an Atmos component in a stack, showing what changes would be made to your infrastructure. - [atmos terraform plan-diff](https://atmos.tools/cli/commands/terraform/plan-diff): The `atmos terraform plan-diff` command compares two Terraform plans and shows the differences between them. - [atmos terraform planfile](https://atmos.tools/cli/commands/terraform/planfile/): Commands for managing Terraform planfiles across multiple storage backends. - [atmos terraform planfile delete](https://atmos.tools/cli/commands/terraform/planfile/delete): Delete Terraform plan files from the configured storage backend. - [atmos terraform planfile download](https://atmos.tools/cli/commands/terraform/planfile/download): Download a Terraform plan file from the configured storage backend. - [atmos terraform planfile list](https://atmos.tools/cli/commands/terraform/planfile/list): List Terraform plan files from the configured storage backend. - [atmos terraform planfile show](https://atmos.tools/cli/commands/terraform/planfile/show): Show metadata for a Terraform plan file from the configured storage backend. - [atmos terraform planfile upload](https://atmos.tools/cli/commands/terraform/planfile/upload): Upload a Terraform plan file to the configured storage backend. - [atmos terraform providers](https://atmos.tools/cli/commands/terraform/providers): Use this command to display provider requirements and configurations for an Atmos component's Terraform configuration in a stack. - [atmos terraform providers](https://atmos.tools/cli/commands/terraform/providers/): Display provider requirements and configurations for an Atmos component's Terraform configuration in a stack. - [atmos terraform providers lock](https://atmos.tools/cli/commands/terraform/providers/lock): Write out dependency locks for the configured providers. - [atmos terraform providers mirror](https://atmos.tools/cli/commands/terraform/providers/mirror): Save local copies of all required provider plugins. - [atmos terraform providers schema](https://atmos.tools/cli/commands/terraform/providers/schema): Show schemas for the providers used in the configuration. - [atmos terraform refresh](https://atmos.tools/cli/commands/terraform/refresh): Use this command to refresh the Terraform state for an Atmos component in a stack, updating it to match the current remote infrastructure. - [atmos terraform shell](https://atmos.tools/cli/commands/terraform/shell): This command starts a new `SHELL` configured with the environment for an Atmos component in a stack to allow execution of all native terraform commands inside the shell without using any atmos-specific arguments and flags. This may by helpful to debug a component without going through Atmos. - [atmos terraform show](https://atmos.tools/cli/commands/terraform/show): Use this command to display human-readable output from the Terraform state or planfile for an Atmos component in a stack. - [atmos terraform source](https://atmos.tools/cli/commands/terraform/source/): Manage terraform component sources with JIT vendoring - [atmos terraform source delete](https://atmos.tools/cli/commands/terraform/source/delete): Remove vendored source directory - [atmos terraform source describe](https://atmos.tools/cli/commands/terraform/source/describe): Show source configuration for a component - [atmos terraform source list](https://atmos.tools/cli/commands/terraform/source/list): List Terraform components with source configuration - [atmos terraform source pull](https://atmos.tools/cli/commands/terraform/source/pull): Vendor component source from source configuration - [atmos terraform state](https://atmos.tools/cli/commands/terraform/state): Use this command to manage the Terraform state for an Atmos component in a stack. Supports operations like list, move, pull, push, replace-provider, rm, and show. - [atmos terraform state](https://atmos.tools/cli/commands/terraform/state/): Manage the Terraform state for an Atmos component in a stack. Supports operations like list, move, pull, push, replace-provider, rm, and show. - [atmos terraform state list](https://atmos.tools/cli/commands/terraform/state/list): List resources in the Terraform state. - [atmos terraform state mv](https://atmos.tools/cli/commands/terraform/state/mv): Move an item in Terraform state. - [atmos terraform state pull](https://atmos.tools/cli/commands/terraform/state/pull): Pull current state and output to stdout. - [atmos terraform state push](https://atmos.tools/cli/commands/terraform/state/push): Update remote state from a local state file. - [atmos terraform state replace-provider](https://atmos.tools/cli/commands/terraform/state/replace-provider): Replace provider in the state. - [atmos terraform state rm](https://atmos.tools/cli/commands/terraform/state/rm): Remove instances from the Terraform state. - [atmos terraform state show](https://atmos.tools/cli/commands/terraform/state/show): Show a resource in the Terraform state. - [atmos terraform taint](https://atmos.tools/cli/commands/terraform/taint): Use this command to mark a Terraform resource for recreation in an Atmos component's next apply operation. Note: This command is deprecated in Terraform v1.0+. - [atmos terraform backend](https://atmos.tools/cli/commands/terraform/terraform-backend): Manage Terraform state backend infrastructure - [atmos terraform version](https://atmos.tools/cli/commands/terraform/terraform-version): Use this command to display the Terraform/OpenTofu version being used for an Atmos component in a stack. - [atmos terraform test](https://atmos.tools/cli/commands/terraform/test): Use this command to run Terraform tests for an Atmos component, validating the component's configuration and behavior. - [atmos terraform untaint](https://atmos.tools/cli/commands/terraform/untaint): Use this command to remove the tainted state from a Terraform resource in an Atmos component. Note: This command is deprecated in Terraform v1.0+. - [atmos terraform](https://atmos.tools/cli/commands/terraform/usage): Use these subcommands to interact with Terraform and OpenTofu. - [atmos terraform validate](https://atmos.tools/cli/commands/terraform/validate): Use this command to validate the Terraform HCL configuration files (`.tf` files) for an Atmos component in a stack, checking for syntax and consistency errors. This validates Terraform code, n - [atmos terraform workdir](https://atmos.tools/cli/commands/terraform/workdir/): Manage component workdirs for isolated Terraform execution - [atmos terraform workdir clean](https://atmos.tools/cli/commands/terraform/workdir/clean): Remove workdir(s) to free disk space or force regeneration. - [atmos terraform workdir describe](https://atmos.tools/cli/commands/terraform/workdir/describe): Output workdir configuration as a valid Atmos stack manifest snippet. - [atmos terraform workdir list](https://atmos.tools/cli/commands/terraform/workdir/list): List all workdirs in the project with their status and metadata. - [atmos terraform workdir show](https://atmos.tools/cli/commands/terraform/workdir/show): Display detailed information about a specific component's workdir. - [atmos terraform workspace](https://atmos.tools/cli/commands/terraform/workspace): This command calculates the `terraform` workspace for an Atmos component (from the context variables and stack config). It runs `terraform init -reconfigure` and selects the workspace by executing the `terraform workspace select` command. - [atmos terraform workspace](https://atmos.tools/cli/commands/terraform/workspace/): This command calculates the `terraform` workspace for an Atmos component (from the context variables and stack config). It runs `terraform init -reconfigure` and selects the workspace by executing the `terraform workspace select` command. - [atmos terraform workspace delete](https://atmos.tools/cli/commands/terraform/workspace/delete): Delete a Terraform workspace. - [atmos terraform workspace list](https://atmos.tools/cli/commands/terraform/workspace/list): List Terraform workspaces. - [atmos terraform workspace new](https://atmos.tools/cli/commands/terraform/workspace/new): Create a new Terraform workspace. - [atmos terraform workspace select](https://atmos.tools/cli/commands/terraform/workspace/select): Select a Terraform workspace. - [atmos terraform workspace show](https://atmos.tools/cli/commands/terraform/workspace/show): Show the name of the current Terraform workspace. - [Browse Themes](https://atmos.tools/cli/commands/theme/browse): Browse and search available terminal themes - [atmos theme list](https://atmos.tools/cli/commands/theme/list): List available terminal themes for Atmos CLI - [atmos theme show](https://atmos.tools/cli/commands/theme/show): Show details and preview of a specific terminal theme - [atmos theme](https://atmos.tools/cli/commands/theme/usage): Manage terminal themes for Atmos CLI - [atmos toolchain add](https://atmos.tools/cli/commands/toolchain/add): Add tool dependencies to your .tool-versions file for version-controlled toolchain management. - [atmos toolchain clean](https://atmos.tools/cli/commands/toolchain/clean): Remove all installed CLI tools from your toolchain to free up disk space. - [atmos toolchain du](https://atmos.tools/cli/commands/toolchain/du): Display the total disk space consumed by all installed tools in your toolchain. - [atmos toolchain env](https://atmos.tools/cli/commands/toolchain/env): Export PATH environment variable for toolchain tools in shell-specific formats. - [atmos toolchain exec](https://atmos.tools/cli/commands/toolchain/exec): Execute toolchain-managed CLI tools directly without modifying your PATH. - [atmos toolchain get](https://atmos.tools/cli/commands/toolchain/get): Display version information for tools configured in your .tool-versions file. - [atmos toolchain info](https://atmos.tools/cli/commands/toolchain/info): Display detailed registry information about a toolchain tool. - [atmos toolchain install](https://atmos.tools/cli/commands/toolchain/install): Install CLI tools required by your Atmos components, commands, and workflows. - [atmos toolchain list](https://atmos.tools/cli/commands/toolchain/list): Display all CLI tools configured in your .tool-versions file with installation status. - [atmos toolchain lock](https://atmos.tools/cli/commands/toolchain/lock): Generate or refresh toolchain.lock.yaml without reinstalling tools. - [atmos toolchain path](https://atmos.tools/cli/commands/toolchain/path): Generate PATH environment variable entries for toolchain tools. - [atmos toolchain registry list](https://atmos.tools/cli/commands/toolchain/registry/registry-list): List all configured registries or browse tools available in a specific registry. - [atmos toolchain registry search](https://atmos.tools/cli/commands/toolchain/registry/registry-search): Search for tools across all configured registries by name, owner, or description. - [atmos toolchain registry](https://atmos.tools/cli/commands/toolchain/registry/usage): Manage and explore toolchain registries to discover CLI tools for your infrastructure workflows. - [atmos toolchain remove](https://atmos.tools/cli/commands/toolchain/remove): Remove tool entries from your .tool-versions file when they are no longer needed. - [atmos toolchain search](https://atmos.tools/cli/commands/toolchain/search): Quick alias for searching tools across registries. - [atmos toolchain set](https://atmos.tools/cli/commands/toolchain/set): Set or update the default version for a tool in your toolchain configuration. - [atmos toolchain uninstall](https://atmos.tools/cli/commands/toolchain/uninstall): Uninstall specific tool versions or all tools from your local toolchain cache. - [atmos toolchain update](https://atmos.tools/cli/commands/toolchain/update): Update tools to their newest available version. - [atmos toolchain](https://atmos.tools/cli/commands/toolchain/usage): Manage toolchain dependencies for your Atmos components with native version control and Aqua registry integration. - [atmos toolchain which](https://atmos.tools/cli/commands/toolchain/which): Locate the exact file path of a toolchain-managed tool binary. - [atmos validate component](https://atmos.tools/cli/commands/validate/component): Use this command to validate an Atmos component in a stack using JSON Schema and OPA policies. - [atmos validate editorconfig](https://atmos.tools/cli/commands/validate/editorconfig): Use this command to validate the workdir of the Atmos project against the rules defined in the .editorconfig file. - [atmos validate schema](https://atmos.tools/cli/commands/validate/schema): Use this command to validate the schema of yaml files of the Atmos project against the rules defined in the schema/manifest file. - [atmos validate stacks](https://atmos.tools/cli/commands/validate/stacks): Use this command to validate all Stack configurations. - [atmos validate](https://atmos.tools/cli/commands/validate/usage): Validate Atmos Configurations - [atmos vendor config](https://atmos.tools/cli/commands/vendor/config/): Read, edit, and list raw vendor manifest config by dot-notation path — the canonical CRUD+list interface for vendor.yaml. - [atmos vendor config delete](https://atmos.tools/cli/commands/vendor/config/delete): Delete a raw value from vendor.yaml by dot-notation path. - [atmos vendor config format](https://atmos.tools/cli/commands/vendor/config/format): Format vendor manifest config files. - [atmos vendor config get](https://atmos.tools/cli/commands/vendor/config/get): Read a raw value from vendor.yaml by dot-notation path. - [atmos vendor config list](https://atmos.tools/cli/commands/vendor/config/list): List raw vendor manifest setting paths. - [atmos vendor config set](https://atmos.tools/cli/commands/vendor/config/set): Set a raw value in vendor.yaml by dot-notation path, preserving comments, anchors, and templates. - [atmos vendor pull](https://atmos.tools/cli/commands/vendor/pull): Use this command to pull sources and mixins from remote repositories for Terraform and Helmfile components and stacks. - [atmos vendor](https://atmos.tools/cli/commands/vendor/usage): Vendor Atmos Components and Stacks - [atmos vendor clean](https://atmos.tools/cli/commands/vendor/vendor-clean): Remove lock-owned vendored files, refusing to delete files modified since they were vendored. - [atmos vendor diff](https://atmos.tools/cli/commands/vendor/vendor-diff): Show the Git diff between two versions of a vendored component without a local checkout. - [atmos vendor get](https://atmos.tools/cli/commands/vendor/vendor-get): Read the pinned version of a vendored component from vendor.yaml. - [atmos vendor set](https://atmos.tools/cli/commands/vendor/vendor-set): Set the pinned version of a vendored component in vendor.yaml, preserving comments, anchors, and templates. - [atmos vendor update](https://atmos.tools/cli/commands/vendor/vendor-update): Update vendored component versions to the latest allowed release, preserving comments, anchors, and templates. - [atmos vendor verify](https://atmos.tools/cli/commands/vendor/vendor-verify): Verify vendored files match vendor.lock.yaml, reporting drift for CI. - [atmos version install](https://atmos.tools/cli/commands/version/install): Install a specific version of Atmos - [atmos version list](https://atmos.tools/cli/commands/version/list): List Atmos releases or locally installed versions - [atmos version show](https://atmos.tools/cli/commands/version/show): Display detailed information about a specific Atmos release - [atmos version track](https://atmos.tools/cli/commands/version/track): Manage tracked software versions with the Atmos Version Tracker. - [atmos version track add](https://atmos.tools/cli/commands/version/track/add): Add a dependency entry to atmos.yaml. - [atmos version track apply](https://atmos.tools/cli/commands/version/track/apply): Rewrite version-managed files from the lock file. - [atmos version track diff](https://atmos.tools/cli/commands/version/track/diff): Show unlocked entries and policy-eligible updates. - [atmos version track get](https://atmos.tools/cli/commands/version/track/get): Get the effective value of a dependency entry, or a single field of it. - [atmos version track list](https://atmos.tools/cli/commands/version/track/list): List configured version tracks as a dependency x track version matrix. - [atmos version track lock](https://atmos.tools/cli/commands/version/track/lock): Resolve desired versions and write the lock file. - [atmos version track remove](https://atmos.tools/cli/commands/version/track/remove): Remove a dependency entry from atmos.yaml. - [atmos version track set](https://atmos.tools/cli/commands/version/track/set): Update fields of a dependency entry in atmos.yaml. - [atmos version track show](https://atmos.tools/cli/commands/version/track/show): Show effective entries of a version track. - [atmos version track status](https://atmos.tools/cli/commands/version/track/status): Show lock and update status for a version track. - [atmos version track update](https://atmos.tools/cli/commands/version/track/update): Update locked versions within the update policy. - [atmos version track verify](https://atmos.tools/cli/commands/version/track/verify): Verify that a version track is locked, current, and applied. - [atmos version uninstall](https://atmos.tools/cli/commands/version/uninstall): Uninstall a specific version of Atmos - [atmos version](https://atmos.tools/cli/commands/version/usage): Use this command to get the Atmos CLI version - [atmos workflow](https://atmos.tools/cli/commands/workflow): Use this command to perform sequential execution of `atmos`, `shell`, and `script` commands defined as workflow steps. - [Configuration Overview](https://atmos.tools/cli/configuration-overview): Introduction to the types of configuration in Atmos - [CLI Configuration](https://atmos.tools/cli/configuration/): Use the `atmos.yaml` configuration file to control the behavior of the Atmos CLI. - [AI Configuration](https://atmos.tools/cli/configuration/ai/): Configure the Atmos AI assistant in your `atmos.yaml` with providers, skills, tools, and sessions. - [Project Instructions](https://atmos.tools/cli/configuration/ai/instructions): Configure project-specific AI instructions in the `ai.instructions` section of your `atmos.yaml`. - [AI Providers](https://atmos.tools/cli/configuration/ai/providers): Configure AI providers in the `ai.providers` section of your `atmos.yaml`. - [AI Sessions](https://atmos.tools/cli/configuration/ai/sessions): Configure AI session persistence in the `ai.sessions` section of your `atmos.yaml`. - [AI Skills](https://atmos.tools/cli/configuration/ai/skills): Configure custom AI skills in the `ai.skills` section of your `atmos.yaml`. - [AI Tools](https://atmos.tools/cli/configuration/ai/tools): Configure AI tool execution and permissions in the `ai.tools` section of your `atmos.yaml`. - [Aliases](https://atmos.tools/cli/configuration/aliases): Create shortcut names for Atmos CLI commands using aliases. - [Authentication](https://atmos.tools/cli/configuration/auth/): Configure cloud provider authentication in your `atmos.yaml` with providers, identities, and credential storage. - [Identities](https://atmos.tools/cli/configuration/auth/identities): Configure authentication identities for AWS, Azure, and GCP in your `atmos.yaml`. - [Keyring](https://atmos.tools/cli/configuration/auth/keyring): Configure credential storage backends (system keyring, file, or memory) in your `atmos.yaml`. - [Auth Logs](https://atmos.tools/cli/configuration/auth/logs): Configure auth-specific logging in your `atmos.yaml` for debugging authentication issues. - [Providers](https://atmos.tools/cli/configuration/auth/providers): Configure authentication providers for AWS, Azure, and GCP in your `atmos.yaml`. - [Required](https://atmos.tools/cli/configuration/auth/required): Mark identities as required for automatic authentication in multi-account Terraform components. - [AWS Configuration](https://atmos.tools/cli/configuration/aws/): Configure AWS-specific features in your `atmos.yaml`. - [Security Configuration](https://atmos.tools/cli/configuration/aws/security): Configure AWS security scanning sources, severity filters, tag mapping, and compliance frameworks. - [CI Configuration](https://atmos.tools/cli/configuration/ci/): Configure native CI/CD integration for GitHub Actions and other CI providers - [CI Cache Configuration](https://atmos.tools/cli/configuration/ci/cache): Configure the CI build cache that restores and saves the toolchain and other regenerable artifacts across CI jobs. - [CI Status Checks](https://atmos.tools/cli/configuration/ci/checks): Configure commit status checks for CI pipelines - [CI Pull Request Comments](https://atmos.tools/cli/configuration/ci/comments): Configure GitHub pull-request comments with Terraform plan summaries - [CI Log Groups Configuration](https://atmos.tools/cli/configuration/ci/groups): Fold Atmos output into collapsible, named CI log groups — by step, by phase, or by whole invocation. - [CI Output Variables](https://atmos.tools/cli/configuration/ci/output): Configure CI output variables for downstream jobs - [CI Job Summaries](https://atmos.tools/cli/configuration/ci/summary): Configure rich job summaries for CI pipelines - [CI Templates](https://atmos.tools/cli/configuration/ci/templates): Customize CI job summary and PR comment templates - [Custom Commands](https://atmos.tools/cli/configuration/commands/): Use the `atmos.yaml` to configure any number of custom commands you want to add to the Atmos CLI. - [arguments](https://atmos.tools/cli/configuration/commands/arguments): The `arguments` field declares positional arguments for a custom command. Argument values are available to steps, env, and templates as `{{ .Arguments. }}`. - [command](https://atmos.tools/cli/configuration/commands/command): A `command` is one entry in the [`commands`](/cli/configuration/commands) list. It defines a custom `atmos` subcommand — its name, help text, the arguments and flags it accepts, the environmen - [commands](https://atmos.tools/cli/configuration/commands/commands): A command's `commands` field nests subcommands beneath it. Each entry has the same structure as a top-level [`command`](/cli/configuration/commands/command), so you can group related commands - [component](https://atmos.tools/cli/configuration/commands/component): The `component` field lets a custom command define its own component type beyond the built-in `terraform`, `helmfile`, `packer`, and `ansible` types. This brings Atmos's stack configuration sy - [dependencies](https://atmos.tools/cli/configuration/commands/dependencies): The `dependencies` field declares tool dependencies that Atmos installs automatically before a command runs, and the named commands and workflows that must complete first. This ensures any CLI - [env](https://atmos.tools/cli/configuration/commands/env): The `env` field exports environment variables to every step in a custom command. Values support Go templates, so they can be built from arguments, flags, and component configuration. - [flags](https://atmos.tools/cli/configuration/commands/flags): The `flags` field declares long and short flags for a custom command. Flag values are available to steps, env, and templates as `{{ .Flags. }}`. - [identity](https://atmos.tools/cli/configuration/commands/identity): The `identity` field authenticates an Atmos auth identity before a custom command runs. This is useful when commands need to interact with cloud resources that require specific credentials or - [steps](https://atmos.tools/cli/configuration/commands/steps): The `steps` field is the work a custom command performs. Custom commands run steps through the **same engine as [workflows](/workflows)** and support the **same step types** — from plain shell - [working_directory](https://atmos.tools/cli/configuration/commands/working-directory): The `working_directory` field controls where a custom command's steps execute, regardless of where `atmos` was invoked. This is useful when commands need to run from a specific location. Atmos follows the Semantic Versioning (SemVer) convention: major.minor.patch. - [Community](https://atmos.tools/community/): Community - [Office Hours](https://atmos.tools/community/office-hours): Office Hours with Cloud Posse - [#atmos](https://atmos.tools/community/slack): Cloud Posse's SweetOps Slack Community - [Atmos Components](https://atmos.tools/components): Components are opinionated building blocks of infrastructure as code that solve one specific problem or use-case. - [Using Ansible](https://atmos.tools/components/ansible): Run Ansible playbooks with the same stack-based configuration used for Terraform and Helmfile. Stack variables are automatically passed via --extra-vars. - [Component Library](https://atmos.tools/components/components-overview): Introduction to Atmos components - the building blocks of your infrastructure - [Using Containers](https://atmos.tools/components/container): Run persistent, stack-scoped container services with the same stack-based configuration used for Terraform and Helmfile. One component is one container, operated by labels. - [Using Custom Component Types](https://atmos.tools/components/custom): Bring any tool—AWS CDK, CloudFormation, Pulumi, Bicep, database migrations, and more—under the same stack-based configuration used for Terraform, Helmfile, and Packer. - [Using Emulators](https://atmos.tools/components/emulator): Run local cloud-API, Kubernetes, and backing-service emulators as stack-scoped components, so the rest of your stack runs offline with no cloud account. - [Using Helmfile](https://atmos.tools/components/helmfile): Atmos natively supports opinionated workflows for [Helmfile](https://github.com/helmfile/helmfile). Helmfile provides a declarative specification for deploying helm charts. - [Using Packer](https://atmos.tools/components/packer): Atmos natively supports opinionated workflows for [HashiCorp Packer](https://www.packer.io/). Packer automates the creation of machine images for multiple platforms, enabling you to build immu - [Terraform/OpenTofu](https://atmos.tools/components/terraform): Configure Terraform and OpenTofu components in Atmos stacks. - [State Backends](https://atmos.tools/components/terraform/backends): Configure Terraform/OpenTofu state backends. - [Brownfield Considerations](https://atmos.tools/components/terraform/brownfield): There are some considerations you should be aware of when adopting Atmos in a brownfield environment. Atmos works best when you adopt the [Atmos mindset](/learn/mindset). - [Terraform Planfiles](https://atmos.tools/components/terraform/planfiles): Atmos provides sophisticated planfile management for Terraform, enabling safe and predictable infrastructure changes through plan generation, storage, and application workflows. - [Provider Generation](https://atmos.tools/components/terraform/providers): Configure and generate Terraform providers. - [Terraform Remote State](https://atmos.tools/components/terraform/remote-state): Configure remote state access for reading other components' outputs. - [Root Modules](https://atmos.tools/components/terraform/root-modules): Learn why Atmos can change how you think about the Terraform modules that you use to build your infrastructure. - [Terraform Stack Configuration](https://atmos.tools/components/terraform/stack-config): Complete reference for configuring Terraform components in Atmos stacks - [Workspaces](https://atmos.tools/components/terraform/workspaces): Configure Terraform workspaces. - [Code of Conduct](https://atmos.tools/contribute/coc): As contributors and maintainers of the Atmos project by [Cloud Posse](https://cloudposse.com), we pledge to respect everyone who contributes by posting issues, updating documentation, submitti - [Contributing](https://atmos.tools/contribute/contributing): Contributing - [How to Contribute](https://atmos.tools/contribute/how-to-contribute): Thanks for the interest in contributing to the Atmos project! - [Deploy Components](https://atmos.tools/deploy/): Deploy components with a single command or in a CI/CD pipeline. - [GitHub Actions (Deprecated)](https://atmos.tools/deprecated/github-actions): Legacy Cloud Posse GitHub Actions for Atmos Terraform — deprecated in favor of native CI - [Affected Stacks (Deprecated)](https://atmos.tools/deprecated/github-actions/affected-stacks): Identify the affected stacks and components in a pull request - [Atmos Terraform Apply (Deprecated)](https://atmos.tools/deprecated/github-actions/atmos-terraform-apply): Run a `terraform apply` to provision changes - [Atmos Terraform Drift Detection (Deprecated)](https://atmos.tools/deprecated/github-actions/atmos-terraform-drift-detection): Identify drift and create GitHub Issues for remediation - [Atmos Terraform Drift Remediation (Deprecated)](https://atmos.tools/deprecated/github-actions/atmos-terraform-drift-remediation): Remediate Terraform drift using IssueOps - [Atmos Terraform Plan (Deprecated)](https://atmos.tools/deprecated/github-actions/atmos-terraform-plan): Run a `terraform plan` to understand the impact of changes - [Component Updater (Deprecated)](https://atmos.tools/deprecated/github-actions/component-updater): Legacy GitHub Action for updating vendored Atmos components - [Spacelift Integration (Deprecated)](https://atmos.tools/deprecated/spacelift): Legacy reference for the Atmos Spacelift integration. - [Describe Stacks](https://atmos.tools/describe/stacks): Describe stacks to view the fully deep-merged configuration - [Atmos Design Patterns](https://atmos.tools/design-patterns/): Techniques of Reusable Infrastructure Configuration - [Configuration Catalog Patterns](https://atmos.tools/design-patterns/component-catalog/): Configuration Catalog Patterns in Atmos - Your library of configuration defaults for organizing reusable component configurations - [Mixins](https://atmos.tools/design-patterns/component-catalog/mixins): Reusable configuration fragments for common settings - [Configuration Catalog Template](https://atmos.tools/design-patterns/component-catalog/template): Configuration Catalog Template Atmos Design Pattern - [Component Archetypes](https://atmos.tools/design-patterns/component-catalog/with-mixins): Pre-configured component variants for common use cases - [Component Overrides](https://atmos.tools/design-patterns/configuration-composition/component-overrides): Use overrides to apply configuration to a specific group of components without affecting others - [DRY Configuration with Locals](https://atmos.tools/design-patterns/configuration-composition/locals): Reduce repetition in stack files with locals - [Partial Component Configuration](https://atmos.tools/design-patterns/configuration-composition/partial-component-configuration): Partial Component Configuration Atmos Design Pattern - [Abstract Component](https://atmos.tools/design-patterns/inheritance-patterns/abstract-component): Abstract Component Atmos Design Pattern - [Component Inheritance](https://atmos.tools/design-patterns/inheritance-patterns/component-inheritance): Component Inheritance Atmos Design Pattern - [Multiple Component Instances](https://atmos.tools/design-patterns/inheritance-patterns/multiple-component-instances): Multiple Component Instances Atmos Design Pattern - [Multiple Inheritance](https://atmos.tools/design-patterns/inheritance-patterns/multiple-inheritance): Inherit from multiple abstract base components - [Inline Configuration](https://atmos.tools/design-patterns/inline-component-configuration): Inline Configuration Atmos Design Patterns for defining and customizing components directly in stack manifests - [Stack Organization Patterns](https://atmos.tools/design-patterns/stack-organization): Design patterns for structuring Atmos stacks - [Application SDLC Environments](https://atmos.tools/design-patterns/stack-organization/application-sdlc): Application SDLC Environments Atmos Design Pattern - [Basic Stack Organization](https://atmos.tools/design-patterns/stack-organization/basic-stack-organization): Simple dev/staging/prod stack organization pattern - [Blueprint Configuration](https://atmos.tools/design-patterns/stack-organization/blueprint-configuration): Blueprint Configuration Atmos Design Pattern - [The _defaults.yaml Design Pattern](https://atmos.tools/design-patterns/stack-organization/defaults-pattern): A naming convention for organizing hierarchical configuration defaults in Atmos - [Layered Stack Configuration](https://atmos.tools/design-patterns/stack-organization/layered-stack-configuration): Layered Stack Configuration Atmos Design Pattern - [Multi-Cloud Configuration](https://atmos.tools/design-patterns/stack-organization/multi-cloud-configuration): Multi-Cloud Configuration Atmos Design Pattern - [Multi-Region Configuration](https://atmos.tools/design-patterns/stack-organization/multi-region-configuration): Multi-Region Configuration Atmos Design Pattern - [Organizational Hierarchy Configuration](https://atmos.tools/design-patterns/stack-organization/organizational-hierarchy-configuration): Organizational Hierarchy Configuration Atmos Design Pattern - [Version Management Patterns](https://atmos.tools/design-patterns/version-management/): Version Management Patterns in Atmos - Strategies for Managing Component Versions - [Continuous Version Deployment](https://atmos.tools/design-patterns/version-management/continuous-version-deployment): Continuous Version Deployment - The recommended trunk-based deployment strategy with automated progressive rollout - [Folder-Based Versioning](https://atmos.tools/design-patterns/version-management/folder-based-versioning): Folder-Based Versioning - The foundational approach for organizing components with explicit folder structure - [Git Flow - Branches as Channels](https://atmos.tools/design-patterns/version-management/git-flow-branches-as-channels): Git Flow - The branch-based deployment strategy alternative to Continuous Version Deployment - [Release Tracks/Channels](https://atmos.tools/design-patterns/version-management/release-tracks-channels): Release Tracks/Channels - Organize components by named channels within Continuous Version Deployment - [Source-Based Version Pinning](https://atmos.tools/design-patterns/version-management/source-based-versioning): Source-Based Version Pinning - Native per-environment version control using the source field - [Strict Version Pinning](https://atmos.tools/design-patterns/version-management/strict-version-pinning): Strict Version Pinning - Organize components using explicit SemVer versions within Continuous Version Deployment - [Vendoring Component Versions](https://atmos.tools/design-patterns/version-management/vendoring-components): Vendoring Component Versions - A complementary technique for automating component version copying - [Versioning Schemes](https://atmos.tools/design-patterns/version-management/versioning-schemes): Common versioning schemes for naming component versions in Atmos - [Experimental Features](https://atmos.tools/experimental): Learn about Atmos experimental features, how they work, and how to provide feedback. - [Atmos FAQ](https://atmos.tools/faq): Find answers to the most common questions about Atmos, from basic concepts to advanced usage patterns. - [Atmos Features](https://atmos.tools/features): Atmos streamlines Terraform orchestration, environment, and configuration management, offering developers and DevOps a framework and a set of powerful tools to tackle deployment challenges. Recommended - [`!append` YAML Function](https://atmos.tools/functions/yaml/append): Append items to lists during configuration merging - [!aws.account_id](https://atmos.tools/functions/yaml/aws.account-id): Retrieve the AWS account ID of the current caller identity - [!aws.caller_identity_arn](https://atmos.tools/functions/yaml/aws.caller-identity-arn): Retrieve the ARN of the current AWS caller identity - [!aws.caller_identity_user_id](https://atmos.tools/functions/yaml/aws.caller-identity-user-id): Retrieve the unique user ID of the current AWS caller identity - [!aws.organization_id](https://atmos.tools/functions/yaml/aws.organization-id): Retrieve the AWS Organization ID of the current account - [!aws.region](https://atmos.tools/functions/yaml/aws.region): Retrieve the current AWS region from the SDK configuration - [!cwd](https://atmos.tools/functions/yaml/cwd): Get the current working directory - [!emulator](https://atmos.tools/functions/yaml/emulator): Retrieve connection information from a running Atmos emulator - [!env](https://atmos.tools/functions/yaml/env): Retrieve environment variables from stack manifests or OS environment and assign them to sections in Atmos stack manifests - [!exec](https://atmos.tools/functions/yaml/exec): Execute shell scripts and assign the results to the sections in Atmos stack manifests - [!git.branch](https://atmos.tools/functions/yaml/git.branch): Get the current branch name of the current Git repository - [!git.host](https://atmos.tools/functions/yaml/git.host): Get the host of the current Git repository - [!git.name](https://atmos.tools/functions/yaml/git.name): Get the bare repository name of the current Git repository - [!git.owner](https://atmos.tools/functions/yaml/git.owner): Get the owner/organization of the current Git repository - [!git.ref](https://atmos.tools/functions/yaml/git.ref): Get an immutable Git ref of the current repository, suitable for source pinning - [!git.repository](https://atmos.tools/functions/yaml/git.repository): Get the repository slug (owner/name) of the current Git repository - [!git.root](https://atmos.tools/functions/yaml/git.root): Get the root directory of the current Git repository - [!git.sha](https://atmos.tools/functions/yaml/git.sha): Get the current HEAD commit SHA of the current Git repository - [!git.url](https://atmos.tools/functions/yaml/git.url): Get the remote URL of the current Git repository - [!include](https://atmos.tools/functions/yaml/include): Download local or remote files from different sources, and insert their contents or specific values directly into sections of your stack manifests - [!include.raw](https://atmos.tools/functions/yaml/include.raw): Force inclusion of files as raw strings regardless of their extension or content - [!labels](https://atmos.tools/functions/yaml/labels): Retrieve the current component's own metadata.labels as a map - [!labels.keys](https://atmos.tools/functions/yaml/labels.keys): Retrieve the current component's own metadata.labels keys as a sorted list - [!labels.values](https://atmos.tools/functions/yaml/labels.values): Retrieve the current component's own metadata.labels values as a list, ordered by key - [!literal](https://atmos.tools/functions/yaml/literal): Preserve values exactly as written, bypassing all template processing - [!random](https://atmos.tools/functions/yaml/random): Generate a random integer within a specified range - [!repo-root](https://atmos.tools/functions/yaml/repo-root): Get the root directory of the Atmos repository - [!secret](https://atmos.tools/functions/yaml/secret): Resolve a declared secret from its configured backend for an Atmos component in a stack - [!store](https://atmos.tools/functions/yaml/store): Read a value from a store for an Atmos component in a stack - [!store.get](https://atmos.tools/functions/yaml/store.get): Retrieve arbitrary keys directly from a store - [!tags](https://atmos.tools/functions/yaml/tags): Retrieve the current component's own metadata.tags as a list - [!template](https://atmos.tools/functions/yaml/template): Handle outputs containing maps or lists returned from the atmos.Component template function - [!terraform.output](https://atmos.tools/functions/yaml/terraform.output): Read the remote state of any Atmos component from Terraform/OpenTofu outputs - [!terraform.state](https://atmos.tools/functions/yaml/terraform.state): The FASTEST way to retrieve Terraform outputs - reads directly from state backends without initializing Terraform or downloading providers - [!unset](https://atmos.tools/functions/yaml/unset): Delete/remove values from Atmos stack configurations - [!version](https://atmos.tools/functions/yaml/version): Resolve an Atmos-managed version from the active version track lock file. - [Programming Framework](https://atmos.tools/glossary/framework): Think of a programming framework like a toolkit or a set of building blocks for creating software. Just like how a carpenter uses specific tools and materials to build a house, programmers use framewo - [Using Profiles for Atmos Version Management](https://atmos.tools/howto/atmos-version-management): How to use Atmos profiles to manage different Atmos versions across environments - [Stack Catalogs](https://atmos.tools/howto/catalogs): Organize Stack configurations into catalogs for easy imports. - [Inherit Configurations in Atmos Stacks](https://atmos.tools/howto/inheritance): Inheritance lets components derive configuration from other components. A derived component inherits all settings from its base component and can override specific values. - [Manage Multiple Terraform/OpenTofu Versions](https://atmos.tools/howto/manage-terraform-versions): How to manage multiple versions of Terraform and OpenTofu using Atmos toolchain - [Stack Mixins](https://atmos.tools/howto/mixins): Advanced - [Using Geodesic with Atmos Devcontainers](https://atmos.tools/howto/using-geodesic): Run Geodesic toolbox using atmos devcontainer commands. - [Install Atmos](https://atmos.tools/install): - [Setup Atmos](https://atmos.tools/integrations/github-actions/setup-atmos): Install Atmos in your GitHub Action workflows - [Get Started with Atmos](https://atmos.tools/intro/): Atmos is a framework for Terraform that helps you manage configuration at scale. Define your infrastructure once, deploy it everywhere. - [The Terraform Maturity Journey](https://atmos.tools/intro/why-atmos/): Understanding the natural evolution of Terraform adoption and how Atmos helps - [Nirvana 💫](https://atmos.tools/intro/why-atmos/nirvana): Teams who adopt Atmos have total clarity of their infrastructure. - [Stage 0: ClickOps](https://atmos.tools/intro/why-atmos/stage-0): All infrastructure is manually provisioned using web interfaces. - [Stage 1: Introduction to Terraform](https://atmos.tools/intro/why-atmos/stage-1): Exploration into Terraform begins with a simple example. - [Stage 10: Terraform Bankruptcy 💥](https://atmos.tools/intro/why-atmos/stage-10): Teams start looking for alternatives out of frustration. - [Stage 2: The Monolithic Root Module](https://atmos.tools/intro/why-atmos/stage-2): Terraform code expands into a monolithic root module. - [Stage 3: Move Towards Modularization](https://atmos.tools/intro/why-atmos/stage-3): In-house modules are created to avoid code duplication. - [Stage 4: Adoption of Open Source Modules](https://atmos.tools/intro/why-atmos/stage-4): Open Source modules replace in-house modules. - [Stage 5: Refactor Root Modules](https://atmos.tools/intro/why-atmos/stage-5): Root modules are refactored into smaller, more manageable units. - [Stage 6: Optimize for DRY Configuration](https://atmos.tools/intro/why-atmos/stage-6): Configuration management moves to `.tfvar` files. - [Stage 7: Terraform Scripting](https://atmos.tools/intro/why-atmos/stage-7): Scripts automate terraform to make it easier. - [Stage 8: Team Challenges](https://atmos.tools/intro/why-atmos/stage-8): Team expands and begins to struggle with Terraform - [Stage 9: DIY CI/CD with Terraform](https://atmos.tools/intro/why-atmos/stage-9): Terraform is deployed with a CI/CD pipeline - [Core Concepts](https://atmos.tools/learn/concepts-overview): Understand the fundamental building blocks of Atmos - Components, Stacks, and Configuration - [Connecting Components](https://atmos.tools/learn/connecting-components): Share data between components using remote state - [Your First Stack](https://atmos.tools/learn/first-stack): Create your first Atmos stack with a simple, working example - [Import Basics](https://atmos.tools/learn/imports-basics): Reuse configuration across stacks with imports - [Inheritance Basics](https://atmos.tools/learn/inheritance-basics): Create component variations using inheritance - [Thinking Like Atmos](https://atmos.tools/learn/mindset): Atmos can change how you think about the Terraform code you write to build your infrastructure. - [What's Next](https://atmos.tools/learn/next-steps): Where to go after learning the basics - [Organizing Stacks](https://atmos.tools/learn/organizing-stacks): Structure your stacks for maintainability and scale - [Atmos Stacks](https://atmos.tools/learn/stacks): Use Stacks to configure Components for an environment - [Why Atmos?](https://atmos.tools/learn/why-atmos): Discover how Atmos helps teams manage complex Terraform infrastructure at scale - [YAML in Atmos](https://atmos.tools/learn/yaml): Understanding how Atmos uses YAML for configuration - [IDE Integration](https://atmos.tools/lsp/): IDE integration for Atmos using Language Server Protocol (LSP) - [LSP Client for AI Validation](https://atmos.tools/lsp/lsp-client): LSP client for Atmos AI to validate YAML, Terraform, and HCL files using external language servers - [Atmos LSP Server for IDE Integration](https://atmos.tools/lsp/lsp-server): Language Server Protocol (LSP) server that enables IDE integration for Atmos stack files with validation, autocomplete, and hover documentation - [MCP](https://atmos.tools/mcp): Atmos and the Model Context Protocol -- as a client connecting to external MCP servers, and as a server exposing Atmos's own tools - [Migrating from Native Terraform](https://atmos.tools/migration/native-terraform): How to migrate from vanilla Terraform to Atmos - [Migrating from Terraform Workspaces](https://atmos.tools/migration/terraform-workspaces): How to migrate from Terraform Workspaces to Atmos - [Migrating from Terragrunt](https://atmos.tools/migration/terragrunt): How to migrate from Terragrunt to Atmos - [Multi-Cloud](https://atmos.tools/multi-cloud): Atmos was designed from the ground up to be cloud agnostic. Multi-cloud integrations are community supported. - [Atmos Pro](https://atmos.tools/pro/): The control plane for coordinating infrastructure at scale across teams, repos, and organizations - [Setup Projects for Atmos](https://atmos.tools/projects/): Atmos is a framework, so we suggest some conventions for organizing your infrastructure using folders to separate configuration from components. This separation is key to making your component - [Folder Structure](https://atmos.tools/projects/layout): Recommended way to organize your Atmos stacks and components - [Configure Your Editor for Atmos](https://atmos.tools/projects/setup-editor): A properly configured editor can make working with Atmos configurations more intuitive and efficient. The right setup can improve readability, speed up your workflow, and even help you c - [Configure AI Assistants](https://atmos.tools/projects/setup-editor/ai-assistants): Configure Claude Code, Cursor, Windsurf, GitHub Copilot, Gemini CLI, OpenAI Codex, and other AI coding assistants to use Atmos agent skills. - [Quick Start Introduction](https://atmos.tools/quick-start): Atmos is a CLI and a powerful enterprise-grade workflow automation tool for DevOps. It's also a framework that prescribes patterns and best practices to structure and organize components and s - [Advanced Tutorial](https://atmos.tools/quick-start/advanced/): In about 30 minutes, deploy a real event-driven AWS backend entirely on your laptop — no cloud account, no credentials — and learn the Atmos patterns that matter most. - [Add Custom Commands](https://atmos.tools/quick-start/advanced/add-custom-commands): :::note Optional chapter This is an advanced extension point, not a required step — most people add custom commands only after running Atmos for a while and noticing a command they wish existed. ::: - [Configure Hooks](https://atmos.tools/quick-start/advanced/configure-hooks): Run automated actions at component lifecycle events — security scans after a plan, output publishing after an apply — with Atmos hooks. - [Configure the Project](https://atmos.tools/quick-start/advanced/configure-project): Lay out an Atmos monorepo and create a single atmos.yaml at the repo root that tells Atmos where your components and stacks live. - [Manage Secrets](https://atmos.tools/quick-start/advanced/configure-secrets): The `app-config` component needs two secrets: a third-party `API_KEY` and a structured `DB_CONFIG` (JSON) containing database credentials. Atmos manages these with a dedicated secrets workflow that ke - [Terraform State Backend](https://atmos.tools/quick-start/advanced/configure-terraform-backend): :::tip No real AWS account needed This example stores Terraform state in an **S3 backend** — the same backend you'd use in production — but runs it entirely against the local **AWS emulator**. Atmos * - [Validate Configurations](https://atmos.tools/quick-start/advanced/configure-validation): Lint every stack against the built-in manifest schema, then enforce your own rules on component configuration with JSON Schema and OPA policies. - [Create Atmos Stacks](https://atmos.tools/quick-start/advanced/create-atmos-stacks): In the previous steps, we configured the Terraform components and started the [local sandbox](/quick-start/advanced/start-sandbox). - [Automate Common Workflows](https://atmos.tools/quick-start/advanced/create-workflows): :::note Optional chapter You've already deployed the full backend. This chapter and the ones that follow are **optional** — reach for them when you want to package the commands your operators run ever - [Final Notes](https://atmos.tools/quick-start/advanced/final-notes): Atmos provides unlimited flexibility in defining and configuring stacks and components in the stacks. - [Install the Toolchain](https://atmos.tools/quick-start/advanced/install-toolchain): Let Atmos install and pin the exact tools your stacks need — OpenTofu and a security scanner — so everyone runs the same versions with no separate tool manager. - [Next Steps](https://atmos.tools/quick-start/advanced/next-steps): You have just learned the **essentials of Atmos**. - [Deploy Everything](https://atmos.tools/quick-start/advanced/provision): Having configured the Terraform components, the Atmos components catalog, all the mixins and defaults, and the Atmos top-level stacks, we can now deploy the backend. Everything runs against the [local - [Start the Local Sandbox](https://atmos.tools/quick-start/advanced/start-sandbox): This tutorial provisions **real Terraform resources** — a KMS key, an S3 bucket, a DynamoDB table, an SNS topic, an SQS queue, and SSM parameters — but it does so against a **local sandbox** running o - [Optional: Vendor Components](https://atmos.tools/quick-start/advanced/vendor-components): :::note Optional step This step is **not required** for the tutorial. The six components in this example live in the repo under `components/terraform/`, so there's nothing to vendor. This page is incl - [Simple Atmos Tutorial](https://atmos.tools/quick-start/simple/): Take 30 minutes to learn the most important Atmos concepts. - [Configure Atmos CLI](https://atmos.tools/quick-start/simple/configure-cli): The `atmos.yaml` configuration file controls the behavior of the `atmos` CLI and how Atmos will work with your project. - [Start Your Project](https://atmos.tools/quick-start/simple/configure-project): The folder structure for an Atmos project is designed to organize your infrastructure effectively on the file system. It separates configuration from code, ensuring your Terraform root modules - [Use Your Component in a Stack](https://atmos.tools/quick-start/simple/configure-stacks): [Atmos Stacks](/learn/stacks) are the configuration for your components. It's how you can combine multiple reusable, stateful components into your "Stack" that you depend on. - [Extra Credit!](https://atmos.tools/quick-start/simple/extra-credit/): Now we want to provide you with some bonus material because we didn’t want to overwhelm you when you were just getting started. These are common ways we use Atmos daily in the infrastructures - [Deploy Another App](https://atmos.tools/quick-start/simple/extra-credit/add-another-component): Provision multiple components in the same stack - [Add Custom Commands](https://atmos.tools/quick-start/simple/extra-credit/add-custom-commands): Extend Atmos with your own custom CLI commands - [Automate Common Workflows](https://atmos.tools/quick-start/simple/extra-credit/create-workflows): Automate your repetitive tasks with workflows - [Vendor Dependencies](https://atmos.tools/quick-start/simple/extra-credit/vendor-components): Learn how to vendor components from remote sources - [Deploy Everything](https://atmos.tools/quick-start/simple/provision): After you've written your components and configured your stacks, now we're ready to deploy them! - [Where to go from here...](https://atmos.tools/quick-start/simple/summary): Atmos provides unlimited flexibility in defining and configuring stacks and components in the stacks. - [Write Some Components](https://atmos.tools/quick-start/simple/write-components): When you [design cloud architectures with Atmos](/learn/mindset), you will first break them apart into pieces called [components](/components). Then, you will implement [Terraform "root module - [Reference](https://atmos.tools/reference/): Reference - [Atmos Alternatives & Inspirations](https://atmos.tools/reference/alternatives): To better understand where Atmos fits in, it may be helpful to understand some of the tooling that has inspired its design or serve as possible alternatives to its approach. - [Slides](https://atmos.tools/reference/slides): - [YAML Configuration Reference](https://atmos.tools/reference/yaml): Comprehensive guide to YAML in Atmos with best practices and common pitfalls - [Type-Aware Merging of YAML Functions](https://atmos.tools/reference/yaml-function-merging): How Atmos handles merging YAML functions with concrete values in the inheritance chain - [Slide Decks](https://atmos.tools/slides/): Browse available Atmos presentation slide decks. - [Scale Terraform Workflows with Atmos](https://atmos.tools/slides/atmos-intro): Learn how Atmos helps teams manage Terraform configurations at scale with hierarchical YAML, inheritance, and workflow automation. - [Atmos Roadmap 2025-2026](https://atmos.tools/slides/roadmap): Atmos product roadmap - from fragmented infrastructure tooling to unified orchestration. - [Stack Configuration](https://atmos.tools/stacks): Advanced stack configuration techniques - [Configure Authentication](https://atmos.tools/stacks/auth): Use the auth section to configure credential management for cloud providers and external services. - [Generate Terraform Backend](https://atmos.tools/stacks/backend): Use the backend section to generate Terraform backend configuration files for state storage. - [Configure Command Override](https://atmos.tools/stacks/command): Use the command setting to override the default executable for Terraform, Helmfile, Packer, or Ansible. - [Configuring Components in Stacks](https://atmos.tools/stacks/components/): Learn how to configure components in Atmos stack manifests, including metadata attributes and common configuration patterns. - [Ansible Components](https://atmos.tools/stacks/components/ansible): Configure Ansible components in your Atmos stack manifests for configuration management and automation. - [Configure Component Metadata](https://atmos.tools/stacks/components/component-metadata): Use the metadata section to control component behavior, inheritance, and deployment settings. - [Container Components](https://atmos.tools/stacks/components/container): Configure Container components in your Atmos stack manifests to build images and run persistent, stack-scoped container services. - [Emulator Components](https://atmos.tools/stacks/components/emulator): Configure Emulator components in your Atmos stack manifests to run local cloud-API, Kubernetes, and backing-service emulators. - [Helm Components](https://atmos.tools/stacks/components/helm): Configure native Helm components in Atmos stack manifests. - [Helmfile Components](https://atmos.tools/stacks/components/helmfile): Configure Helmfile components in your Atmos stack manifests for Kubernetes deployments. - [Kubernetes Components](https://atmos.tools/stacks/components/kubernetes): Configure Kubernetes-native components in Atmos stack manifests. - [Packer Components](https://atmos.tools/stacks/components/packer): Configure Packer components in your Atmos stack manifests for machine image building. - [Configure Component Provisioning](https://atmos.tools/stacks/components/provision): Configure automatic provisioning of state backends and isolated workdirs for components. - [Backend Provisioning](https://atmos.tools/stacks/components/provision/backend): Stack configuration for automatic Terraform state backend provisioning. - [Workdir Provisioning](https://atmos.tools/stacks/components/provision/workdir): Run each component instance in its own isolated working directory for safe concurrent execution. - [Terraform Components](https://atmos.tools/stacks/components/terraform): Configure Terraform components in your Atmos stack manifests. - [Terraform Backend Configuration](https://atmos.tools/stacks/components/terraform/backend): Configure Terraform state backends for components. - [Component Retry](https://atmos.tools/stacks/components/terraform/retry): Automatically retry transient Terraform errors with configurable backoff and pattern matching. - [Configure Dependencies](https://atmos.tools/stacks/dependencies/): Use the dependencies section to declare tool version requirements and component dependencies. - [Component Dependencies](https://atmos.tools/stacks/dependencies/components): Define dependencies between components, files, and folders to control execution order and detect affected components. - [Configure Environment Variables](https://atmos.tools/stacks/env): Use the env section to set environment variables for your Terraform, Helmfile, Packer, or Ansible components. - [Generate Terraform Files](https://atmos.tools/stacks/generate): Use the generate section to create auxiliary configuration files for Terraform components. - [Manage Lifecycle Events with Hooks](https://atmos.tools/stacks/hooks): Run scanners, cost estimators, custom commands, and store outputs at component lifecycle events. - [Import Stack Configurations](https://atmos.tools/stacks/imports): Imports let you split stack configurations across multiple files and reuse them. Each import is deep-merged on top of previous imports, building up the final configuration. - [Configure Locals](https://atmos.tools/stacks/locals): Use the locals section to define file-scoped temporary variables that reduce repetition and improve readability. - [Stack Names](https://atmos.tools/stacks/name): Use the name field to explicitly set a stack's logical name, or use name_template for programmatic naming. - [Override Configurations](https://atmos.tools/stacks/overrides): Use the 'Component Overrides' pattern to modify components' configuration and behavior in the current scope. - [Generate Terraform Providers](https://atmos.tools/stacks/providers): Use the providers section to generate Terraform provider configuration files for your components. - [Using Remote State](https://atmos.tools/stacks/remote-state): Redirect to remote state documentation - [Configure Settings](https://atmos.tools/stacks/settings/): Use the settings section to configure integrations, custom metadata, and component behavior. - [Migrate Legacy settings.depends_on](https://atmos.tools/stacks/settings/depends_on): Migrate legacy component dependency declarations to dependencies.components. - [Sharing State Between Components](https://atmos.tools/stacks/share-data): Share data between loosely-coupled components in Atmos - [Sharing State Between Components](https://atmos.tools/stacks/sharing-state): Share data between loosely-coupled components in Atmos - [Using the Remote State Module](https://atmos.tools/stacks/sharing-state/remote-state-module): Use native Terraform to read outputs from other components - [Using External Stores](https://atmos.tools/stacks/sharing-state/stores): Share data through external stores like SSM Parameter Store, AWS Secrets Manager, Artifactory, and more - [Using !terraform.output](https://atmos.tools/stacks/sharing-state/terraform-output): Read component outputs by executing terraform output command - [Using !terraform.state](https://atmos.tools/stacks/sharing-state/terraform-state): The fastest way to share state between components - reads directly from Terraform backends - [Configure Variables](https://atmos.tools/stacks/vars): Use the vars section to pass variables to your Terraform, Helmfile, Packer, or Ansible components. - [Stack Manifest Templating](https://atmos.tools/templates/): Advanced - [Template Data Sources](https://atmos.tools/templates/datasources): Advanced - [Glossary](https://atmos.tools/terms/): Here's a list of the terms, concepts and conventions used throughout the Atmos project. - [Abstract Component](https://atmos.tools/terms/abstract-component): An *Abstract Component* is a component baseline required to be inherited by a *Real Component* in order to be instantiated. - [Catalog](https://atmos.tools/terms/catalog): A *Catalog* is a collection of reusable configurations, such as Stack configurations. - [Component](https://atmos.tools/terms/component): *Components* are reusable building blocks of some tool, such as terraform "root" modules. - [Component Instance](https://atmos.tools/terms/component-instance): A *Component Instance* is a configuration of a real component in a parent stack that can be instantiated, such as deployed. - [Concrete Component](https://atmos.tools/terms/concrete-component): Also known as a *Real Component*. - [Environment](https://atmos.tools/terms/environment): An *Environment* is a location where resources are deployed, such as `us-east-1`. - [Imports](https://atmos.tools/terms/imports): *Imports* are a mechanism to include one configuration in another for the purpose of reducing duplication. - [Inheritance](https://atmos.tools/terms/inheritance): *Inheritance* is a mechanism to derive a configuration from a hierarchy of other configurations that share a set of attributes. - [Integration](https://atmos.tools/terms/integration): An *Integration* is a mechanism of working with other tools and APIs. - [Kubernetes Namespace](https://atmos.tools/terms/kubernetes-namespace): Frequently it will be represented by a variable named `kubernetes_namespace`; it should not be confused with what Atmos calls namespace. - [Library](https://atmos.tools/terms/library): A *Library* is a collection of "Components" that can be treated like reusable building blocks. - [Mixins](https://atmos.tools/terms/mixins): *Mixins* are a partial configuration that is imported for use by other stacks without having to be the parent stack. - [Multiple Inheritance](https://atmos.tools/terms/multiple-inheritance): *Multiple Inheritance* is a mechanism to inherit configurations from multiple sources. - [Namespace](https://atmos.tools/terms/namespace): A *Namespace* is a prefix for all resources in a Stack. - [Parent Stack](https://atmos.tools/terms/parent-stack): The *Parent Stack* configuration defines all components for an environment. - [Real Component](https://atmos.tools/terms/real-component): A *Real Component* is a component that is instantiated in a Parent Stack. - [Spacelift Stack](https://atmos.tools/terms/spacelift-stack): A Spacelift Stack is a Terraform root module. Atmos on the other hand treats a stack as a collection of Terraform root modules. - [Stack](https://atmos.tools/terms/stack): An Atmos Stack serves as a configuration blueprint that describes a cohesive collection of components, automating the deployment, management, and teardown of Terraform resources for uniform setups acr - [Stack Manifest](https://atmos.tools/terms/stack-manifest): Stack manifests are YAML files in which the configuration for all Atmos stacks and components are defined. - [Stage](https://atmos.tools/terms/stage): Atmos defines "Stage" as a classification for different lifecycles in infrastructure management, such as Development, Production, Staging, QA, etc. It is recommended to allocate at least one account p - [Tenant](https://atmos.tools/terms/tenant): A *Tenant* is a logical grouping of resources. In AWS, we use the Tenant to represent the Organizational Unit (OU). - [Terraform "Child Module"](https://atmos.tools/terms/terraform-child-module): Any Terraform module that is invoked by another module, distinguishing itself by not maintaining a separate Terraform state. These modules are integral components of larger infrastructure setups, desi - [Terralith](https://atmos.tools/terms/terralith): A monolithic Terraform "root module" is also known as a Terralith. It's characterized by an expansive, all-encompassing Terraform configuration that attempts to manage every aspect of the infrastructu - [Vendoring](https://atmos.tools/terms/vendoring): *Vendoring* is a mechanism of making a copy of 3rd-party components within your repository. - [Debugging](https://atmos.tools/troubleshoot/debugging): :::note TODO ::: - [Common Errors](https://atmos.tools/troubleshoot/errors): For organizations running Atmos at scale, consider enabling [Error Handling & Monitoring](/cli/configuration/errors) to track failures across your infrastructure pipelines with Sentry integration. - [Packer Troubleshooting](https://atmos.tools/troubleshoot/packer-troubleshooting): Common issues and solutions when using Atmos with Packer - [Performance Profiling](https://atmos.tools/troubleshoot/profiling): Profile and optimize Atmos performance using built-in heatmap visualization and pprof analysis tools. - [Tutorials](https://atmos.tools/tutorials/): Here are some lessons on how to implement Atmos in a project. - [Atmos component migration in YAML config](https://atmos.tools/tutorials/atmos-component-migrations-in-yaml): Learn how to migrate an Atmos component to a new name or to use the `metadata.inheritance`. - [Atmos Example Infrastructure](https://atmos.tools/tutorials/atmos-example-infra): Learn about the Example Infrastructure that Atmos shows how to configure and provision - [Getting Started with Atmos](https://atmos.tools/tutorials/atmos-getting-started): Learn what Atmos is and how you can start using it with stacks to simplify your DevOps Automation tasks. - [Azure Authentication](https://atmos.tools/tutorials/azure-authentication): Complete guide for authenticating to Azure using Atmos Auth with interactive browser flow, device code flow, OIDC, and service principals. - [Configuring Geodesic with Atmos Auth](https://atmos.tools/tutorials/configuring-geodesic): Guide for configuring Geodesic to work with Atmos Auth for AWS authentication. - [ECR Authentication](https://atmos.tools/tutorials/ecr-authentication): Complete guide for authenticating to AWS ECR using Atmos integrations for seamless container workflows. - [EKS Kubeconfig Authentication](https://atmos.tools/tutorials/eks-kubeconfig-authentication): Complete guide for authenticating to AWS EKS and generating kubeconfig using Atmos integrations. - [Your First Environment on AWS](https://atmos.tools/tutorials/first-aws-environment): Get your first AWS environment deployed using Atmos, Stacks, and Vendoring - [Migrating from Leapp](https://atmos.tools/tutorials/migrating-from-leapp): Guide for migrating from Leapp to Atmos Auth for AWS IAM Identity Center authentication. - [Unreleased Content](https://atmos.tools/unreleased): Documentation pages with content that has not yet been included in a formal release. - [Atmos Use-Cases](https://atmos.tools/use-cases): Atmos has proven time and again that it works great for these key use cases. Whether you're managing a handful of environments or hundreds, Atmos provides the structure and flexibility to scal - [EditorConfig Validation](https://atmos.tools/validation/editorconfig-validation): Use EditorConfig Checker to validate your configurations. - [JSON Schema Validation](https://atmos.tools/validation/json-schema): Use JSON Schema policies to validate Stacks and Component configurations. - [Open Policy Agent (OPA) Validation](https://atmos.tools/validation/opa): Use OPA policies to validate Stacks and Component configurations. - [Terraform Input Variables Validation](https://atmos.tools/validation/terraform-variables): Use OPA policies to validate Terraform input variables. - [Validating Stack Configurations](https://atmos.tools/validation/validating): Use JSON Schema, OPA policies, and EditorConfig Checker to validate Components. - [Vendoring](https://atmos.tools/vendor/): Use Atmos vendoring to make copies of 3rd-party components, stacks, and other artifacts in your own repo. - [Component Manifest (Legacy)](https://atmos.tools/vendor/component-manifest): Configure component-level vendoring with component.yaml (legacy approach). - [Mixins](https://atmos.tools/vendor/component-manifest/mixins): Configure mixins in component.yaml to overlay additional files on vendored components. - [Source](https://atmos.tools/vendor/component-manifest/source): Configure the source section in component.yaml for component vendoring. - [Imports](https://atmos.tools/vendor/config/imports): Configure hierarchical imports in vendor.yaml to split vendor manifests. - [Sources](https://atmos.tools/vendor/config/sources): Configure vendor sources in vendor.yaml to define components to vendor. - [Vendor URL Syntax](https://atmos.tools/vendor/url-syntax): Learn how to use URLs and paths in Atmos vendor manifests - [Vendor Configuration](https://atmos.tools/vendor/vendor-config): Configure vendoring with vendor.yaml manifest (recommended approach). - [workflows](https://atmos.tools/workflows): Atmos workflows are versioned runbooks for infrastructure operations. Use them to turn repeatable deployment, validation, maintenance, and release procedures into YAML that runs the same way o - [container](https://atmos.tools/workflows/container): With a `container` defined on a workflow, Atmos runs your `type: shell` steps inside a single persistent container for the duration of the workflow run, instead of on the host. Every step shar - [dependencies](https://atmos.tools/workflows/dependencies): The workflow-level `dependencies` field declares the tool versions a workflow requires, and the named commands and workflows that must complete before it runs, so Atmos can provision and order - [env](https://atmos.tools/workflows/env): The workflow-level `env` field defines environment variables available to every step in the workflow. - [output](https://atmos.tools/workflows/output): The workflow-level `output` field sets the default command output mode for all steps in the workflow. - [show](https://atmos.tools/workflows/show): The workflow-level `show` field turns on optional workflow display features, such as a header, the step count, and per-step flags. - [stack](https://atmos.tools/workflows/stack): The workflow-level `stack` field sets the default Atmos stack applied to every `type: atmos` step in the workflow. - [steps](https://atmos.tools/workflows/steps): The `steps` field is an ordered array of step objects. Atmos executes the steps in the order they appear. - [artifacts](https://atmos.tools/workflows/steps/artifacts): The step-level `artifacts` field declares the files a step is expected to produce. Pair it with [`inputs`](/workflows/steps/inputs) (the step's sources) — the two are separate, sibling fields, - [container](https://atmos.tools/workflows/steps/container): The step-level `container` field controls whether a single step runs inside the workflow's container sandbox or on the host. It is separate from the [`type: container`](/workflows/steps/type/c - [continue](https://atmos.tools/workflows/steps/continue): The step-level `continue` field forgives a step's own failure: later steps still run, and the workflow's overall exit status is unaffected — the same semantics as GitHub Actions' `continue-on- - [env](https://atmos.tools/workflows/steps/env): The step-level `env` field adds or overrides environment variables for a single step, taking precedence over the workflow-level [env](/workflows/env). - [identity](https://atmos.tools/workflows/steps/identity): The step-level `identity` field authenticates an Atmos auth identity before the step runs, so the step executes with the right cloud credentials. - [inputs](https://atmos.tools/workflows/steps/inputs): The step-level `inputs` field declares the files that determine a step's freshness, so Atmos can skip the step when nothing has changed since it last ran successfully. Pair it with [`artifacts - [interactive](https://atmos.tools/workflows/steps/interactive): The step-level `interactive` field attaches your terminal's stdin to a `type: shell` step, so the command can read input from you while it runs. - [output](https://atmos.tools/workflows/steps/output): The step-level `output` field overrides the workflow-level [output](/workflows/output) mode for a single step. - [outputs](https://atmos.tools/workflows/steps/outputs): The step-level `outputs` field declares named outputs derived from a step's result, so later steps and templates can reference structured values from it. - [preconditions](https://atmos.tools/workflows/steps/preconditions): The step-level `preconditions` field declares tools that must already be on `PATH` for a step's work to be considered already satisfied — a lighter, inline, single-step-skip variant of the [`r - [retry](https://atmos.tools/workflows/steps/retry): The step-level `retry` field automatically re-runs a failed step using a configurable backoff strategy, making workflows resilient to transient failures. - [show](https://atmos.tools/workflows/steps/show): The step-level `show` field overrides the workflow-level [display settings](/workflows/show) for a single step. - [tty](https://atmos.tools/workflows/steps/tty): The step-level `tty` field allocates a pseudo-terminal for a `type: shell` step, which terminal-native tools need to run correctly. - [type](https://atmos.tools/workflows/steps/type): The step `type` field selects how Atmos executes or renders a step. Step types expose the building blocks that power the Atmos CLI itself — command execution, interactive prompts, and rich ter - [alert](https://atmos.tools/workflows/steps/type/alert): The `alert` step type rings the terminal bell and optionally prints a message, a small building block for grabbing attention when a long-running custom command or workflow finishes or needs in - [archive](https://atmos.tools/workflows/steps/type/archive): The `archive` step type packages a directory or file into a zip, tar, or tgz archive — most commonly zipping a Lambda function's source into a deployable `handler.zip` before `terraform plan`/ - [atmos](https://atmos.tools/workflows/steps/type/atmos): The `atmos` step type runs an Atmos CLI command from inside a custom command or workflow, giving your automation direct access to the same stack-aware commands you run by hand. It is the defau - [cancel](https://atmos.tools/workflows/steps/type/cancel): The `cancel` step type stops and removes a [background container service](/workflows/steps/type/container#background-services) that an earlier step started with `background: true`. It gives yo - [cast](https://atmos.tools/workflows/steps/type/cast): The `cast` step type records deterministic terminal demos as asciicast files. It can run nested workflow steps, simulate typed commands, and render additional outputs from the same recording. - [choose](https://atmos.tools/workflows/steps/type/choose): The `choose` step type presents a single-select menu, letting your custom commands and workflows pick one value from a list of options at runtime. - [clear](https://atmos.tools/workflows/steps/type/clear): The `clear` step type clears the current terminal line, a building block for tidying up transient output before your custom command or workflow prints its next message. - [confirm](https://atmos.tools/workflows/steps/type/confirm): The `confirm` step type asks for a yes/no decision and stores the answer, adding an interactive guardrail to your custom commands and workflows before they take a risky action. - [container](https://atmos.tools/workflows/steps/type/container): The `container` step type builds, pushes, runs, and inspects containers through Docker or Podman, bringing the full container lifecycle into your custom commands and workflows without leaving - [emulator](https://atmos.tools/workflows/steps/type/emulator): The `emulator` step type starts, stops, or resets a local cloud [emulator](/stacks/components/emulator) component from a workflow, custom command, or lifecycle hook. It is the declarative way - [env](https://atmos.tools/workflows/steps/type/env): The `env` step type stores environment variables for the steps that follow, letting one step in a custom command or workflow compute values that later steps consume. Values always become avail - [exec](https://atmos.tools/workflows/steps/type/exec): The `exec` step type hands full process ownership to another command, so your workflows can launch terminal-native tools — interactive sessions, REPLs, or port-forwards — exactly as if you had - [exit](https://atmos.tools/workflows/steps/type/exit): The `exit` step type stops a custom command or workflow immediately with an exit code, giving you a clean, explicit way to halt automation after a guard or validation step fails. - [file](https://atmos.tools/workflows/steps/type/file): The `file` step type opens an interactive file picker, letting your custom commands and workflows prompt the user to choose a path instead of hard-coding it. - [filter](https://atmos.tools/workflows/steps/type/filter): The `filter` step type provides a searchable, optionally multi-select menu — the same fuzzy picker Atmos uses for interactive selection — so your custom commands and workflows can choose one o - [format](https://atmos.tools/workflows/steps/type/format): The `format` step type resolves templates and writes plain text to stdout — the building block for passing computed values into shell pipelines, CI logs, or later steps in your custom commands - [hint](https://atmos.tools/workflows/steps/type/hint): The `hint` step type displays a muted tip message with Atmos' lightbulb hint styling. - [http](https://atmos.tools/workflows/steps/type/http): The `http` step type performs an HTTP request from a workflow or custom command — call an API, notify a service, trigger a CI job, hit a deployment webhook, or poll a health endpoint. It suppo - [input](https://atmos.tools/workflows/steps/type/input): The `input` step type prompts for a single line of text using the same interactive prompt Atmos uses in its own CLI, so your custom commands and workflows can collect values from the user at r - [join](https://atmos.tools/workflows/steps/type/join): The `join` step type combines strings into a single value, a building block for assembling arguments, lists, or messages that later steps in your custom commands and workflows consume. The `junit` step ingests JUnit XML from a test runner, writes a CI step summary, and emits inline annotations for test failures when the CI provider supports them. - [linebreak](https://atmos.tools/workflows/steps/type/linebreak): The `linebreak` step type prints one or more blank lines, a simple building block for spacing out the human-facing output of your custom commands and workflows. - [log](https://atmos.tools/workflows/steps/type/log): The `log` step type emits a structured Atmos log message — the same leveled, field-aware logging Atmos uses internally — so your custom commands and workflows produce consistent, machine-reada - [markdown](https://atmos.tools/workflows/steps/type/markdown): The `markdown` step type renders Markdown with the Atmos UI theme, so your custom commands and workflows can print richly formatted summaries and instructions that match the rest of the Atmos - [matrix](https://atmos.tools/workflows/steps/type/matrix): The `matrix` step type expands a set of axes into a Cartesian product and runs the generated child steps concurrently through the same scheduler as [`parallel`](/workflows/steps/type/parallel) - [pager](https://atmos.tools/workflows/steps/type/pager): The `pager` step type opens content in a scrollable, full-screen pager, letting your custom commands and workflows present long output — changelogs, plans, or logs — without flooding the termi - [parallel](https://atmos.tools/workflows/steps/type/parallel): The `parallel` step type runs its child steps concurrently instead of one after another, with bounded concurrency, sibling dependencies, configurable failure behavior, and parent-owned output - [require](https://atmos.tools/workflows/steps/type/require): The `require` step type is a declarative preconditions gate. It verifies that the CLI tools a workflow or custom command depends on are executable and on `PATH`, and that required files and di - [say](https://atmos.tools/workflows/steps/type/say): The `say` step type speaks a message aloud using text-to-speech (TTS) — an audible cue, like [`alert`](/workflows/steps/type/alert), for when a long-running custom command or workflow finishes - [script](https://atmos.tools/workflows/steps/type/script): The `script` step type runs inline code with an explicit interpreter. Use it for a small, portable script body instead of encoding a heredoc in a shell command. - [shell](https://atmos.tools/workflows/steps/type/shell): The `shell` step type runs a shell command or script, letting your custom commands and workflows reach beyond Atmos to repository scripts, make targets, test commands, and any other tooling in - [sleep](https://atmos.tools/workflows/steps/type/sleep): The `sleep` step type pauses execution for a set duration, a simple building block for pacing custom commands and workflows around external systems that need time to settle. - [spin](https://atmos.tools/workflows/steps/type/spin): The `spin` step type runs a command behind an animated spinner — the same progress indicator Atmos uses for long-running operations — so your custom commands and workflows show clean, compact - [stage](https://atmos.tools/workflows/steps/type/stage): The `stage` step type prints numbered progress markers like `[Stage 1/3] Setup`, giving multi-step custom commands and workflows a clear sense of overall progress. - [store](https://atmos.tools/workflows/steps/type/store): The `store` step type writes a value to a configured [store](/cli/configuration/stores) backend. You can use this step in a workflow, a custom command, or a hook. For example, a workflow can b - [style](https://atmos.tools/workflows/steps/type/style): The `style` step type applies the Atmos terminal styling engine — colors, borders, padding, and text decoration — to any text, so your custom commands and workflows can highlight the output th - [table](https://atmos.tools/workflows/steps/type/table): The `table` step type renders tabular data with the same themed tables Atmos uses for its own list output, giving your custom commands and workflows a clean way to present structured results. - [title](https://atmos.tools/workflows/steps/type/title): The `title` step type sets the terminal window title, a small touch that lets long-running custom commands and workflows surface their current activity in the terminal tab. - [toast](https://atmos.tools/workflows/steps/type/toast): The `toast` step type displays a themed status message in success, info, warning, or error variants — the same status styling Atmos uses to report results across the CLI. - [wait](https://atmos.tools/workflows/steps/type/wait): The `wait` step type blocks the workflow until one or more named [background container services](/workflows/steps/type/container#background-services) are ready. The companion `wait-all` step t - [workdir](https://atmos.tools/workflows/steps/type/workdir): The `workdir` step provisions a mutable directory from a source. It replaces ad hoc shell sequences that create, delete, and copy scratch directories. - [write](https://atmos.tools/workflows/steps/type/write): The `write` step type opens a multi-line text editor prompt, giving your custom commands and workflows a place to collect longer free-form input such as release notes or commit messages. The step-level `working_directory` field overrides the workflow-level [working directory](/workflows/working-directory) for a single step. - [workflow](https://atmos.tools/workflows/workflow): A workflow is one named object at `workflows.` inside a [workflow manifest](/workflows). It owns workflow-level defaults and the ordered `steps` array Atmos runs for that workflow. The workflow-level `working_directory` field sets the default directory in which workflow steps run.