What's new and what's next for Atmos.
Organizations with their own identity provider or credential broker need to connect that login flow to their infrastructure commands. Native Atmos plugins let teams implement the provider in Go, distribute a compiled release using any OCI registry, and use it through the same authentication commands as built-in providers.
Reading about a feature should lead directly to trying it. Finding its example directory,
Gomplate's experimental functions are now available in Atmos stack manifests.
Sharing one team's CLI configuration across many repositories is a common setup: keep developer-tooling
The templates.settings.delimiters setting changes the delimiters that Atmos
A deployment can take thirty seconds to finish even when a demo only needs four
A CI job fails, and the run page says only "Process completed with exit code 1." To learn why, you open the job,
Preformatted Terraform tables make it difficult to group variables or reproduce
Plan in one stage, apply in another: that is the whole point of saving a Terraform planfile between CI
Enabling preview environments from a pull request label often requires workflow scripts to fetch labels and pass flags into stack configuration. The new !ci.labels YAML function lets you express that decision directly in your stacks.
The past year has changed how we build Atmos. Advances in AI have accelerated
An RDS instance's latest restorable time can advance between Terraform plans even when its configuration has not changed. That timestamp can make a plan comparison fail and interrupt deployment verification. Atmos now supports configured attribute exclusions for both comparisons.
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.
A successful infrastructure command does not prove that a plan respected your safety rules or that
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.
Shared AI skills need a record of where they came from and which revision a project uses.
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.
Rain, the AWS CloudFormation CLI, was archived in July 2026. Teams that deploy with it need a
Publish pull request comments, job summaries, and status checks from Atmos scripts. Preview reports locally before running the same script in CI.
Query affected Atmos components and their dependents, then select the build, test, and deployment tasks to run for a change.
Pre-commit hooks put your team's standards to work on every commit.
Packaging a Lambda archive is only part of a deployment: the archive must also
Call container builds, HTTP requests, prompts, and archive operations from reusable Starlark functions you can test with Atmos.
Use !literal to keep script text unchanged. Custom commands also preserve arguments, pass integer flags correctly, and enforce step timeouts.
Give your team one command to build, ship, and deploy containers, whether they
Stack policies often differ by environment, so static policy files can require
Atmos is now a language for automation. Introducing the
Tools like aws-sso-util and Granted let you run aws --profile=app-sandbox-1 s3 ls from any directory, because the profile in ~/.aws/config knows how to fetch its own credentials. Move to atmos auth and that convenience goes away: the AWS CLI only gets credentials when you run it through atmos auth exec from inside the Atmos project, and people have filled the gap with shell scripts that eval $(atmos auth env) and re-encode the result as JSON without a correct expiration. The reverse problem exists too. Many organizations already vend temporary AWS credentials through a helper such as okta-aws-cli, aws-sso-cli, or aws-vault, and those credentials never reached Atmos, so those teams could not use atmos auth shell, identity chaining, or the automatic authentication of atmos terraform.
Reviewing a CloudFormation deployment in CI means finding the pending changes, the deployment result,
CloudFormation deployments need more than a template: they need parameters for
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.
You pin hashicorp/terraform 1.15.8 in .tool-versions, run atmos terraform plan, and Atmos quietly runs whatever Terraform happens to be first on your PATH — a Homebrew upgrade, a teammate's tfenv shim, or an older binary on a CI runner. The Terraform versions guide promised the pinned version; components didn't deliver it. Now every command and component uses .tool-versions as its baseline.
Trying Atmos for the first time should be easy. Install it, check out an example, and run it. Now you can with atmos init.
atmos describe affected now supports --tags and --labels, so you can choose which affected components enter your CI job matrix directly from stack metadata.
Large infrastructure repositories can contain a few components with much larger
A Helm chart is full of {{ }} expressions, and so is a GitHub Actions workflow with its
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.
Every S3 bucket name has historically lived in one namespace shared by all AWS customers. The name you want for your Terraform state bucket may already belong to someone else, and when you delete a bucket, its name goes back into the shared pool where anyone can claim it. Amazon S3 now offers an account-scoped namespace that fixes both problems: bucket names in it are reserved to your account and cannot collide with anyone else's, now or after the bucket is deleted. Atmos could not request that namespace when it created a state bucket, so teams that want it had to create the bucket by hand before Atmos could take over.
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.
Kubernetes server-side apply tracks who owns every field of a managed object. When two actors write the same field - a controller that reconciles an object a release also sets, or an object whose ownership ledger was lost - the next apply fails with a field-ownership conflict. The standard escape is a one-off kubectl apply --server-side --force-conflicts or hand-editing managedFields, then re-running your deploy. That is fine on a laptop and impossible in CI, and a conflicted release blocks every dependent waiting on it.
Templates change over time: a file that made sense when you first generated your project gets
Two fields in the same scaffold template often need the exact same list of choices — a license
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.
More and more Azure resource roles are handed out as PIM-eligible rather than standing: you hold
Running --update against a generated project is supposed to save you from re-doing your own
Finding the stack, component, and team behind a failed infrastructure command can
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.fields[] questionnaire is great at collecting answers, but not every
A scaffold template's spec.files[] entries have always matched one discovered file at a time —
The AI model landscape moves faster than any single vendor's roadmap. A model that was the obvious
If you already drive your infrastructure work through a terminal coding agent, paying for a
Bringing a generated project or component forward when its template changes means computing a
Waiting for each component download to finish before the next begins adds up in
Workflows and custom commands can invoke Atmos many times, repeating startup banners and experimental warnings before each step. Those repeated notices make it harder to find the output that matters. Atmos now shows each experimental feature's warning once every 24 hours by default and suppresses repeated startup banners in child invocations.
Running terraform init is necessary the first time you touch a working directory, and again
Run post-deployment checks with a test tree, progress, and failure-only output.
Every CI runner — a GitHub-hosted tier or a self-hosted pool — has to be sized before a single job runs
An urgent image rollback, a temporary feature flag, or a one-off chart setting should not require
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.
A component can have several labels, while a variable may need only one value.
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.
A Helm values file, a docker-compose override, or any other hand-maintained YAML config often carries
Git tags on GitHub almost always carry a v prefix — v1.228.0 — because that's the convention
Shipping a Helm release is rarely a single helm upgrade --install. A first install onto a cold cluster needs a generous timeout; a routine upgrade should fail fast. A broken upgrade should roll back and clean up the resources it left behind; a broken first install should uninstall itself so it doesn't wedge the next attempt. Some releases must wait for their Jobs to finish, others only for a readiness gate, and a few shouldn't wait at all. Getting this right usually means memorizing a pile of Helm flags and threading them into shell wrappers per command — and trusting that every environment runs the same incantation.
Automating the last mile of a dependency bump — branch, commit, push, open a pull request — only
Atmos lets you configure the Kubernetes namespace where a Helm release should be installed. This
Atmos's toolchain has had a lockfile for a while. The lockfile records the exact resolved artifact
Terraform components already recover from a transient error automatically — a 502, a dropped registry connection, an S3 backend timeout. Helmfile, Packer, and Ansible components in that same pipeline did not. The exact same class of failure that Terraform shrugged off would still fail your Helmfile sync or Ansible playbook outright, because a retry: block on either was silently inert. Now all four component types share the same retry engine.
If your team already publishes container images, Atmos components, or Helm charts to a private
Component retry already recovers a single component from a transient error block onto each component, wire up a shared abstract base component just to hold it, or set up a mixin. Now you can define the policy once at the stack level, and every component in that stack inherits it automatically.
Every interactive form with a fixed set of choices eventually hits the same problem: at some
GitHub Actions is the most popular way teams run Atmos in CI, and a lot of those pipelines are
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.
Federal agencies, financial institutions, and healthcare organizations are often required to run
Terraform locks state before it writes to it, and by default it gives up the instant that lock
A custom command often needs to behave differently depending on how it was called — skip the
Plain JSON has no comment syntax, so there's nowhere to put an annotation telling a tool which
A pipeline runs a dozen Atmos commands across a dozen jobs. Something looks off — a plan
A container component's build.context and dockerfile looked like ordinary relative paths, but
Naming things from memory is one of the more tedious parts of a CLI workflow. You know you want
You add platforms: [linux/amd64] to a container build step, run it, and nothing happens
Using an Atmos-managed GCP identity with GKE used to stop one step short of the cluster. The
Every file a scaffold template declares renders at most once. when: can skip a file, but it
Bring up two containers in the same environment and the first thing you hit is that they can't
Centralizing shared configuration in one private Git repository, and reusing it across projects, is not a
Atmos scaffolds can perform genuinely complex three-way merges of YAML templates: keys can merge
A CI job deploying the dev stack shouldn't need to vendor every component in the repository --
Bootstrapping Terraform state on Azure has always meant a detour outside Terraform: before you
Package managers normally tell you when an installed package is out of date and let you refresh
Editing a config value from the command line is supposed to be the easy path. Type `atmos stack set
Pinning a CLI tool to an exact version is good practice — until it's time to move forward. Then it means
Before you install a skill, you want to read what it does. Atmos agent skills did not let you do that. You
Kustomize expects the files it consumes to have exact, reserved names. A remote base or
If you've ever tried to move a Taskfile.yml over to Atmos, you've hit the gap had no
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.
Getting kubectl and docker working against Azure resources has always meant a side trip
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.
Reference architectures live for years. By the time you wire up a store hook, most of what
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.
Atmos workflows already supported --stack. They now also support --tags and --labels, forwarding those selectors to every nested type: atmos step.
Pulling a tool's version into a script usually means scraping decorated terminal output. A checkmark here, a
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 has to run them first, in the right order. In practice that "something" is usually a bash wrapper --include-dependencies and --include-dependents expand any multi-component selection with its dependency closure and execute it in graph order, and the list commands preview exactly what would run.
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.
Large stacks eventually turn into a shared bottleneck. Network, platform, and
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.
Keeping vendored components current across dozens of repositories doesn't scale as a manual habit.
Vendoring pulls external code into your own repository so it's reviewable, diffable, and not
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 downloads, and registry artifacts—without accidentally mistaking missing evidence for an empty dependency set. Atmos now makes that evidence visible in one SBOM while keeping coverage boundaries explicit. It also integrates with native CI to upload the SBOM as a GitHub Actions workflow artifact when enabled.
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.
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 review depend on deployed infrastructure, backend access, and cloud credentials that are irrelevant to the change at hand.
Container image builds get slower as a Dockerfile grows, and CI runners rarely keep a warm
Large repositories often have validation rules that are useful but expensive or
Initializing a project should establish a useful local starting point, not leave a developer with
Platform teams build golden paths so application teams can begin with the right architecture,
Installing every tool a repository might eventually need makes project setup slow and wasteful.
A workflow can be valid YAML and still fail only after GitHub Actions tries to run it: a
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.
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, download size, verification state, and final result line.
Editors, CI pipelines, and offline environments that want to validate stack manifests locally
Upgrading the atmos binary has always meant upgrading your schema validation too, whether you
Package managers normally let you discover available updates, review their impact, and apply them
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 hooks; now it runs a linter the same way, with a built-in tflint hook kind.
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.
On macOS, Atmos would sometimes install a verifier CLI (like cosign, used to check signatures on
Getting Atmos connected to an MCP server, or letting your AI assistant call Atmos's own tools, used to
You set mcp.enabled `failed to initialize AI components:
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.
You pinned aws/aws-cli in your toolchain, ran atmos toolchain install, and saw a
Packaging a directory into a deployable archive — most commonly zipping a Lambda
A component with an oci true failed the moment you ran any Terraform operation against it. JIT auto-provisioning (the before.terraform.init hook) failed with go-getter's download not supported for scheme 'oci', even though atmos vendor pull handled the exact same source fine. Registries distributing modules in OpenTofu's native OCI module-package format couldn't be pulled by either path at all.
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.
Reading !terraform.state and !terraform.output can fail to resolve for a dozen
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 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.
Atmos can now read and edit your YAML — atmos.yaml, stack manifests, and vendor.yaml —
Atmos can now record terminal sessions as asciicast files and render them into
A workflow fails in CI. You open the run and you're staring at two thousand lines of
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 made the options you actually needed harder to find.
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 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: vpc-base instead of deeply nested YAML structures.
Atmos container builds and pushes now write rich image summaries directly to the CI job summary when
Atmos help output now separates built-in commands from custom commands, and error output now makes explanations easier to scan without adding extra headings.
Atmos now treats Helm as a first-class component type. Define a Helm release —
Terraform's native testing framework (*.tftest.hcl) is great — until you hit a run block with
Atmos now treats Kubernetes as a first-class component type. Define Kubernetes
Atmos lifecycle hooks can now run an ordered list of steps with kind: steps.
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.
Custom command steps can now read their own command-line flags through {{ .Flags. }}, and the table step templates its data, columns, and title per-step. Together they let you build flag-driven runbooks — rich, dynamic output assembled declaratively in atmos.yaml, no shell scripting required.
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.
The official Atmos agent skills are now embedded directly in the Atmos binary. atmos ai skill install works fully offline — no network call, no Git clone — and atmos ai skill list shows a single merged view of every skill available to you alongside what's already installed.
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.
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 checks.
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 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 background: true, gate the next step on its container health check, and stop it with a cancel step — no shell scripts, no background jobs, no orphaned containers.
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.
A big challenge for infrastructure developers is how hard it is to iterate locally. Every
Atmos hooks can now run any workflow step type. A new kind: step hook bridges the
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 timeouts and retries that compose with the existing retry webhook? It's an accepted alias.)
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) can now surface findings as inline GitHub annotations on the pull request diff and upload them to GitHub Code Scanning (the Security tab) — natively, with no github/codeql-action step. Custom hooks running any SARIF-emitting tool get the same treatment by adding format: sarif.
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 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 downloads it, generates a fresh plan, reconciles it against the reviewed plan, and applies the fresh plan — only if they match, failing on drift by default.
Atmos workflows and custom commands can now run containers natively. A new type: container step
Atmos now has a first-class container component kind. Where a type: container workflow step is a
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.
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 does not change how the component is processed, planned, or applied.
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 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: deployment repos consumed by Argo CD or Flux, provider lock files, rendered manifests. Define managed repositories once in atmos.yaml, then clone, inspect, diff, commit, and push them through a new atmos git command group, or publish generated artifacts automatically on lifecycle events with the new git hook kind.
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 supports using dotenv files directly with the !include YAML function.
Atmos now has first-class secrets management: you declare the secrets each component depends on,
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 subprocess at it via TFCLICONFIGFILE and TOFUCLICONFIGFILE — no hand-managed dotfiles, no manual env exports.
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.
The atmos describe affected command now compares every provisioned component section between refs — including providers, required_providers (provider versions), generate, backend, auth, and command. Previously, changes to these sections were silently missed.
Atmos now supports before.terraform.init and after.terraform.init lifecycle
Atmos now supports the !append YAML function, which adds items to an inherited list
atmos auth login now performs one browser interaction per AWS SSO portal, no matter how many
Atmos Terraform bulk commands now run through a dependency graph, with optional bounded concurrency for plans and deterministic ordering for multi-component runs.
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.
--use-version now accepts a refmain — without looking up a commit SHA.
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 adds a new template function, atmos.Resolve, that evaluates any
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.
A common question from the community is: *how do I use Atmos with Packer to build AMIs,
Atmos now exposes Git repository metadata through dedicated YAML functions:
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 local catalog — from one variable defined once.
Fetching private Terraform modules, Atmos source: components, and vendored artifacts in CI has
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.
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 includes core Git YAML functions for resolving repository metadata directly in stack and config processing: !git.root, !git.sha, !git.branch, and !git.ref.
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.
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.
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.
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 Amazon Inspector, including Security Hub product findings from services such as AWS Config, GuardDuty, Macie, and IAM Access Analyzer, then uses Atmos component tags and mapping heuristics to connect affected resources back to the stacks and components that manage them.
Atmos hooks now have a kind system — the same before.terraform.plan /
GitHub Actions has a built-in "Re-run with debug logging" button: when a workflow fails, you click it and the next run launches with runner and step debug logging turned on. Atmos now auto-detects that signal — when you re-run with debug logging, Atmos switches its own log level to Debug for the run. No need to remember to also set ATMOSLOGSLEVEL=Debug in your workflow YAML.
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 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-deterministic order — the dependency-graph implementation that landed with PR #1516 was reachable from tests but never wired into the CLI dispatcher.
Atmos toolchain installs now verify downloaded packages before extraction when registry metadata provides checksums, signatures, or attestations.
Claude Code, OpenAI Codex CLI, and Google Gemini CLI all speak MCP, but
Three documented flags on atmos list instances were silently ignored:
Every atmos list subcommand that processes stack manifests now accepts --skip and the matching
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 --upload now works under GITHUBEVENTNAME=mergegroup, so Atmos Pro can correctly conclude check runs on the synthetic commits GitHub creates when a PR enters a merge queue. To control what runs on those synthetic commits, declare a new settings.pro.mergegroup.checksrequested.workflows block in your stack config and point it at the workflow you want the queue to dispatch (in most cases, the same plan workflow you already use for pullrequest.synchronize).
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.
Every atmos list subcommand that processes stack manifests now accepts --process-templates and --process-functions
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 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 now supports server-side commits via the Atmos Pro GitHub App. The new atmos pro commit command
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.
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.
You can now enable or disable CI PR comments per-pipeline using the ATMOSCICOMMENTS_ENABLED environment variable — no config file changes needed.
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.
The atmos auth env command now supports --format=github for direct output to $GITHUB_ENV, eliminating shell pipelines in CI workflows.
Atmos can now pull security findings from AWS Security Hub, map them to the exact Atmos
Atmos AI now supports CLI providers — invoke your locally installed Claude Code, OpenAI Codex, or
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 can now connect to external MCP servers and use their tools directly in AI conversations.
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 automatically chunks large payloads when uploading affected stacks and instances to Atmos Pro, eliminating HTTP 413 errors for large infrastructure repositories.
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 identities now support required: true, enabling automatic authentication of multiple identities before Terraform runs — without prompting.
Atmos stack processing is now up to 3.5× faster for deep-merge operations — the hot path
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 clusters, giving you seamless kubectl access without requiring the AWS CLI.
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.
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.
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.
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.
Add --ai to any Atmos command and get instant AI-powered analysis of the output. Successful plans get
Atmos now supports a global templates.settings.ignoremissingtemplatevalues option in atmos.yaml, eliminating the need to set ignoremissingtemplatevalues: true on every individual catalog import.
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.
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.
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.
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 when working with floating refs like branch names during active development.
Vendor targets now accept optional version overrides, enabling multiple versions of the same component from a single source entry.
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 across different cloud providers.
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.
Access the AWS Organization ID directly in stack configuration with the new !aws.organization_id YAML function.
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.
Atmos now supports first-class Google Cloud authentication alongside AWS and Azure, with provider-scoped file isolation and a unified auth experience.
Test features from any Atmos pull request or commit SHA without compiling from source or manually downloading artifacts.
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 manifests.
The !terraform.state YAML function now supports reading from S3 buckets encrypted with customer-provided keys (SSE-C).
Atmos now supports credential realm isolation, preventing collisions when engineers
Atmos helmfile commands now use the identity system for AWS authentication and provide more flexible EKS cluster name configuration.
The !terraform.output YAML function now works seamlessly with Terraform Cloud and Terraform Enterprise backends, enabling cross-component dependencies without switching backend types.
Atmos now automatically detects components and stacks that have been deleted in your current branch compared to the target branch.
Workflows now support environment variables at both workflow and step levels with hierarchical merging.
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.
Fixed an issue where retrieving values from Artifactory stores would fail when using nested paths, and corrected store documentation to accurately reflect supported backends.
The --chdir flag now correctly isolates configuration loading when changing to a directory with its own Atmos configuration.
The atmos auth env command now exports AWSREGION and AWSDEFAULT_REGION
Provably safe secrets masking with custom patterns, comprehensive output coverage, and configurable replacement strings.
Atmos now correctly detects component file changes when running atmos describe affected.
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.
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 intuitive selector.
New query syntax for atmos list components and support for installing multiple tools at once with atmos toolchain install.
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.
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.
Atmos toolchain now has native GitHub Actions support with the new github format for atmos toolchain env.
Locals can access {{ .settings }}, {{ .vars }}, and {{ .env }} from the same file during template resolution.
Locals now support YAML functions like !env, !exec, !store, !terraform.state, and !terraform.output.
Atmos now supports atmos vendor list and atmos workflow list as aliases for their atmos list vendor and atmos list workflows counterparts.
Interactive component selection now filters out non-deployable components.
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 provides granular control over experimental features with the new settings.experimental configuration option—giving teams the flexibility to explore new capabilities safely while maintaining stability in production environments.
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 source provisioner now provides better visual feedback with spinners during auto-provisioning, interactive confirmation prompts for delete operations, and interactive stack selection when --stack is omitted.
The atmos list components command now correctly shows unique component definitions, supports stack filtering, and uses a new dedicated configuration namespace.
The file-scoped locals feature introduced in v1.203.0 now correctly resolves {{ .locals.* }} templates in stack configurations.
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.
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, contextual answers—powered by Algolia DocSearch v4 and ChatGPT.
Atmos now supports declarative file generation for Terraform components via the new generate section in stack configuration.
Atmos now includes a unified import adapter registry that provides a modular, extensible architecture for configuration imports.
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.
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 required.
The !terraform.state YAML function now correctly reads Terraform state when workspaces are disabled
Custom commands now support structured task syntax with per-step configuration including timeouts, retry logic, working directories, and authentication identities.
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 supports automatic version switching, making it easy to pin projects to specific Atmos versions and ensure consistency across teams.
Atmos now includes native toolchain management that seamlessly integrates with the Aqua registry ecosystem — giving you
Atmos now automatically detects when your AWS IAM User credentials have been rotated or revoked and prompts you for new credentials inline.
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 automatic retry with exponential backoff for vendoring and source operations. This makes component downloads more resilient to transient network failures, connection resets, and GitHub API rate limits.
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.
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 Terraform operations. Today, we're introducing Component Workdir Isolation—a foundational feature that eliminates these conflicts and unlocks powerful new capabilities for Atmos.
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.
Atmos now supports Azure OIDC/Workload Identity Federation for secure, secretless authentication in CI/CD pipelines.
Introduces pkg/function/, a new format-agnostic function registry that consolidates YAML function handlers into a reusable package.
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.
Quickly identify which components and stacks are affected by your changes with the new atmos list affected command.
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.
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: ".".
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 making your configurations more readable and maintainable.
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.
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.
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 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 subcommands.
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.
Custom commands and workflow steps can now specify a working_directory to control where they execute.
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.
Atmos now provides clear, actionable error messages when your Terraform components contain HCL syntax errors, instead of the misleading "component not found" message.
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.
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 infrastructure doesn't follow a strict naming convention.
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.
Configure custom columns in atmos.yaml to tailor list command output to your team's needs
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.
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.
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.
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 container with all the tools you need for infrastructure work, Geodesic is your answer.
New metadata.name field provides stable Terraform state paths when using versioned component folders.
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."
Need to generate random port numbers, worker IDs, or other numeric values in your Atmos configurations? The new !random YAML function makes it easy.
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.
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.
We've reorganized the Atmos documentation to better serve both newcomers and experienced users. Here's what changed and why.
We've added comprehensive migration guides to help teams adopt Atmos regardless of their starting point.
We've improved how Atmos handles YAML functions during merges across configuration layers.
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 generation.
This release brings powerful enhancements to color output in CI/CD environments and significant code quality improvements that make Atmos more maintainable and performant.
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 dedicated documentation with usage examples, arguments, flags, and integration details.
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.
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.
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.
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 variables and reference values from your infrastructure configuration.
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.
atmos auth logout now preserves keychain credentials by default for faster re-authentication. Only session data is cleared. Use --keychain to permanently delete credentials.
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.
The theme commands have been migrated to use the modern StandardFlagParser infrastructure, bringing them in line with other Atmos commands.
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 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.
Atmos now automatically discovers your repository root and runs from there, just like Git. No more cd-ing back to the root directory.
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 your style.
You can now disable Atmos identity authentication by setting --identity=false, allowing you to use cloud provider SDK credential resolution instead.
Tab completion for the --stack flag is now context-aware, filtering suggestions based on the component you specify.
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.
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 detection, color adaptation, and secret masking happen transparently. No more capability checking, manual color detection, or masking code. Just write clean, simple output code and it works everywhere.
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'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 correctly.
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.
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 development versions to a registry.
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.
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.
We've made several quality-of-life improvements to Atmos authentication commands, making identity management smoother and more intuitive.
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.
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.
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 simultaneously in a single operation.
Atmos now detects circular dependencies in YAML function calls and provides a clear call stack showing exactly where the cycle occurs.
We're excited to introduce atmos auth shell, a new command that makes working with multiple cloud identities more secure.
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.
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 share credentials across OS boundaries (like between your Mac and a Docker container), or memory keyrings for testing.
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.
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 identities.
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 published two comprehensive guides to help you adopt and integrate atmos auth into your workflows: migrating from Leapp and configuring Geodesic for seamless authentication.
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 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 a solution that works whether you adopt the entire Atmos framework or just need better credential management.
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'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).
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'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, you can now see exactly where every configuration value originated—down to the file, line number, and column.
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.
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.
