Atmos Updates

When a CLI needs you to open a page in a browser, it usually prints a URL and leaves the rest to you:

Publishing a container port usually exposes it on every network interface of the host. For a local database, an admin portal, or a cloud emulator, that means anything on the same network can reach a service that was only ever meant for your own machine. Container port mappings in Atmos now accept an IP:port string in host, so you can keep a published port on loopback, or on any single interface you choose.

A custom command that starts a local dashboard usually ends by opening it. Doing that portably has meant

When a pull request plans changes across many components, you need to see what will change, which plans

Structured secrets rarely agree on a single field name, and an ambient Vault token can silently cross an authentication boundary. That combination forces teams to reshape secret documents or wrap Atmos just to pass one short-lived credential into another identity.

Copying the same resource tags into every component makes ownership changes tedious and lets environments drift.

Tool aliases can come from built-in defaults or your project's configuration, making it difficult to see which target a short name selects. The toolchain aliases command lists the effective mappings in one place.

Building and verifying rarely downloaded binaries makes everyone wait longer for Atmos releases. We're retiring prebuilt downloads for Linux 386, Linux 32-bit ARM, and FreeBSD on amd64 and arm64 to reduce that overhead. Users on those platforms should install Atmos with Go, which builds it locally.

Tools often need API tokens from a secret store as environment variables. Copying those values into shell profiles duplicates credentials and makes rotation harder. The official auth-secrets plugin lets an Atmos identity read the configured store and select exactly which values a command receives.

Trying a different Terraform binary or a local wrapper should not require changing shared stack configuration. The component command families now accept a consistent --command flag for a single invocation, with explicit precedence over configured executables.

Shared authentication configuration can leave account and role values for stacks to supply. Validating only the global configuration rejects those incomplete definitions before their component overrides are considered. The auth validation command can now check the merged configuration for a selected stack or component.

Infrastructure written with AWS CDK or CDK Terrain needs a synthesis step before it can be

Replacing legacy naming patterns can accidentally select a different Terraform workspace, while a copied schema can reject configuration supported by your installed Atmos version. The Atmos Doctor command now checks naming migrations before applying them and identifies local Atmos schema overrides for review.

Reusing existing Rego checks should not require a separate plan wrapper. Atmos policies now support

A misspelled lifecycle event can silently prevent a security check or output sync

Keeping a terminal demo current means more than recording it again. You want to know that the commands still work, the output shows what you intended, and someone else can reproduce the result. The Starlark cast recorder lets you express that intent in a small script: commands, narration, and checks together, with functions and shared settings you can reuse across demos.

We published incorrect artifacts in the 1.233.0 and 1.233.1 releases.

Gomplate's experimental functions are now available in Atmos stack manifests.

The templates.settings.delimiters setting changes the delimiters that Atmos

A CI job fails, and the run page says only "Process completed with exit code 1." To learn why, you open the job,

Plan in one stage, apply in another: that is the whole point of saving a Terraform planfile between CI

The past year has changed how we build Atmos. Advances in AI have accelerated

Configuration can pass schema validation while still using deprecated fields or depending on an archived upstream repository. Migrating those fields also takes care: a valid replacement can change which components run or how missing dependencies behave. The new Atmos Doctor brings those findings together and verifies supported repairs before applying them.

You ask the AI how many stacks you have. After a pause with nothing on screen, it answers that it needs your approval to run a command, and asks whether you would approve it. There is no prompt to say yes to, no sign that anything was happening while you waited, and no way to reply. The answer ends, and so does the conversation.

In most GitOps setups the deployment repository is protected. Nothing lands on main without review, because whatever reaches main is what Argo CD or Flux applies to the cluster. Delivering rendered manifests into that repository has meant giving the deploy pipeline permission to push straight to the branch the cluster reconciles from, which skips the review step the repository exists to enforce. Git provision targets can now deliver through a pull request.

Publish pull request comments, job summaries, and status checks from Atmos scripts. Preview reports locally before running the same script in CI.

Pre-commit hooks put your team's standards to work on every commit.

Call container builds, HTTP requests, prompts, and archive operations from reusable Starlark functions you can test with Atmos.

Give your team one command to build, ship, and deploy containers, whether they

Atmos is now a language for automation. Introducing the

Reviewing a CloudFormation deployment in CI means finding the pending changes, the deployment result,

Comparing debug logs is harder when ANSI color escapes appear in the files, even after you ask for plain output. Atmos now consistently honors global color opt-outs and adds an independent log color setting, so you can save plain logs while keeping your terminal UI colored.

Trying Atmos for the first time should be easy. Install it, check out an example, and run it. Now you can with atmos init.

Large infrastructure repositories can contain a few components with much larger

Many organizations enforce an Azure Policy that rejects any Key Vault secret created without an expiration date and a set of tags. It is a sensible governance rule, and it blocks every write that doesn't comply. Until now, that ruled out using Azure Key Vault as an Atmos store in those environments: Atmos wrote the secret value and nothing else, so the policy denied the request.

A controller rollout times out. The deploy fails with "release did not become ready within 5m0s" and nothing else. So you switch to the cluster, run kubectl get pods, then describe, then logs on whichever pod looks wrong - and in CI you often can't do any of that. Worse, if the release is set to roll back on failure, the rollback has already deleted the crashing pods by the time you look, taking the evidence with it.

Templates change over time: a file that made sense when you first generated your project gets

A local plan rarely depends on infrastructure that is entirely missing or entirely deployed. For example, the VPC exists, the database has not been created yet, and the cluster is somewhere in between. Until now, component mocks forced an all-or-nothing choice: with --use-mocks, every Terraform lookup returned its mock, even for components whose real state was sitting in the backend.

Running --update against a generated project is supposed to save you from re-doing your own

CI should install the artifacts reviewed and committed with a project. Ordinarily, Atmos verifies artifacts against the lockfile's recorded checksums, but it can still accept and record a new artifact when a tool or platform entry is missing.

A scaffold template's spec.files[] entries have always matched one discovered file at a time —

If you already drive your infrastructure work through a terminal coding agent, paying for a

Waiting for each component download to finish before the next begins adds up in

Running terraform init is necessary the first time you touch a working directory, and again

Every CI runner — a GitHub-hosted tier or a self-hosted pool — has to be sized before a single job runs

Plenty of organizations run their own GitHub instance behind the firewall instead of using public github.com. Standard tools are expected to just work against it: GITHUBSERVERURL and GITHUBAPIURL are the same two variables GitHub Actions already exports on both public github.com and a GitHub Enterprise Server runner, precisely so that scripts and CLIs don't need special-casing.

Infrastructure graphs often include dependencies that are useful when present but should not block an environment when a component is intentionally absent or disabled. Treating every dependency as mandatory forces stack-specific workarounds and makes reusable manifests harder to share.

Git tags on GitHub almost always carry a v prefix — v1.228.0 — because that's the convention

Automating the last mile of a dependency bump — branch, commit, push, open a pull request — only

Atmos's toolchain has had a lockfile for a while. The lockfile records the exact resolved artifact

If your team already publishes container images, Atmos components, or Helm charts to a private

Every interactive form with a fixed set of choices eventually hits the same problem: at some

Say goodbye to overwhelming Terraform output. The new streaming UI mode transforms verbose terraform output into a clean, Docker-build-style progress display with interactive confirmations, resource dependency tree visualization, and attribute-level change details.

Terraform locks state before it writes to it, and by default it gives up the instant that lock

Plain JSON has no comment syntax, so there's nowhere to put an annotation telling a tool which

A container component's build.context and dockerfile looked like ordinary relative paths, but

You add platforms: [linux/amd64] to a container build step, run it, and nothing happens

Every file a scaffold template declares renders at most once. when: can skip a file, but it

Centralizing shared configuration in one private Git repository, and reusing it across projects, is not a

A CI job deploying the dev stack shouldn't need to vendor every component in the repository --

Package managers normally tell you when an installed package is out of date and let you refresh

Pinning a CLI tool to an exact version is good practice — until it's time to move forward. Then it means

Kustomize expects the files it consumes to have exact, reserved names. A remote base or

Atmos's Aqua-compatible toolchain registry now understands two more package types: githubarchive and githubcontent. Tools that ship as a source tarball (like adr-tools and tfenv) or as a single raw file in a repo (like kubens and kubectx) can now be installed through atmos toolchain install without any registry workarounds.

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 your browser, signs you in, and sets up everything Terraform and the az CLI need.

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. You could write it into Terraform state, where it does not belong. You could run a cloud CLI command by hand. You could also build a custom file-based handoff between steps. Atmos already had a fast way to read any value from a configured store. But Atmos had no supported way to write a value into a store. The only exception was one narrow hook. That hook works only with Terraform output. For every other value, you had to leave Atmos to write it.

Pulling a tool's version into a script usually means scraping decorated terminal output. A checkmark here, a

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. metadata couldn't — every component had to repeat the same labels/tags, and a metadata: block placed at the top of a stack file was silently ignored.

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 by hand with terraform state mv, but that command only fixes one workspace at a time. It is easy to get wrong, and no one can review it before it runs.

Vendoring pulls external code into your own repository so it's reviewable, diffable, and not

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 configuration changed — a default did, somewhere in the release notes you didn't read, and now you're bisecting versions to figure out which upgrade moved the furniture. Every tool with evolving defaults forces this trade-off: either the project never improves its out-of-the-box behavior, or every upgrade is a small gamble.

Container image builds get slower as a Dockerfile grows, and CI runners rarely keep a warm

Initializing a project should establish a useful local starting point, not leave a developer with

Installing every tool a repository might eventually need makes project setup slow and wasteful.

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 ignored, and you discover the mistake only when Atmos doesn't behave the way you expected. Stack manifests solved this with a published JSON Schema and editor auto-completion, but the CLI configuration itself — a surface that has grown far larger than stack manifests — had no schema at all. Now it does: a schema generated from the very code that reads the configuration, validated by default, published with every release, and wired into your editor with one comment line.

Editors, CI pipelines, and offline environments that want to validate stack manifests locally

Package managers normally let you discover available updates, review their impact, and apply them

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 bootstrap new Atmos projects or generate infrastructure code in seconds.

Getting Atmos connected to an MCP server, or letting your AI assistant call Atmos's own tools, used to

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 lives in that tree; it doesn't tell you it's tier-1, or that platform owns it, or that it's in scope for SOX. Those characteristics don't belong to one branch of the tree — they apply across many stacks and many components at once, and a single component is usually several of them simultaneously. Your AWS accounts and auth identities have the same problem: prod-admin doesn't tell you it's the production one, or the elevated one, until you already know that.

Packaging a directory into a deployable archive — most commonly zipping a Lambda

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 scripting a loop over components yourself, or falling back to one-at-a-time runs.

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 for step. The prompts that make the workflow friendly locally are exactly what make it unrunnable in a pipeline, so you end up maintaining a second, prompt-free copy just for CI.

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 a catalog in atmos.yaml, a deterministic lock file, policy-driven updates, and file managers that rewrite your workflows, Dockerfiles, and rendered files from the lock.

Atmos can now read and edit your YAML — atmos.yaml, stack manifests, and vendor.yaml —

A workflow fails in CI. You open the run and you're staring at two thousand lines of

Atmos now detects unsupported and misspelled YAML function tags before configuration

atmos git clone is Atmos's native replacement for actions/checkout. Mirroring the

Atmos container builds and pushes now write rich image summaries directly to the CI job summary when

Atmos now treats Helm as a first-class component type. Define a Helm release —

Atmos now treats Kubernetes as a first-class component type. Define Kubernetes

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.

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. It reads dependencies.components (preferred) and the legacy settings.depends_on, so the output stays consistent with atmos describe dependents.

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 keeping those copies in sync by hand.

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 instead of a sequence.

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 failure behavior directly to your workflow YAML.

Atmos hooks can now run any workflow step type. A new kind: step hook bridges the

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 to another window. When no speech engine is available (or you're in CI), it degrades gracefully and prints the message instead, so the same workflow works everywhere.

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 atmos terraform plan log stream. The official Atmos Docker image was also updated so Checkov runs without a glibc error.

Atmos workflows and custom commands can now run containers natively. A new type: container step

The official Atmos Media Kit is now available with downloadable logo assets, usage guidance, brand colors, and product language for teams writing about or building integrations with Atmos.

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-session, ssh, psql, and vim can take over the terminal properly, with Ctrl-C going to the session instead of killing Atmos.

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 Terraform providers your stacks download, the modules and vendored components they pull, remote stack imports, and everything else it would otherwise re-fetch from the internet on every run. Cold CI jobs go warm: the same pipeline stops waiting on the same downloads, and stops going red when an upstream registry has a bad minute.

Atmos now has first-class secrets management: you declare the secrets each component depends on,

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, keep working when upstream registries are slow or down, and capture the exact versions a deployment used so builds stay reproducible. No changes to your Terraform code, provider declarations, or module sources.

Atmos now supports before.terraform.init and after.terraform.init lifecycle

atmos auth login now performs one browser interaction per AWS SSO portal, no matter how many

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 import defined, without resorting to workarounds.

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 GitHub Actions cache) skip the clone entirely on subsequent runs.

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 scripts, CDK, and more.

Atmos now exposes Git repository metadata through dedicated YAML functions:

Fetching private Terraform modules, Atmos source: components, and vendored artifacts in CI has

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 your atmos.yaml without external scripts.

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, generated assets, schemas, Lambda source, or other external paths change.

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 a manual re-run. With this release you can configure per-component retry so transient failures recover automatically — without retrying real Terraform errors.

Atmos hooks now have a kind system — the same before.terraform.plan /

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.

Atmos toolchain installs now verify downloaded packages before extraction when registry metadata provides checksums, signatures, or attestations.

Three documented flags on atmos list instances were silently ignored:

You can now pin Terraform and provider versions directly in your stack configuration. Atmos generates terraformoverride.tf.json files with requiredversion and required_providers blocks, giving you centralized control over infrastructure versioning.

atmos describe affected --format=matrix now writes to $GITHUBOUTPUT automatically when CI is enabled, matching the behavior already shipped for atmos list instances --format=matrix. No more --output-file=$GITHUBOUTPUT boilerplate in workflow YAML.

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 exact command to re-run. The same release also adds profiles.default so you can pin a default profile in atmos.yaml.

Atmos now supports server-side commits via the Atmos Pro GitHub App. The new atmos pro commit command

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 ATMOSCIGITHUB_TOKEN.

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 interactive sign-in using the same AWS console flow you already know.

Atmos can now pull security findings from AWS Security Hub, map them to the exact Atmos

The atmos describe affected command now auto-detects the base commit in CI environments, eliminating the need for verbose flag wiring in your workflows.

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 credential chain).

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.

Atmos stack processing is now up to 3.5× faster for deep-merge operations — the hot path

For teams using Atmos Pro, 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 state of every component within seconds — no polling, no waiting for webhooks, no stale data.

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 same command work identically locally and in CI—no wrapper scripts, no extra actions, no hidden complexity.

Add --ai to any Atmos command and get instant AI-powered analysis of the output. Successful plans get

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.

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 relationships.

Vendor targets now accept optional version overrides, enabling multiple versions of the same component from a single source entry.

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 two open standards -- AGENTS.md and Agent Skills -- and work across Claude Code, OpenAI Codex, Gemini CLI, Cursor, Windsurf, GitHub Copilot, and other AI tools.

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.

Test features from any Atmos pull request or commit SHA without compiling from source or manually downloading artifacts.

The !terraform.state YAML function now supports reading from S3 buckets encrypted with customer-provided keys (SSE-C).

Atmos helmfile commands now use the identity system for AWS authentication and provide more flexible EKS cluster name configuration.

Atmos now automatically detects components and stacks that have been deleted in your current branch compared to the target branch.

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.

The --chdir flag now correctly isolates configuration loading when changing to a directory with its own Atmos configuration.

Provably safe secrets masking with custom patterns, comprehensive output coverage, and configurable replacement strings.

Atmos now correctly detects file changes in components that use the source attribute for just-in-time vendoring. Previously, components vendored from remote sources were not properly tracked for affected detection.

New query syntax for atmos list components and support for installing multiple tools at once with atmos toolchain install.

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 infrastructure.

Locals can access {{ .settings }}, {{ .vars }}, and {{ .env }} from the same file during template resolution.

Atmos now supports atmos vendor list and atmos workflow list as aliases for their atmos list vendor and atmos list workflows counterparts.

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 recommended patterns. Atmos automatically passes the component directory to Packer, which loads all *.pkr.hcl files.

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 just-in-time during your first Terraform operation.

The atmos list components command now correctly shows unique component definitions, supports stack filtering, and uses a new dedicated configuration namespace.

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 advanced users.

Atmos now supports declarative file generation for Terraform components via the new generate section in stack configuration.

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.

The !terraform.state YAML function now correctly reads Terraform state when workspaces are disabled

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.

Atmos now includes native toolchain management that seamlessly integrates with the Aqua registry ecosystem — giving you

atmos auth login now automatically falls back to provider authentication when no identities are configured, enabling seamless first-time login with autoprovisionidentities.

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 components. Declare component sources inline without requiring separate component.yaml files—components are automatically downloaded on first use.

We're sharing the Atmos Product 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 long-term vision?" The roadmap answers that question openly.

Introduces pkg/function/, a new format-agnostic function registry that consolidates YAML function handlers into a reusable package.

Quickly identify which components and stacks are affected by your changes with the new atmos list affected command.

Starting with Atmos v1.202.0, empty or omitted basepath values in atmos.yaml now trigger git root discovery instead of defaulting to the current directory. Users with multiple Atmos projects in a single repository, or where the Atmos project root differs from the git root, must explicitly set basepath: ".".

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 tools like Terraform, Helm, or ArgoCD.

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.

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 commands.

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—Atmos provisions your state backend automatically with secure defaults, making it fully compatible with Terraform-managed infrastructure.

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 workflows faster and more intuitive.

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 provisioned or outputs didn't exist.

Atmos now includes four AWS YAML functions that retrieve identity and region information directly in stack configurations: !aws.accountid, !aws.calleridentityarn, !aws.calleridentityuserid, and !aws.region.

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 might feel more natural for users accustomed to running commands on folders rather than remembering specific component names.

Metadata now inherits from base components, just like vars and settings.

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: "It works on my machine."

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 behaviors, you can ensure all team members and CI/CD pipelines use compatible Atmos versions.

We've reorganized the Atmos documentation to better serve both newcomers and experienced users. Here's what changed and why.

We've improved how Atmos handles YAML functions during merges across configuration layers.

This release brings powerful enhancements to color output in CI/CD environments and significant code quality improvements that make Atmos more maintainable and performant.

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 light theme like GitHub, help output will match your terminal's color scheme.

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.

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 CIDR ranges, while production stays on the stable version until you're confident the changes work.

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 identically to az login with full Terraform provider compatibility.

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 actionable guidance instead of cryptic messages, and enterprises can track and analyze errors across their entire infrastructure stack.

Atmos now automatically discovers your repository root and runs from there, just like Git. No more cd-ing back to the root directory.

You can now disable Atmos identity authentication by setting --identity=false, allowing you to use cloud provider SDK credential resolution instead.

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.

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 !terraform.state and !terraform.output functions work seamlessly without relying on ambient credentials.

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 seamlessly use cloud credentials in your automation while maintaining security through file-based credential management.

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 blazing-fast performance to Azure that S3 users already enjoy.

We've made several quality-of-life improvements to Atmos authentication commands, making identity management smoother and more intuitive.

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 consistency with other DevOps tools.

Atmos now detects circular dependencies in YAML function calls and provides a clear call stack showing exactly where the cycle occurs.

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 temporary console sign-in URLs and open them in your browser.

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 identities, end work sessions, and maintain proper security hygiene.

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 it easier than ever to understand and manage complex authentication chains across multiple cloud providers and identities.

We've significantly improved the AWS SSO authentication experience with styled verification code dialogs, animated status indicators, and proper Ctrl+C handling.

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 infrastructure tooling up-to-date—all from your terminal with beautiful formatted output.

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.

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, allowing the community to extend Atmos with custom command packages without modifying the core codebase.