232 posts tagged with "Feature"

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.

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.

Give your team one command to build, ship, and deploy containers, whether they run it locally or in CI. Write your release tool in the Atmos Automation Language, a Python-like DSL based on Starlark, and run it with atmos ./release.star. Compose image builds, registry pushes, deployments, and checks using your existing Atmos configuration.

The same approach works for inventory reports, deployment checks, and other CLI apps. Atmos supplies the interpreter, typed flags, generated help, and automation functions so you can focus on the work your tool performs.

Your app can install pinned tool dependencies, run commands under configured cloud identities, and execute independent tasks in parallel. Return structured data for other tools to consume, and use error builders to report failures with explanations, hints, and examples through Atmos's own error formatting and reporting.

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.

Native Helm releases in Atmos now capture that evidence at the moment of failure and fold it straight into the error: which pod is failing, what the container is reporting, and - at debug level - the crash log and recent events.

Build, ship, and deploy containers the same way locally and in CI. The Atmos Automation Language is a Python-like DSL based on Starlark for writing that process as reusable, testable code. Compose image builds, registry pushes, deployments, and checks using your existing Atmos stacks, identities, and toolchain.

Install pinned tool dependencies, assume configured identities, call Atmos commands and external tools, and parallelize work with retries and timeouts. Combine scripts with native prompt steps, pass structured results between steps, and give users Atmos's formatted output and actionable errors.

Keep the release logic in your project and have developers and CI invoke the same command. Atmos supplies structured data, command execution, parallel tasks, and test steps, reducing the shell plumbing you maintain as Bash scripts grow.

For standalone .star apps with their own arguments and help, see the Atmos interpreter announcement.

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.

Native Helm components now expose the two Helm 4 controls that resolve this - server_side_apply and force_conflicts - as release-policy settings and command-line flags, so a conflict clears in the normal atmos helm apply path.

Templates change over time: a file that made sense when you first generated your project gets renamed, split up, or just stops being relevant. Most codegen tools treat that evolution as something only a brand-new scaffold run can fix — your existing project just keeps carrying the leftover file forever. And if you'd deleted that file yourself to clean up, the next update used to bring it right back, overwriting the choice you'd already made.

Two fields in the same scaffold template often need the exact same list of choices — a license picker and a region list are both really just "options sourced from some small reference table." Until now, that table had nowhere to live but inside scaffold.yaml itself, copied into every field that needed it. And a value as simple as the current git branch, an environment variable, or a random suffix had no path into a template at all, short of prompting the user for it by hand.

More and more Azure resource roles are handed out as PIM-eligible rather than standing: you hold the role only after you activate it, for a time-boxed window, with a justification. That activation is a multi-step REST dance against Azure Resource Manager - enumerate what you are eligible for, file a self-activation request, then poll until it provisions - and there is no native az command for activating an eligible Azure resource role. So every working session starts with hand-rolled az rest calls or a third-party script before you can actually run anything.

Running --update against a generated project is supposed to save you from re-doing your own customizations by hand. But once your local changes and the template's own changes overlap enough — more than half of a file's lines, by the merge's own accounting — the merge doesn't hand you conflict markers to work through. It refuses outright, with no way to say "I understand, show me the conflict anyway."

Finding the stack, component, and team behind a failed infrastructure command can require piecing together several CI logs. Atmos can now report CLI failures to Atmos Pro with execution context and your existing metadata tags and labels.

A scaffold template's spec.fields[] questionnaire is great at collecting answers, but not every value a template needs is really an answer. Some values are just a function of other answers — "the primary region, defaulting to the only region when there's just one" — and until now, every file that needed that value had to re-derive it itself, with the same {{ if .Config.primary_region_select }}...{{ end }} snippet copied into each one.

A scaffold template's spec.files[] entries have always matched one discovered file at a time — every file that needed gating or duplicating got its own entry, one path: per file. That's fine for a handful of files. It breaks down the moment the thing you want to skip or duplicate is a whole directory: a legacy docs tree gated behind an opt-in answer, or a components/ tree that needs to exist once per environment, region, or tenant. Either case meant repeating the same when: or the same matrix: on every file inside the directory, one entry per file, kept in sync by hand as the directory grew.

The AI model landscape moves faster than any single vendor's roadmap. A model that was the obvious choice last quarter is often outclassed - or undercut on price by an order of magnitude - by one you hadn't heard of this quarter. Locking your infrastructure assistant to one vendor's API means you either overpay or miss out, and for teams outside the US, a US-only provider list can be a non-starter entirely.

If you already drive your infrastructure work through a terminal coding agent, paying for a separate AI API key just to ask Atmos a question is redundant. You've authenticated the agent once, picked your model provider there, and you'd rather Atmos reuse that setup than make you manage a second set of credentials.

Bringing a generated project or component forward when its template changes means computing a three-way merge: what changed in the template since you last generated, layered onto whatever you've customized locally. That merge needs a base — a snapshot of what the template looked like at the point you started from — and the obvious place to find one is the project's own commit history. But not every generated project has intact history to read: it might not be a Git repository at all, its history might have been squashed or rewritten by a different tool, or it might simply be old enough that the base commit no longer exists on any reachable branch. Any of those and --update had nothing to work with.

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.

A successful deployment still needs checks that the application is healthy. Running those checks as ordinary commands can bury failures in successful logs or stop before the remaining tests run. The new test step collects the results, keeps passing output quiet, and reveals each failed check's logs.

Every CI runner — a GitHub-hosted tier or a self-hosted pool — has to be sized before a single job runs on it. Get it wrong small and jobs queue or get OOM-killed on a memory-hungry provider plugin; get it wrong large and every job pays for idle capacity it never touches. Nothing in a pipeline's output tells you which side of that line you're on.

An urgent image rollback, a temporary feature flag, or a one-off chart setting should not require editing a stack manifest just to make one deployment. Yet a preview is only useful when it renders the exact values that the later deployment will use. When temporary values live in a shell wrapper or are applied only at deploy time, teams cannot reliably see the change before it reaches a cluster.

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: GITHUB_SERVER_URL and GITHUB_API_URL are the same two variables GitHub Actions already exports on both public github.com and a GitHub Enterprise Server runner, precisely so that scripts and CLIs don't need special-casing.

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

A Helm values file, a docker-compose override, or any other hand-maintained YAML config often carries one field that tracks an external dependency's version, alongside comments explaining what the surrounding settings do and anchors sharing config between sections. Keeping that one field in sync usually means either editing it by hand on every release, or running it through a full parse-and- regenerate step that throws the comments and anchors away.

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 pays off if it works wherever the repository actually lives. A team standardized on Azure DevOps Repos instead of GitHub gets none of that: every vendor sync still ends in a manual PR, or a one-off script bolted on just to close the gap.

If your team already publishes container images, Atmos components, or Helm charts to a private OCI registry, that registry is probably the most secure, versioned, and well-understood distribution channel you have. Reusable project scaffolding rarely gets to use it — instead it tends to live in its own git repository, with its own access controls and its own line in the onboarding docs, just to hand out a scaffold.yaml and a handful of files.

Every interactive form with a fixed set of choices eventually hits the same problem: at some point, what a question should offer depends on how an earlier question was answered. List every possible environment when asking "which one deploys first," and people have to hunt through options they never actually set up. Show raw values like dev or prod just to avoid maintaining a separate label mapping, and people have to mentally translate those into what they actually mean. The only real fix is letting choices adapt to prior answers — and letting them look nicer than the underlying values.

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.

Terraform locks state before it writes to it, and by default it gives up the instant that lock is already held — no retry, no wait. That's fine for a single engineer running commands one at a time. It falls apart the moment two pipelines, or a pipeline and an engineer, touch the same component's state around the same moment: whichever process loses the race just fails, even though the lock would have cleared in a few seconds.

A custom command often needs to behave differently depending on how it was called — skip the destructive step on --dry-run, only run a cleanup step for a particular environment argument, or branch on whichever component the caller targeted. Doing that meant wrapping the command in a shell script that inspected $@ itself, because a step's when: condition had no visibility into the command's own --flag or positional argument values.

Plain JSON has no comment syntax, so there's nowhere to put an annotation telling a tool which field carries a managed version. Rewriting the whole file from a parsed structure works, but it reflows formatting, reorders keys, and turns a one-line diff into a noisy one. Neither option was a good fit for keeping a version field in a package.json, plugin manifest, or marketplace listing in sync with a locked dependency.

Naming things from memory is one of the more tedious parts of a CLI workflow. You know you want to switch configuration contexts before running a command, but you don't always remember every profile name your team has defined, especially on a project you don't touch daily. Until now, --profile required you to type that name exactly, or go check atmos profile list first and copy it over.

Using an Atmos-managed GCP identity with GKE used to stop one step short of the cluster. The identity could authenticate Terraform and other GCP clients, but operators still needed gcloud or gke-gcloud-auth-plugin to discover the cluster, write kubeconfig, and refresh Kubernetes credentials. Atmos now handles that complete path itself.

Every file a scaffold template declares renders at most once. when: can skip a file, but it can never multiply one. You could work around that by authoring every combination up front and letting when: prune down to what applies — but that only works if every combination is knowable in advance. It breaks down for environments picked interactively from a longer list, or names typed in by hand that no template author could have enumerated ahead of time. Until now, that meant hand-rolling files outside the template, or maintaining a pile of near-duplicate ones inside it.

Bring up two containers in the same environment and the first thing you hit is that they can't find each other. Docker's default bridge network hands out a private IP to each container but gives you no way to resolve a sibling by name, so you either hardcode IPs that change on every restart, or reach for docker network create and wire up the aliases yourself. Docker Compose solved this years ago by giving every project its own network and naming each service after itself. Atmos containers had no equivalent — every one landed on the default bridge, reachable only through published host ports.

Atmos scaffolds can perform genuinely complex three-way merges of YAML templates: keys can merge intelligently, and comments and local customizations are preserved when changes don't conflict. That capability comes from parsing YAML into a structured document and re-serializing it—and structured serialization is lossy by nature. Formatting that isn't part of the data model, like blank lines separating sections, doesn't survive the round trip. If your team treats that whitespace as a convention rather than noise, atmos scaffold generate --update (and atmos init --update) used to flatten it every time, whether or not the file had actually changed.

A pipeline runs a dozen Atmos commands across a dozen jobs. Something looks off — a plan that should have shown changes didn't, a command that used to take seconds now takes minutes. The only way to find out what actually happened is to open each CI job, scroll through raw log output, and reconstruct the timeline by hand. There was no automatic record of what ran, how long it took, or how much it cost.

A CI job deploying the dev stack shouldn't need to vendor every component in the repository -- just the ones dev actually uses. Production deploys have the same problem in reverse: pulling in components that belong to other environments wastes time and widens what that job can touch. Selecting the right subset meant either hand-listing every component with repeated --component flags or reaching for --everything and pulling in components the job has nothing to do with.

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.

Package managers normally tell you when an installed package is out of date and let you refresh just that one. Installed AI skills did not work that way: atmos ai skill install copies a bundled skill's content once, and upgrading the atmos binary afterward never touches that already-installed copy, even when the new release ships updated skill content.

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.

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

Atmos now supports the azure/interactive provider — the same interactive browser login az login uses (authorization code + PKCE on a localhost redirect). One command, atmos auth login, opens your browser, signs you in, and sets up everything Terraform and the az CLI need.

Reference architectures live for years. By the time you wire up a store hook, most of what it should cover was already deployed — some of it before hooks existed, some of it by a process outside Atmos entirely. Store hooks only ran after apply. To get an existing VPC ID or subnet list into a store, you had to force a fresh apply, or fall back to a manual write with a cloud CLI.

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.

For an introduction to defining and selecting tags and labels, see the original feature announcement.

Pulling a tool's version into a script usually means scraping decorated terminal output. A checkmark here, a color code there, maybe a table row — and now the one-liner that used to grab a version string needs a regex, a head -1, and a 2>&1 to work around output that was never meant to be parsed.

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.

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.

Stack manifests can now declare stack-wide metadata defaults that every component inherits, with the component's own metadata: still free to override them.

Large stacks eventually turn into a shared bottleneck. Network, platform, and application owners all need to contribute components, but putting every change in one manifest makes reviews noisy and parent-level configuration easy to accidentally share.

Atmos now lets multiple top-level manifests represent one logical stack while keeping each manifest's components and parent scope independent.

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

Getting kubectl and docker working against Azure resources has always meant a side trip through the Azure CLI. az aks get-credentials writes a kubeconfig entry — and for AAD-enabled clusters, the modern default, that entry calls out to a separate kubelogin binary just to mint a token. az acr login does the same dance for container registries. Both assume you're already logged into az, which may not match the identity you just authenticated with in Atmos.

Keeping vendored components current across dozens of repositories doesn't scale as a manual habit. Someone has to notice a new upstream release, edit the right version: field without breaking a comment or a template, then commit, push, and open a pull request. That has to happen for every component, on some kind of schedule, forever. Most teams either let it slip until something forces an update, or bolt on a third-party GitHub Action just to automate the commit-and-PR part.

Vendoring pulls external code into your own repository so it's reviewable, diffable, and not subject to an upstream registry going away. But once those files land on disk, nothing has watched them since. A teammate edits a vendored file directly to work around a bug. A pull can interrupt partway through. CI reuses a runner's disk across jobs. Every one of these leaves your checkout silently out of sync with what Atmos actually vendored. The first sign of trouble is usually a broken terraform plan weeks later — not the moment the drift happened.

Container image builds get slower as a Dockerfile grows, and CI runners rarely keep a warm local cache between runs. Teams work around this with a handful of docker/setup-buildx-action and docker/build-push-action steps that provision a builder and wire up a remote cache — glue that lives outside the rest of the pipeline and has to be reproduced in every workflow that builds an image.

The native container build step can now provision that builder and cache directly, so a build's caching strategy lives next to the rest of its configuration instead of in separate Actions.

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.

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.

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.

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.

A workflow can be valid YAML and still fail only after GitHub Actions tries to run it: a misspelled trigger filter, an invalid expression, or an action reference that does not make sense in context. Those failures are slow to discover and usually arrive after a push.

Atmos now includes GitHub Actions workflow validation as an experimental native-CI command. Run it from your workstation or in the workflow that it checks:

atmos ci validate

# Equivalent validation-oriented alias
atmos validate ci

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.

Atmos editions resolve that trade-off the way Rust did: defaults evolve for new projects, and existing projects opt into change on their own schedule. Pin your project to a date, and upgrading Atmos never silently changes a default again.

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.

Getting Atmos connected to an MCP server, or letting your AI assistant call Atmos's own tools, used to mean opening atmos.yaml and hand-writing a mcp.servers entry — then, separately, remembering which atmos mcp command actually pushes it into Claude Code, Cursor, or VS Code. If all you wanted was "let my AI assistant use Atmos," there was no single command that got you there.

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.

Tags and labels give components that organizational context directly — components get both; auth identities and providers get tags — so you can select and act on infrastructure by what it is instead of by where you filed it.

Packaging a directory into a deployable archive — most commonly zipping a Lambda function's source into handler.zip before terraform plan/apply — has always meant reaching for a shell-based hook that wraps the zip/tar binary. That works until you actually depend on it: the flags aren't even the same between BSD tar (macOS) and GNU tar (most Linux CI images), errors surface as opaque shell exit codes instead of anything typed, and — the part that's easy to miss — the archive you get back isn't reproducible. Build the exact same source twice and you get two different files. A new archive step type fixes all three: implemented on the Go standard library only, it behaves identically everywhere Atmos runs, validates its config before touching the filesystem, and can now produce byte-identical output for identical input.

A component with an oci:// source and provision.workdir.enabled: true failed the moment you ran any Terraform operation against it. JIT auto-provisioning (the before.terraform.init hook) failed 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.

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.

Your infrastructure's versions live everywhere except one place. actions/checkout@v4 in a dozen workflow files, TOFU_VERSION=1.9.0 in a Dockerfile, nginx:1.27 in a stack, kubectl wherever your bootstrap script says. When a version needs to move, you grep and hope. When it shouldn't move, nothing enforces that either — and every unpinned mutable tag is a supply-chain incident waiting for its moment. The Atmos Version Tracker gives all of those versions a single source of truth: 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.

See how independent dev and prod tracks resolve locked versions into stack variables, then update a dependency in dev without changing prod:

View the full example

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 now detects unsupported and misspelled YAML function tags before configuration processing continues. Invalid tags return a clear error with the supported Atmos YAML functions, so typos fail fast instead of being silently treated as ordinary YAML.

atmos git clone is Atmos's native replacement for actions/checkout. Mirroring the actions/checkout v7 hardening, it now refuses by default to clone untrusted fork content under the elevated pull_request_target and workflow_run events — the classic "pwn request" where fork code would run with your repository's secrets. A grep-able opt-in is available for the rare case you genuinely need it.

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 native CI is enabled. Use type: container workflow steps or atmos container build/push component commands and GitHub Actions gets a readable image report without adding a separate Docker summary action.

Atmos now treats Helm as a first-class component type. Define a Helm release — local chart, remote repository chart, or OCI chart — in your stack configuration, then template, diff, apply, and delete it through the Helm Go SDK. No helm or helmfile binary required. And because Atmos owns rendering, values, lifecycle events, and credentials, an apply can publish the rendered manifests to a Git deployment repository instead of a cluster — the producer side of a GitOps workflow.

For existing Helmfile users, we also added atmos helmfile template, which renders a Helmfile component to manifests and can deliver them to the same provision targets — closing the long-standing request in #2069.

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.

Atmos now treats Kubernetes as a first-class component type. Define Kubernetes objects — inline manifests, files, directories, or Kustomize overlays — in your stack configuration, then render, diff, apply, and delete them through the Kubernetes Go SDK with server-side apply. No kubectl or kustomize binary required. And because Atmos owns rendering, lifecycle events, and credentials, an apply can publish the rendered manifests to a Git deployment repository instead of a cluster — the producer side of a GitOps workflow.

Atmos lifecycle hooks can now run an ordered list of steps with kind: steps. Use it when one lifecycle event needs sequencing but the orchestration should stay local to the component being operated on.

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.

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.

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 terraform apply needs a real cloud account, costs real money, and touches a live environment. And in many enterprises developers don't have permission to the cloud at all, so they can't iterate locally even when they want to. Atmos emulators help with this: long-running, containerized stand-ins for AWS, GCP, Azure, Kubernetes, Vault, and an OCI registry that you provision as ordinary Atmos components — so you can run the full Atmos workflow (auth, secrets, vendoring, toolchain, and terraform apply) on your laptop, with no cloud account and no credentials.

Atmos hooks can now run any workflow step type. A new kind: step hook bridges the component lifecycle (before/after terraform plan, apply, deploy, init) to the same step registry that powers workflows and custom commands — so a container, toast, log, markdown, or http step you already use elsewhere runs identically as a hook.

Here's a kind: step hook wired to a custom command, running end to end:

View the full example

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: policy. No more shelling out to curl. (Prefer type: 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.

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 builds images, pushes them to registries, and runs containerized tools — Docker or Podman — through the same reusable step library that powers the rest of your automation.

Atmos now has a first-class container component kind. Where a type: container workflow step is a procedural docker run --rm, a components.container entry is declarative, stack-scoped infrastructure: one component is one service, with an image artifact Atmos builds/pushes/pulls and an optional long-running named container you operate with atmos container up/ps/logs/exec/restart/stop/rm/down. A new compositions section groups the components that make up a system.

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, provision their values per environment, and reference them at runtime with a single YAML function.

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 TF_CLI_CONFIG_FILE and TOFU_CLI_CONFIG_FILE — 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.

Atmos now supports before.terraform.init and after.terraform.init lifecycle hooks, and --skip-hooks is finally honored for before- hooks across plan, apply, and deploy.

Atmos now supports the !append YAML function, which adds items to an inherited list during stack merging instead of replacing it — giving you per-field control over list merging without changing any global setting.

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.

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 ref: prefix, so you can run the latest build of any branch or tag — like ref:main — without looking up a commit SHA.

Atmos adds a new template function, atmos.Resolve, that evaluates any Atmos YAML function — like !git.repository, !exec, !store, or !terraform.output — at template-render time. This lets you compose a YAML function's result with other strings and template variables in a single value.

Atmos custom commands can now define their own component types beyond terraform, helmfile, and packer. Use Atmos's stack configuration system with any tool: Ansible, Kubernetes manifests, shell scripts, CDK, and more.

Atmos now exposes Git repository metadata through dedicated YAML functions: !git.repository, !git.owner, !git.name, !git.host, and !git.url. These join the existing !git.root, !git.sha, !git.branch, and !git.ref 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 always meant handing a long-lived, over-privileged GitHub credential to your pipeline — a PAT, a machine user, or a deploy key, sitting in a CI secret. Atmos Pro STS replaces that with just-in-time, least-privilege, short-lived GitHub tokens that are minted at the start of a run and revoked at the end — with zero .tf changes.

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.

Those mappings make findings more actionable: instead of stopping at an AWS resource ARN, Atmos can show the owning stack, component path, severity, source service, and remediation context. With new SARIF 2.1.0 and OCSF 1.4.0 output, those findings can now flow into code scanning, SIEM, governance, risk, and compliance workflows without a translation layer.

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.

Atmos now supports importing stack configurations from remote URLs. Reference shared configurations from GitHub, S3, GCS, or any HTTP endpoint directly in your stack files.

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

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.

atmos describe affected --upload now works under GITHUB_EVENT_NAME=merge_group, so Atmos Pro can correctly conclude check runs on the synthetic commits GitHub creates when a PR enters a merge queue. To control what runs on those synthetic commits, declare a new settings.pro.merge_group.checks_requested.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 pull_request.synchronize).

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 sends your changes to Atmos Pro, which creates the commit using its GitHub App installation — ensuring commits trigger CI workflows.

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.

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 components and stacks that manage the affected resources, and generate structured remediation reports — all from a single command.

Atmos AI now supports CLI providers — invoke your locally installed Claude Code, OpenAI Codex, or Gemini CLI as AI backends. No API keys needed. Just use your existing subscription.

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. Configure any MCP server in atmos.yaml, and its tools appear alongside native Atmos tools in atmos ai chat, atmos ai ask, and atmos ai exec — no custom integration code needed.

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

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

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

Atmos now supports credential realm isolation, preventing collisions when engineers work with multiple customer repositories using identical identity names.

Atmos now automatically detects components and stacks that have been deleted in your current branch compared to the target branch. This enables CI/CD pipelines to trigger terraform destroy workflows for removed infrastructure.

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.

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

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.

Locals now support YAML functions like !env, !exec, !store, !terraform.state, and !terraform.output.

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

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.

Custom commands now support structured task syntax with per-step configuration including timeouts, retry logic, working directories, and authentication identities.

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 access to hundreds of pre-configured CLI tools without the overhead of external tool managers.

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.

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.

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

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.

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.

Atmos now includes four AWS YAML functions that retrieve identity and region information directly in stack configurations: !aws.account_id, !aws.caller_identity_arn, !aws.caller_identity_user_id, and !aws.region.

Atmos now supports using filesystem paths instead of component names for all component commands. Use . for the current directory, relative paths like ./vpc or ../eks, or absolute paths. This might feel more natural for users accustomed to running commands on folders rather than remembering specific component names.

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.

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

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

Different versions. Missing dependencies. Subtle configuration differences. Onboarding a new team member becomes a day-long exercise in installing and configuring tools. Something that worked perfectly on your laptop fails in CI. You spend more time managing your toolchain than actually using it.

Today, we're solving this problem once and for all with native Development Container support in Atmos.

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.

We've improved how Atmos handles YAML functions during merges across configuration layers. Atmos now postpones merging YAML functions until after the regular merge is done. This avoids the type conflicts that used to happen when a stack layer replaced a plain value—like a string, map, or list—with a YAML function such as a template or an output reference.

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.

We're thrilled to announce native Azure authentication support in Atmos! You can now authenticate to Azure using atmos auth login with device code flow, OIDC, and service principals - working identically to az login with full Terraform provider compatibility.

We've completely rebuilt Atmos error handling from the ground up to provide helpful hints, rich context, and enterprise-grade error tracking. When something goes wrong, you now get actionable guidance instead of cryptic messages, and enterprises can track and analyze errors across their entire infrastructure stack.

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

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.

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

We're excited to introduce atmos auth shell, a new command that makes working with multiple cloud identities more secure.

This command launches isolated shell sessions scoped to specific cloud identities. Think of it like aws-vault exec, but for all your cloud identities managed by Atmos—AWS, Azure, GCP, GitHub, SAML, and more.

When you exit the shell, you return to your parent shell where those credentials were never present. It's a simple pattern that helps prevent credential leakage and reduces the risk of running commands against the wrong environment.

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.

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