115 posts tagged with "DX"

Several independent configuration lookups can spend most of their time waiting on commands, with each lookup waiting for the previous one to finish. You can now set a concurrency limit for ordinary !exec expressions and let those commands overlap without restructuring your stack.

Command help now includes a copyable documentation URL. Use --docs to open that page in your browser, or --example to choose a related example and initialize it locally—even before you have an Atmos project configured.

Reading about a feature should lead directly to trying it. Finding its example directory, installing Atmos, and assembling the first commands adds unnecessary work. Changelog posts with runnable examples, command documentation, and individual example pages now include a quick start with installation instructions and copyable commands.

Sharing one team's CLI configuration across many repositories is a common setup: keep developer-tooling config (AI assistants, MCP servers, toolchain pins) in a single source-of-truth repo, and have every other repo pull it in with a remote import so it is edited in one place. It works - until you try to adopt it safely. A fragment that quietly fails to load leaves its settings out with nothing but a warning. There is no way to say "this one must load." A tooling fragment meant for your laptop gets resolved by an automated apply holding deploy credentials. And an import pinned to a branch silently absorbs the upstream repo's edits on every run.

A deployment can take thirty seconds to finish even when a demo only needs four seconds to show its progress. Speeding up the entire recording also rushes the commands and the pauses that help viewers follow along. Atmos now supports playback groups to set the recorded duration of just the steps you choose.

A CI job fails, and the run page says only "Process completed with exit code 1." To learn why, you open the job, scroll through the log, and hunt for the one error that matters. When the failure is a policy denial, the rule that blocked the run and the reason its author wrote are in that log too, out of sight of the person reviewing the pull request. Atmos now reports a failed command as a CI annotation, so the reason appears on the run page.

The past year has changed how we build Atmos. Advances in AI have accelerated our development and helped us bring many new capabilities to the project. Some needed more time and real-world experience before they were ready for broad adoption. We introduced the experimental designation to make that maturity visible and help you decide which features were ready for everyday use.

Since then, we, our customers, and the community have put many of these features to work in production. That use has brought valuable feedback. Interfaces have stabilized, functionality has been validated, and feedback has increasingly shifted from critical problems toward refinements and nice-to-haves.

We're graduating Atmos CI, Atmos Auth, Atmos Toolchain, Atmos Emulator, and source vendoring to stable. These capabilities have demonstrated stable interfaces and real-world use; this release formalizes their supported status. Other features will keep the experimental designation while we continue assessing them.

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.

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.

Some components need privileged credentials or manual approval. Others need network access that the CI runner lacks: a private VPC, a peering connection, or access to an internal service. Selectors let you leave those components out of a workflow and run them where the required access is available.

Moving build, test, and deploy pipelines out of GitHub Actions YAML and into Atmos custom commands removes a lot of glue, but one piece of it always came back. To tell the pull request what happened, the script had to shell out to gh, append to $GITHUB_ENV by hand, and print workflow commands for annotations. None of that works on a laptop, so the reporting half of a pipeline could only be debugged by pushing a commit and waiting for a runner.

Scripts written in the Atmos Automation Language now have a ci module that reports to the CI provider with one call each, and renders the same calls on your terminal when there is no provider.

Build, test, and deploy what changed. In a monorepo, that means identifying the affected projects and their dependents, then running the work that matters for that change.

The Atmos Automation Language lets you turn affected components and stacks into build, test, and deployment tasks. Write your project logic once and run it locally or in CI.

Pre-commit hooks put your team's standards to work on every commit. With AI agents generating more code, those automated checks matter even more. At Cloud Posse, we use them to enforce formatting, run linters, catch broken symlinks, and keep agent instruction files within size limits.

Atmos already manages Git hooks. Now you can write the checks themselves in the Atmos Automation Language, based on Starlark, and keep small checks inline beside the hook configuration.

Over the past year, we've used Atmos custom commands and workflows extensively at Cloud Posse. That experience keeps bringing us back to the code between the tools: the project-specific logic that turns individual commands into a delivery process. Much of it lives in shell scripts. We want to give it the same structure, reuse, and testing we expect from application code.

The Atmos Automation Language, based on Starlark, lets us write that logic with ordinary functions and structured data, call the capabilities Atmos already provides, and test it with Atmos itself.

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.

By default, --use-mocks now treats mocks as fallbacks. Real state wins whenever it exists, and a mock fills in only for a component that has not been provisioned or an output that is missing.

Waiting for each component download to finish before the next begins adds up in large repositories. Atmos vendoring now prepares independent packages concurrently and shows their progress together, while keeping destination writes in declaration order.

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 after a real change — a new provider, an updated module, a different backend. Repeating that same work before every single command, whether or not anything changed, adds real time to a workflow: provider downloads, backend re-initialization, module resolution, all over again for a component that's identical to how it was a few seconds ago.

GitHub Actions is the most popular way teams run Atmos in CI, and a lot of those pipelines are still calling into the original cloudposse/github-action-atmos-* actions. Those actions were the recommendation for years. They're no longer where investment goes — Native CI replaced them with a more capable, end-to-end-tested integration. Plenty of teams don't know it exists, let alone that the actions they're on are effectively on life support.

Even teams already on Native CI run into a quieter version of the same problem: a setting that doesn't take effect looks exactly like one that does. Maybe ci.enabled is set on one profile but not another, or an Atmos Pro workspace never got configured in the first place — nothing errors either way. The pipeline finishes green, and the first symptom is a status check or an upload that isn't there, discovered days later.

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.

Centralizing shared configuration in one private Git repository, and reusing it across projects, is not a new idea. Mergify and Dependabot both support extending a project's configuration from a shared repository. Doing the same for a general-purpose tool usually means a git submodule or subtree, and both are cumbersome. Atmos supports this natively: a project's atmos.yaml or stack manifest adds a remote import, a git:: URL that points at the centralized repository, with no submodule or subtree involved.

Resolving that import still had rough edges. Git fetch authentication was separate from a developer's GitHub CLI session, so gh auth login alone was not enough for a private import. A broken import failed silently: a tag name with a typo, an unreachable host, or a token without read access all added nothing to the configuration, with no warning. And a git:: import with a subdirectory re-cloned on every single command, even when nothing had changed.

Atmos already reused a developer's GitHub CLI session for other GitHub operations, such as toolchain installs. Atmos now reuses that same session for private git:: imports too. This applies to both stack configuration imports and atmos.yaml configuration imports. Atmos also warns you when an import fails. Atmos also lets you cache imports to avoid unnecessary re-fetching.

Bootstrapping Terraform state on Azure has always meant a detour outside Terraform: before you can run a single plan, you have to hand-create a resource group, a storage account (with the right TLS, public-access, and auth settings), and a blob container — by portal, az script, or a one-off Terraform component you cold-start and then migrate. AWS users have had one-line automatic backend provisioning for a while. Azure users had a checklist. Not anymore.

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.

Atmos now supports component mocks: literal, component-owned Terraform outputs that you enable explicitly with --use-mocks.

Pinning a CLI tool to an exact version is good practice — until it's time to move forward. Then it means opening .tool-versions by hand, going to check the tool's release page, picking a version, and editing the line yourself. Get it wrong and you're stuck rerunning install commands to find out.

Before you install a skill, you want to read what it does. Atmos agent skills did not let you do that. You had to install a skill first to read its full instructions. Or you had to find its file in the Atmos repository on GitHub. An AI agent had the same problem. No page listed every skill with its full content. No single URL let an agent fetch a skill's content on its own.

If you've ever tried to move a Taskfile.yml over to Atmos, you've hit the gap: deps: had no clean equivalent in custom commands, sources:/generates: up-to-date checking didn't exist at all, and a failed lint step stopped your whole release pipeline even when you just wanted to see every check's result. So teams ended up running two tools side by side — go-task for the parts Atmos couldn't do, Atmos for everything else — instead of one.

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: a hand-maintained list of stacks, a loop of atmos terraform apply calls, and a prayer that the ordering comments are still true. Atmos now does this natively: --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.

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.

tfmigrate turns these state changes into migration files that you store under version control. Atmos runs these files for you — manually from the CLI, or automatically from Terraform lifecycle hooks — in the same component context as atmos terraform plan and apply.

atmos terraform migrate plan s3-bucket -s plat-ue2-dev
atmos terraform migrate apply s3-bucket -s plat-ue2-dev

Large repositories often have validation rules that are useful but expensive or noisy to run across every file on every pull request. That makes it tempting to skip validation exactly when a focused signal would be most helpful.

Atmos can now validate the files affected by a change, so pull requests get actionable feedback without rechecking unrelated project inputs.

Initializing a project should establish a useful local starting point, not leave a developer with an empty directory and a list of conventions to reconstruct. Modern development platforms provide an initialization workflow: developers select a known-good example or template, create the project locally, and make the next action obvious. Atmos provides that workflow for infrastructure projects.

The atmos init command initializes an Atmos project from a template chosen for the job at hand: a minimal cloud-agnostic project, an AWS application SDLC project, or a cloud landing zone. Each template creates the configuration, structure, and operational path appropriate to that project rather than asking every team to assemble it from scratch.

Platform teams build golden paths so application teams can begin with the right architecture, guardrails, and operational conventions. A GitHub template repository is an excellent way to distribute that starting tree, but its job ends at the copy. It cannot ask project-specific questions, apply a policy to CI-supplied answers, tailor the file set, or evolve the template without every team manually reconciling a fork.

Atmos scaffolds turn a golden path into an executable contract. Use a local template, register one in atmos.yaml, or point to a Git repository—including a GitHub template repository—and let the same template guide developers, automate CI, and evolve with the platform.

Creation is only day one. Golden paths accumulate improvements after projects have adopted them: updated CI conventions, guardrails, shared configuration, and boilerplate. Atmos scaffolds include an optimistic three-way merge process so a project can take those upstream improvements without blindly replacing the custom work that happened after initialization.

Installing every tool a repository might eventually need makes project setup slow and wasteful. Atmos toolchain proxies provide on-demand, just-in-time installation instead: invoking a configured command resolves its pinned version and installs that binary only when it is first needed. The first invocation pays the download-and-prepare cost; later invocations reuse the installed release.

Proxies also make subcommands first-class executable names. A command-named link points back to Atmos; when it is invoked, Atmos reads the executed name, finds its proxy configuration, and runs the configured tool with its prefix arguments and the caller’s arguments. A multicall tool such as uutils/coreutils can therefore expose coreutils ls as the normal ls command—without shell aliases, copied shims, or a different invocation in every repository.

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 have had one option: fetch the JSON Schema from atmos.tools over the network and hope it matches whatever atmos binary you actually have installed. There was no way to just ask your own binary for its schema.

Upgrading the atmos binary has always meant upgrading your schema validation too, whether you wanted to or not. The JSON Schema published at atmos.tools/schemas/atmos/atmos-manifest/1.0/... is a single, mutable file — every merge to main updates it in place. Bump the binary without touching your stack YAML, and the schema underneath your atmos.yaml pin can still change: fields you haven't reviewed yet suddenly validate, or a schema you were relying on to reject unreleased fields quietly starts accepting them.

Package managers normally let you discover available updates, review their impact, and apply them locally. Vendored Atmos components did not: the only updater was a GitHub Action, so there was no native way to run that workflow from your workstation before opening a pull request.

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.

Interactive steps now fall back to their default value when there is no TTY, so the same workflow runs unattended in CI — no duplicate variant required.

Start with the recording.

That is the point of this update: the docs now have short terminal casts for the parts of Atmos that are easier to understand by watching them run.

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.

The result is easier to read, easier to review, and keeps the same recursive merge behavior that existing custom commands rely on.

Atmos can now read and edit your YAML — atmos.yaml, stack manifests, and vendor.yaml — through first-class commands that preserve comments, anchors, YAML functions, and Go templates. No more sed or yq one-liners that strip your comments and reformat the file.

Atmos can now record terminal sessions as asciicast files and render them into shareable formats for documentation, demos, and CI artifacts.

atmos cast render demo.cast --output=demo.gif
atmos cast render demo.cast --output=demo.html
atmos cast render demo.cast --output=demo.out --format=html

The render command turns a recording into a rendered artifact — here it's converted straight to a GIF:

Replaying a recording in the terminal with play reproduces it exactly as it was captured:

And any command can capture its own session as it runs with --cast, no separate recording step required:

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.

Topic-specific help fixes that by making default help focused, while keeping usage examples, command flags, and the full reference one flag away.

Atmos now builds itself through a first-class Atmos command:

atmos build --target linux

We replaced the old Make-based build and CI entrypoints with Atmos custom commands to improve the developer experience and dogfood our own workflow engine. Build and test workflows now expose the flags developers actually care about, such as the target platform, while Atmos owns the shell details, cross-compilation wiring, output paths, and CI glue behind the command.

Atmos help output now separates built-in commands from custom commands, and error output now makes explanations easier to scan without adding extra headings.

Terraform's native testing framework (*.tftest.hcl) is great — until you hit a run block with command = apply. Those blocks create real infrastructure, so running them means a cloud account, credentials, and spend. Atmos now lets you point terraform test at a local emulator, so the same apply-backed tests run for free and hermetically on your laptop or in CI.

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.

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.<name> }}, 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 official Atmos agent skills are now embedded directly in the Atmos binary. atmos ai skill install <name> 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.

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 auth login now performs one browser interaction per AWS SSO portal, no matter how many aws/iam-identity-center providers in your atmos.yaml point at it. Cached tokens also refresh silently for the full ~8-hour portal session window — no more re-prompt every hour.

--use-version now accepts a ref: prefix, so you can run the latest build of any branch or tag — like ref:main — without looking up a commit SHA.

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.

A common question from the community is: how do I use Atmos with Packer to build AMIs, and automate the whole build → approve → share process? We've published a new gist that shows exactly that — a reference recipe combining several Atmos features into one production-shaped workflow.

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 hooks now have a kind system — the same before.terraform.plan / after.terraform.plan lifecycle you already know, but the dispatch is pluggable and built-in kinds ship for common tools. Two lines in a stack manifest gets you cost analysis from infracost, or SARIF scanning from checkov, trivy, or kics, with tools auto-installed via the Atmos toolchain.

components:
  terraform:
    vpc:
      dependencies:
        tools:
          checkov: "3.2.529"
      hooks:
        security:
          events: [after.terraform.plan]
          kind: checkov

That's the whole config. No scanner binary on PATH, no custom command wrapper, no GitHub Actions glue — atmos terraform plan vpc -s prod auto-installs checkov via the toolchain, runs it against the component, parses the SARIF, renders the findings as a markdown table in your terminal, and (when Atmos Pro is connected) ships the same body to the run page.

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 ATMOS_LOGS_LEVEL=Debug in your workflow YAML.

Claude Code, OpenAI Codex CLI, and Google Gemini CLI all speak MCP, but each wants its own config format, its own credentials flow, and its own idea of where binaries live. This post shows how to centralize all of it — server configuration, AWS credentials, and toolchain version — in one atmos.yaml that every AI coding assistant uses unchanged.

Atmos Auth is the only place AWS credentials live; each MCP server is automatically wrapped with the right identity for the question it'll answer (billing → payer account, CloudTrail → audit, IAM → root, workload queries → dev/rpg/staging). One atmos auth login covers them all — no API keys in CLI configs, no AWS_PROFILE swapping between prompts. The server set spans the Atmos MCP server for project stacks, the AWS MCP server suite for live cloud queries, and the Atmos Pro MCP server for drift, deployment, and audit history. The Atmos toolchain pins binaries so every assistant runs the same binary. See the example: examples/mcp-for-ai-coding-assistants/.

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

Every atmos list subcommand that processes stack manifests now accepts --skip <yaml-function> and the matching ATMOS_SKIP env var, mirroring the surface already exposed by atmos describe affected, atmos describe component, and atmos describe stacks. Use it to bypass a single YAML function while leaving the rest of YAML function processing — including !template — fully enabled.

Every atmos list subcommand that processes stack manifests now accepts --process-templates and --process-functions (with matching ATMOS_PROCESS_TEMPLATES / ATMOS_PROCESS_FUNCTIONS env vars), matching the flag surface of atmos describe affected and atmos describe stacks. Defaults are true across the board.

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.

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

Add --ai to any Atmos command and get instant AI-powered analysis of the output. Successful plans get summarized, errors get explained with step-by-step fixes — zero workflow changes required.

Atmos now supports a global templates.settings.ignore_missing_template_values option in atmos.yaml, eliminating the need to set ignore_missing_template_values: true on every individual catalog 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.

Unlike general-purpose AI coding assistants, Atmos AI has deep, native understanding of Atmos stacks, components, inheritance patterns, and infrastructure workflows. It's not just an AI that knows about code—it's an AI that truly understands your infrastructure.

With support for 7 AI providers (including local/offline Ollama), persistent sessions with full conversation memory, tool execution with granular permissions and persistent permission cache, specialized skills for specific tasks, and seamless IDE integration via MCP—Atmos AI brings the productivity patterns of industry-leading AI systems to infrastructure management.

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.

Atmos LSP provides comprehensive Language Server Protocol integration that transforms how you write and validate Atmos configurations. Get instant feedback on errors, autocomplete for Atmos keywords, hover documentation without leaving your editor, and seamless integration with external language servers for YAML and Terraform validation.

With support for 13+ editors (VS Code, Neovim, Zed, Cursor, Emacs, and more), multiple transport protocols, and deep AI integration—writing infrastructure configuration now feels like writing code in a modern IDE.

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.

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

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.

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.

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

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 automatically detects when your AWS IAM User credentials have been rotated or revoked and prompts you for new credentials inline. No more persistent authentication failures after credential rotation. Plus, improved guidance when credentials expire.

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

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

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.

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.

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.

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.

Atmos lets you model your cloud architecture, so why shouldn't you be able to easily explore that? This is especially a pain point for people new to a team who just want to see what exists without having to understand your complete cloud architecture. Atmos List makes that possible.

We've enhanced all column-supporting list commands (instances, components, stacks, workflows, vendor) to support customizable output columns via atmos.yaml configuration.

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.

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.

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.

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

Tab completion for the --stack flag is now context-aware, filtering suggestions based on the component you specify.

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.

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.

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

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.

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