The Problem​

Atmos talks to a lot of TLS endpoints — cloud provider APIs, git servers, artifact registries, the Terraform module registry. Every one of those connections depends on the cryptography built into the Go runtime atmos is compiled with. Until now, nothing about that cryptography was validated or restricted to FIPS-approved algorithms; it just used whatever Go's standard library picked. Operators who needed a FIPS 140-3 claim for their toolchain had no way to get one from an official atmos release.

The Fix​

Every officially released atmos binary — along with every binary built from a checkout using atmos build — now links Go's own FIPS 140-3 crypto module and defaults to enforcing FIPS 140-3 mode at runtime. Go standard-library TLS connections, key generation, and hashing are restricted to FIPS-approved algorithms and key sizes automatically. No flag, environment variable, or config change is required.

This covers the TLS and cryptography atmos itself uses for outbound connections, and it's FIPS 140-3 mode — enforced by Go's runtime — not a CMVP compliance certification for the atmos binary itself. Declarative secrets management (atmos secret keygen and the age-based SOPS backend, along with the sealed values atmos pushes to GitHub Actions secrets) relies on its own encryption, chosen for compatibility with those specific ecosystems, and sits outside Go's FIPS module boundary entirely — worth knowing if your compliance program needs FIPS coverage across secrets handling too.

How to Use It​

Nothing to opt into — every current and future atmos release ships this way by default. To confirm it on any binary, ask atmos itself:

atmos version --format=json

{
  "version": "1.226.1",
  "os": "darwin",
  "arch": "arm64",
  "fips": true
}

If you'd rather check without atmos installed yet — say, auditing a downloaded binary — any standard Go toolchain can tell you the same thing:

go version -m ./atmos | grep -i fips

build   DefaultGODEBUG=fips140=on
build   GOFIPS140=latest

Get Involved​

Have feedback on this, or a compliance requirement it doesn't yet cover? Open an issue or join the conversation in the Cloud Posse community Slack.

The Problem​

Terraform, Helmfile, Kubernetes, and Helm components have always resolved their working directory the same way: a configurable base_path per component type, joined with the component's own name, computed once and used consistently no matter where atmos is invoked from. Container components never got wired into that mechanism. build.context and build.dockerfile were passed straight through to docker build/podman build with no anchoring at all, and run.mounts[].source anchored only to the bare project root — never to the component itself. components.container.base_path existed in the config schema, but nothing ever read it.

The Fix​

Container components now resolve build.context, build.dockerfile, and run.mounts[].source the same way every other component type does: relative to components.container.base_path (default components/container) joined with the component's own name, independent of the directory atmos happens to be invoked from. components.container.base_path is now a real, working setting. Container components also gained the same just-in-time source provisioning as Terraform and Helmfile components — a component that declares source: is now auto-vendored into a workdir, and that workdir becomes the anchor for build and mount paths instead of the static base path.

Breaking Change​

If your container component's build.context, build.dockerfile, or run.mounts[].source are relative paths, they now resolve against <base_path>/<component-name>/ instead of the previous CWD-dependent (build) or bare-project-root (mounts) behavior. Update your setup one of two ways: move build assets under components/container/<component-name>/ to match the same convention Terraform components already use, or point components.container.base_path at wherever your container build assets currently live.

How to Use It​

# atmos.yaml
components:
  container:
    base_path: components/container   # default

components:
  container:
    api:
      build:
        context: app           # resolves to components/container/api/app
        dockerfile: Dockerfile  # resolves to components/container/api/app/Dockerfile

Get Involved​

Try it out with an existing container component or a fresh one. Questions or ideas? Start a thread in GitHub Discussions, or open an issue in the issue tracker.

The Problem​

The Version Tracker's marker manager rewrites version tokens on lines annotated with an atmos:version comment — but JSON has no comment syntax, so there's no line to annotate. The template manager covers formats like this by rendering a *.tmpl source to a sibling output file, but that means maintaining a template and a generated file as two files that have to be kept in sync by hand every time an unrelated field in the JSON document changes.

The Fix​

A new json file manager writes locked values directly into JSON files at configured field paths. It patches only the targeted field and leaves everything else in the document — key order, spacing, unrelated fields — exactly as it was, so atmos version track apply produces a minimal, single-field diff instead of a fully reformatted file.

How to Use It​

version:
  dependencies:
    atmos:
      ecosystem: github/actions
      datasource: github-releases
      provider: github
      package: cloudposse/atmos
      desired: "~1.160"

  files:
    - manager: json
      paths:
        - package.json
      options:
        set:
          - path: version
            from: atmos

A single rule can target more than one file, and a single file can carry more than one managed field — each just needs its own path/from entry under set:

  files:
    - manager: json
      paths:
        - package.json
      options:
        set:
          - path: version
            from: cli
          - path: engines.node
            from: node

atmos version track apply rewrites every configured field from the lock; --check fails and lists any file that's out of date, so CI can catch drift before it merges.

Get Involved​

See the Version Files docs for the full path/from syntax, including array indexing and escaping keys that contain literal dots. Have feedback on this feature? Open an issue or join the conversation in the Cloud Posse community Slack.

The Problem​

--profile activates one or more named configuration overlays — dev settings, CI settings, security overrides, whatever a project defines. But the flag always required an explicit value. Typing --profile alone, expecting the CLI to prompt you the way -i/--identity already does when used bare, instead produced a raw usage error:

$ atmos auth login -i core-auto/terraform --profile
Incorrect Usage
Error: --profile flag needs an argument for command atmos auth login

The Fix​

--profile with no value now opens an interactive multi-select listing every profile Atmos discovers across your configured profile locations. Nothing is checked by default — toggle the ones you want with space, confirm, and they activate left-to-right in the order shown, exactly as if you'd typed them explicitly.

Any profile name you already typed alongside the bare flag starts pre-checked, so --profile ci --profile opens with ci already selected, ready to confirm or adjust. In a non-interactive context — CI, scripts, no TTY — bare --profile returns a clear error instead of hanging or guessing, so automation fails fast rather than silently.

How to Use It​

# Interactively choose which profiles to activate
atmos auth login -i core-auto/terraform --profile

# Explicit values still work exactly as before
atmos --profile developer terraform plan vpc -s prod
atmos --profile ci,security terraform plan vpc -s prod

Get Involved​

See the Profiles docs for the full behavior, including profile discovery order and merge precedence. Have feedback on this feature? Open an issue or join the conversation in the Cloud Posse community Slack.

The Problem​

type: container steps take their configuration under with: (and, for the driver, a nested driver: block) as a typed mapping — run, build, push, and inspect actions each have a fixed set of real fields. But nothing checked that the keys you wrote were actually among them. A typo'd field name, a field copied from Docker Compose that doesn't exist in Atmos, or a straight-up nonexistent option all decoded the same way: silently discarded, with the rest of the mapping loaded normally. The step would run — just without the setting you thought you'd configured.

The Fix​

with: and driver: blocks on container steps now reject unknown fields outright, in both standalone workflow files and custom commands. A typo like platforms: (not a real field) now fails the step with a clear decode error naming the field, instead of quietly doing nothing.

Breaking Change​

If a with: or driver: block on a type: container step currently has a field that isn't one of the real, documented fields, it will now fail to load instead of being silently ignored. Check your container steps for typos or leftover fields from a different tool's config format before upgrading.

Also in This Release: Local Backend State Was Being Deleted on Re-Provision​

If you used a local Terraform backend on a component with just-in-time (JIT) workdir provisioning enabled, your state was gone after the second run. Not corrupted — deleted, cleanly, with no error. apply would create it, and the very next plan would silently start over with an empty state, because the workdir provisioner's incremental sync treated the state file the same way it treats any file that isn't part of your component's source: not present in source, so remove it. terraform.tfstate was never protected from that cleanup the way provider lock files already were.

The workdir provisioner now leaves terraform.tfstate, terraform.tfstate.backup, and the transient .terraform.tfstate.lock.info marker alone, in both directions — never copied in from source, never deleted from the workdir. If you were working around this by avoiding JIT workdir provisioning for local-backend components, that workaround is no longer necessary.

Also in This Release: Workdir Path Encoding​

Separately, the internal .workdir/ directory Atmos uses for JIT component provisioning now encodes component and stack names more carefully, to guarantee two differently named components (e.g. one named app/local and another named app-local) can never accidentally resolve to the same on-disk directory and share files or state.

This changes the on-disk directory name for any component whose name contains a literal -, /, or \. Atmos migrates a workdir it finds at the old location automatically the next time that component is provisioned, so this should be transparent for most setups.

The Problem​

Atmos Auth already supports Application Default Credentials, Workload Identity Federation, and service account impersonation. GKE access still required a separate authentication flow outside Atmos, though. That created two sources of truth for identity selection and added external tools to local and CI environments solely to prepare kubeconfig.

The gap was especially visible with native Helm components: Atmos could resolve the intended GCP identity, but an ambient kubeconfig could still point Helm at a different cluster.

The Fix​

The new gcp/gke Auth integration links a GKE cluster to an existing GCP identity. When Atmos selects that identity, it uses the GKE API to discover the cluster endpoint and CA certificate, writes an Atmos-managed kubeconfig, and injects its path into child commands:

auth:
  providers:
    example-gcp:
      kind: gcp/adc
      spec:
        project_id: example-project

  identities:
    example-deployer:
      kind: gcp/project
      via:
        provider: example-gcp
      principal:
        project_id: example-project

  integrations:
    example-gke:
      kind: gcp/gke
      via:
        identity: example-deployer
      spec:
        cluster:
          name: example-cluster
          project_id: example-project
          location: us-central1
          alias: example

Run Kubernetes tools through the selected identity without a preparatory gcloud command:

atmos auth exec --identity example-deployer -- kubectl get nodes

The generated kubeconfig uses atmos gcp gke token as a Kubernetes exec credential plugin. Kubernetes requests a fresh short-lived token when needed; the token and its expiration are returned as ExecCredential JSON and are never stored in kubeconfig.

Guard Native Helm Targets​

Native Helm keeps its existing ambient-kubeconfig behavior by default. Components that must use an Atmos-provisioned GKE identity can opt into a fail-closed endpoint check:

components:
  helm:
    example-release:
      auth:
        require_identity: true
        identities:
          example-deployer:
            default: true

For live plan, apply, and delete operations, Atmos provisions the linked integration and verifies that Helm's effective Kubernetes API endpoint matches the endpoint returned by GKE before any cluster request. Offline template and manifest-baseline operations remain credential-free.

Security Boundaries​

• The kubeconfig stores the HTTPS endpoint, CA certificate, context, and exec-plugin command—not a bearer token.
• The GCP identity needs permission to describe the cluster, normally container.clusters.get.
• Kubernetes RBAC remains separate and determines what the authenticated principal may do inside the cluster.
• Explicit plaintext GKE API endpoints are rejected rather than written to kubeconfig.

See the GKE kubeconfig authentication command documentation for configuration, update modes, permissions, and troubleshooting details.

Get Involved​

Try the integration with your GCP identity chain and GKE clusters. Share feedback in the Cloud Posse community or open an issue on GitHub.

The Problem​

The number of files a project needs often depends on what gets selected when the project is generated. Pick three environments out of five, and you want three stack files, not five. That output was already possible: declare all five stack files in the template up front, and gate each one with its own when: on whether that specific environment got picked. The real cost was authorship — five nearly-identical files, one per environment the template author had to anticipate, kept in sync by hand as the shared parts drifted. Nothing let a template say "generate one of these per selected value" from a single file; only "generate this specific file" or "skip this specific file."

The Fix​

Declaring matrix: on a file entry expands it into one generated file per combination of one or more axes. It reuses the same shape Atmos workflow matrix: steps already use, so the syntax should feel familiar. when: still prunes combinations that don't apply — the same conditional engine that already gates whole files, now scoped to a single combination at a time:

spec:
  fields:
    - name: environments
      type: multiselect
      options: [dev, staging, production]
  files:
    - path: stacks/deploy/environment.yaml
      target: "stacks/deploy/{{ .matrix.environment }}.yaml"
      matrix:
        environment: answers.environments

Selecting dev and staging generates exactly stacks/deploy/dev.yaml and stacks/deploy/staging.yaml. Declaring more than one axis expands their full combination, and each resolved combination is available as .matrix.<axis> in Go-template fields such as the output path and generated content, and as matrix.<axis> in when: conditions — so a file can name itself and branch on its own combination.

Computed axes​

Real answers aren't always a flat, pre-selected list. Say environments were a structured answer instead of a multiselect — supplied through --set or a preset value — shaped like this:

environments:
  dev:
    regions:
      us-east-1: {}
  production:
    regions:
      us-east-1: {}
      us-west-2: {}

The full list of regions actually used isn't something anyone picked directly — it has to be derived from every environment's own regions. The collectKeys function does that: called with one argument, it returns a map's keys; called with a second argument, it collects that key from every value in the map, flattening and deduplicating across all of them.

files:
  - path: deploy.yaml
    target: "deploy/{{ .matrix.environment }}/{{ .matrix.region }}.yaml"
    matrix:
      environment: '{{ collectKeys answers.environments }}'
      region: '{{ collectKeys answers.environments "regions" }}'
    when: "matrix.region in answers.environments[matrix.environment].regions"

environment resolves to dev and production; region resolves to every region used by any of them (us-east-1 and us-west-2). Their combination fans a single deploy.yaml out into deploy/dev/us-east-1.yaml, deploy/production/us-east-1.yaml, and deploy/production/us-west-2.yaml — target: names each one from .matrix.<axis>, and when: prunes the combination down to each environment's actual regions, so dev never gets a us-west-2 file.

How to Use It​

The scaffolding-matrix example is a minimal, runnable template — one multiselect field driving one matrix axis:

cd examples/scaffolding-matrix
atmos scaffold generate example ./my-project

Answering the environments prompt with dev and staging generates stacks/dev.yaml and stacks/staging.yaml from the template's single environment.yaml file — or skip the prompt entirely with --set environments=dev,staging for scripted, non-interactive use. Add matrix: to any spec.files[] entry alongside target: to do the same in your own templates, using a literal list, a multiselect answer, or a computed expression for each axis.

Get Involved​

See the atmos scaffold generate docs for the full reference, or open an issue with feedback.

The Problem​

A container component's run config could publish ports to the host, but two container components in the same stack — or a container and a local emulator — had no way to talk to each other directly. A workflow step that spun up a one-shot container to run tests against those services hit the same wall. The only fix was manual: create a network by hand, or fall back to routing everything through the host.

The Fix​

Every container component, one-shot container run, and stack-scoped workflow type: container step now automatically joins a shared network for its stack and gets a predictable DNS alias — no configuration required. It's the same idea as the network Docker Compose creates for a project, scoped to your Atmos stack instead.

• A component named api in stack dev is reachable at dev-api.
• An emulator and a container component in the same stack land on the same network, so either can resolve the other by name.
• A workflow run step that resolves a stack (its own stack: field, or the workflow's --stack/ATMOS_STACK) joins that same network too, so a test-runner step can hit http://dev-api:80 directly.

It's best-effort: if the container runtime can't create or join a network, everything still runs — you just lose the ability to resolve peers by name, and host-published ports keep working exactly as before.

How to Use It​

Nothing to turn on. Bring up two services in the same stack and reference one from the other by its <stack>-<component> alias:

components:
  container:
    api:
      image: localhost:5001/api:latest
      run:
        ports:
          - host: 8080
            container: 80

    worker:
      image: localhost:5001/worker:latest
      run:
        command: ./worker --api-url=http://dev-api:80

atmos container up api -s dev
atmos container up worker -s dev
# worker resolves dev-api on the shared network — no host port juggling needed.

The same alias works from a workflow run step scoped to the same stack:

steps:
  - name: smoke
    type: container
    action: run
    stack: dev
    with:
      image: curlimages/curl
      command: curl -f http://dev-api:80/health

Get Involved​

Try it out with a couple of container components or an emulator in the same stack. Questions or ideas? Start a thread in GitHub Discussions, or open an issue in the issue tracker.

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.

The Problem​

• Git fetch authentication was separate from GitHub CLI authentication. A private git:: import used its own credential chain. This chain did not include the GitHub CLI. A developer who ran only gh auth login still needed a separate token for private imports to work.
• A broken import failed with no warning. A typo in a ?ref= value, an unreachable host, or an unreadable private repository all produced the same result. The import added nothing to the configuration. No error appeared. The command exited successfully.
• Every command re-cloned a git:: import. A root atmos.yaml import that pointed at a subdirectory in a Git repository had no cache. A command as simple as checking the current identity re-cloned the remote repository first.

The Fix​

• Private git:: imports now fall back to a developer's GitHub CLI session automatically. This covers config imports, vendoring, and private Terraform module fetches. Atmos already used this fallback for other GitHub operations. If gh auth login is already done, no other setup is needed.
• A remote import: entry that fails to resolve now prints a warning by default. The warning names the import path and the underlying error. The command no longer continues silently with an empty or partial configuration.
• Set imports: { ttl: ... } once in atmos.yaml to apply the same expiry policy to every remote import form. A git:: import with a subdirectory then reuses its clone across commands instead of re-cloning every time. A plain remote URL, or a git:: import without a subdirectory, then expires after ttl instead of being cached forever. The two forms track freshness differently under the hood (a marker file in the cloned directory for the first, a cache entry for the second), but ttl now governs both.

How to Use It​

Sign in once. Private imports then work automatically:

gh auth login

If an import breaks, Atmos reports it immediately:

WARN  failed to resolve import path="git::https://github.com/acme/config.git//auth.yaml?ref=v1.2.3" error="..."

Set a cache TTL to stop re-fetching a stable, pinned git:: import on every command:

imports:
  ttl: 5m

import:
  - "git::https://github.com/acme/config.git//auth.yaml?ref=v1.2.3"

Leave ttl unset to keep each import form's default: a git:: subdirectory import refreshes on every command, and a plain remote URL is cached forever. Set ttl once to apply the same expiry to every remote import in the file, of either form.

Get Involved​

Did you find another case where a remote import fails silently? Did you find an operation where GitHub CLI auth does not reach, but should? Open an issue. Include the command and the result you saw.

The Problem​

--update re-runs a template against an existing project and 3-way merges the result. Scaffold picks its merge algorithm by file extension: YAML-aware for .yaml/.yml, line-oriented text for everything else. The YAML-aware path is what makes the complex merges possible in the first place—but re-encoding the whole document through a YAML parser and serializer means anything the parser doesn't model, blank lines between top-level blocks being the common case, gets dropped unconditionally. That's a real cost for files where formatting is a convention—many CI pipeline definitions use blank lines to visually separate jobs, stages, and other top-level blocks.

The Fix​

--merge-driver lets you override which merge algorithm runs, named after git's own merge driver concept:

• auto (default, unchanged) — YAML-aware for .yaml/.yml, text otherwise.
• text — forces every file, YAML included, through a line-oriented, diff3-style merge. Comments, blank lines, and other structural formatting the YAML-aware merger doesn't model are preserved in non-conflicting regions.

Because it's a flag on the --update invocation itself, not a project-wide setting, you're not choosing one mode for the project's entire lifetime. Most updates can stay on the default auto merge, and you reach for --merge-driver=text on the specific update that needs it—bundle up a template's formatting-sensitive changes (a CI pipeline overhaul, say) and pull them in with one deliberate --merge-driver=text run, rather than running every future update through the coarser text merger just to protect that one file.

This is a different axis from --merge-strategy, which decides how a genuine conflict resolves (manual, ours, or theirs) once a merge algorithm has already run. --merge-driver decides which algorithm runs in the first place.

How to Use It​

# Everyday updates: the default auto merge is usually what you want.
atmos scaffold generate my-template ./my-project --update

# This update brings in a batch of formatting-sensitive template changes—
# override the driver just for this run.
atmos scaffold generate my-template ./my-project --update --merge-driver=text
atmos init --update --merge-driver=text

Get Involved​

See the atmos scaffold generate and atmos init docs for the full flag reference. Have feedback on this feature? Open an issue or join the conversation in the Cloud Posse community Slack.

The Problem​

Scoping a vendor pull to "just what this stack needs" is a selection CI reaches for on every deploy, not an occasional convenience. Without it, the choice was between hand-listing every component or vendoring the entire repository. Neither scales, and neither composes: picking components by tag, by name, and by the stack they belong to used to be three separate, mutually exclusive modes rather than filters that could work together.

The Fix​

atmos vendor pull now accepts --stack and --labels selectors, and --tags composes with either of them (or with --component) as an independent, narrowing filter -- across pull, diff, clean, update, and verify alike:

• --stack vendors every component declared in that stack that has its own component.yaml.
• --labels filters that eligible stack component set by each component's stack metadata.labels.
• --tags narrows whichever set --stack/--labels (or --component) resolved, down to components whose declared source tags match.

Combining selectors that don't overlap now fails with a clear error instead of silently matching nothing or falling back to a different set than you asked for.

How to Use It​

# Vendor each stack component that has a component.yaml
atmos vendor pull --stack plat-ue2-dev

# Select by stack metadata.labels instead of stack name
atmos vendor pull --labels tier=1,cost-center:platform

# Narrow a stack selection further by declared tag
atmos vendor pull --stack plat-ue2-dev --tags networking

# Preview instead of pulling
atmos vendor pull --stack plat-ue2-dev --dry-run

The same selectors work on the other vendor subcommands:

atmos vendor diff --stack plat-ue2-dev --tags networking
atmos vendor update --labels tier=1 --check
atmos vendor clean --stack plat-ue2-dev
atmos vendor verify --labels tier=1

For atmos vendor pull, --stack/--labels install each matched component from its own component.yaml, bypassing vendor.yaml entirely -- components without one are skipped, and if every matched component lacks a component.yaml the command succeeds having pulled nothing. It only fails with the shared selector's "no components matched" error when --stack/--labels itself resolves to no stack, or when --tags narrows an already non-empty selection down to zero. --component still selects a single, explicitly named component and isn't combined with --stack/--labels, but composes with --tags the same way they do. diff, update, clean, and verify use the same selectors to resolve component names, but retain their own manifest-resolution rules (vendor.yaml first, falling back to component.yaml).

Get Involved​

Have feedback or ideas for vendor improvements? Join our Slack community or open an issue on GitHub.

The Problem​

Atmos could already generate backend.tf.json for an azurerm backend and read its state in-process — but it couldn't create the backend. Turn on backend auto-provisioning against an azurerm backend and nothing happened; it silently skipped, because provisioning only knew how to make S3 buckets. So every new subscription hit the same chicken-and-egg: you need remote state to run Terraform, but you need something other than Terraform to create that remote state first.

The workaround was a bespoke storage-account component that runs on local state, then migrates its own state into the account it just created. It works, but it's ceremony every team re-invents — and it's exactly the friction AWS users don't have.

The Fix​

Atmos now provisions azurerm backends automatically, the same way it does for S3. Point a component at an azurerm backend, enable provisioning, and Atmos creates what's missing — the resource group, the storage account, and the container — with secure defaults, before terraform init runs.

Everything is created with opinionated, hardcoded best practices:

• TLS 1.2 minimum and HTTPS-only traffic
• Public blob access blocked; the state container is private
• Blob versioning enabled — the direct analog of S3 versioning, so every state write is recoverable
• Soft delete (blob + container) with 30-day retention as a safety net
• Entra ID hardening: when your backend sets use_azuread_auth: true, the storage account is created with shared-key access disabled — no account keys to leak

And one thing Atmos deliberately does not create: a lock table. On Azure, state locking is built into Blob Storage — the azurerm backend takes an exclusive blob lease on the state blob during each operation, so concurrent runs are serialized with no extra resource. (On AWS that role is played by a DynamoDB table or native S3 lockfiles; on Azure there's simply nothing to provision.)

How to Use It​

Add provision.backend.enabled: true to a component that uses an azurerm backend:

components:
  terraform:
    vpc:
      auth:
        providers:
          azure:
            type: azure/interactive
            identity: platform

      backend_type: azurerm
      backend:
        resource_group_name: rg-tfstate-cus
        storage_account_name: stexampletfstateplatformcus
        container_name: tfstate
        key: vpc.terraform.tfstate
        use_azuread_auth: true

      provision:
        backend:
          enabled: true

Then run Terraform as usual:

atmos terraform apply vpc -s platform-cus
# Backend resource group, storage account, and container are created if missing, then init/apply proceed.

That's it. Atmos checks whether the backend is fully provisioned, creates only what's missing, and continues. It's idempotent — safe to leave enabled and safe to re-run.

A few things worth knowing:

• You don't put location in the backend block. It isn't a valid azurerm backend argument, so Atmos takes the region from your active Azure identity — or, if the resource group already exists, from the group itself. Pre-create the resource group and you don't need to configure a location at all.
• Subscription comes from backend.subscription_id if set, otherwise from your active Azure identity.
• It composes with inheritance. Enable provisioning once at the org or environment level and override per component — on in dev/qa, off in prod where state storage is module-managed.

Managing the backend explicitly​

The same lifecycle commands that work for S3 now work for azurerm:

# Create the backend explicitly (e.g. in a CI bootstrap stage)
atmos terraform backend create vpc -s platform-cus

# Tear it down (deletes the storage account and all state in it — resource group is preserved)
atmos terraform backend delete vpc -s platform-cus --force

Deletion always requires --force, and it removes the storage account (and therefore every state file in it, just as deleting an S3 bucket does), while leaving the resource group in place.

Not for Production As-Is​

Like the S3 provisioner, this is built for fast, secure bootstrapping — dev, test, CI, and cold-starts — not to replace a production-grade module. It doesn't set up customer-managed keys, private endpoints, network ACLs, geo/zone redundancy, or lifecycle policies. When you're ready to harden, import the resource group, storage account, and container into a managed module (such as Azure/avm-res-storage-storageaccount) and keep using the same backend — no state migration needed, because the account keeps its name and contents. You can even leave provisioning enabled; Atmos detects the resources exist and skips.

Get Involved​

Give it a try on your Azure subscriptions and let us know how it goes. Questions or ideas? Start a thread in GitHub Discussions, or open an issue in the issue tracker.

The Problem​

Official Atmos skills (atmos-terraform, atmos-stacks, and the rest of the catalog) are embedded directly in the atmos binary. Installing one by name copies its SKILL.md and supporting files to ~/.atmos/skills/ at that point in time. If a later atmos release bundles an improved version of that skill, nothing tells you, and nothing refreshes your local copy — the only way to pick it up was atmos ai skill install <name> --force, applied on faith, one skill at a time, with no way to check first whether anything had actually changed.

atmos ai skill list --detailed already surfaced an "update available" hint when an installed skill's version drifted from the catalog. There was no command that acted on it.

The Fix​

atmos ai skill update closes that gap. It compares each installed bundled skill's recorded version against the catalog embedded in the running binary and reinstalls only the ones that are actually outdated — skills already at the current version are left untouched.

Run it with no arguments to refresh every installed bundled skill that has an update available (a single confirmation, not one per skill), or name one skill to update just that one. Skills that are already current report "already up to date" and nothing is rewritten, so it's safe to run atmos ai skill update repeatedly, including as a habit after every atmos upgrade.

An outdated skill is reinstalled the same way atmos ai skill install <name> --force would install it, so --client, --scope, --global, --all-clients, and --path all work exactly as they do on install.

Skills installed from a GitHub repository aren't covered yet — there's no cheap way to check whether a git-sourced skill's upstream has moved without re-fetching it. Run atmos ai skill install <source> --force to refresh one of those manually.

How to Use It​

# Update a single bundled skill if a newer version is available.
atmos ai skill update atmos-terraform

# Update every installed bundled skill that has an update available.
atmos ai skill update

# Skip the confirmation prompt (for automation).
atmos ai skill update --yes

# Update and redistribute to a specific AI client.
atmos ai skill update atmos-terraform --client vscode

Get Involved​

Read the atmos ai skill documentation for the full command reference. To share feedback or request an improvement, open an issue.

The Problem​

atmos config set already tried to guess a value's type from the Atmos config schema, but only for fields the schema knows about — everything else, including the free-form vars and settings sections most people actually edit, fell back to a plain string with no warning. atmos stack set didn't even have that: it always wrote a string unless you passed --type explicitly, since component variables have no fixed schema to infer from in the first place.

On top of that, editing a value that came from an imported catalog file — the normal way Atmos stacks are organized, defaults in one file, per-environment overrides in another — could fail outright with an error that pointed at the wrong manifest, leaving no clue where the real value actually lived.

The Fix​

--type now defaults to auto on both commands, and auto tries harder before it gives up. config set checks the Atmos config schema first, then the type of the value already at that path. stack set checks the component's own declared Terraform variable type for vars.* paths first — Atmos already parses variables.tf while resolving the component, so this costs nothing extra — then the existing value. If the declared type disagrees with what's already stored (a number saved as a quoted string, say), Atmos retypes it and tells you so, instead of leaving the mismatch in place.

Only after all of that does either command fall back to the value's own shape: 5 infers as an int, true infers as a bool, 3.14 infers as a float. A value doesn't get silently downgraded to a quoted string just because nothing else had an opinion on it anymore — that fallback (with a warning) is now reserved for values that genuinely don't look like anything but a string.

Editing values that live only in an imported catalog file is also fixed: atmos stack set, get, delete, and list now correctly resolve to the file that actually defines the value, instead of misattributing it to whichever stack manifest happened to import it.

How to Use It​

# vars.replicas is already 1 (an int) in the manifest -- auto keeps it an int.
atmos stack set vars.replicas 5 -s plat-ue2-prod -c vpc

# If variables.tf declares vars.quota as a number, auto uses that -- and retypes an
# existing value that disagrees, e.g. one stored as a quoted string.
atmos stack set vars.quota 10 -s plat-ue2-prod -c vpc

# A brand-new vars.new_flag with nothing existing to infer from now infers straight
# from the value's shape: "true" is written as a bool, not the string "true".
atmos stack set vars.new_flag true -s plat-ue2-prod -c vpc

# Works even when the value is only defined in an imported catalog file.
atmos stack set vars.region us-west-2 -s plat-ue2-prod -c vpc

--type still accepts string, int, bool, float, null, or yaml explicitly whenever you want to skip inference entirely.

Get Involved​

Run into a case where inference guesses wrong, or a value that still won't resolve? Open an issue on GitHub — this is exactly the kind of day-to-day CLI friction we want to keep sanding down.

The Problem​

A tool declared in .tool-versions stays exactly where you pinned it, on purpose — that's what makes it reproducible. But "pinned" shouldn't mean "stuck." When a new release ships, moving a tool forward has always meant editing the file by hand: look up the tool's latest release yourself, write the new version string into .tool-versions, then reinstall and hope you copied it correctly. There was no single command that answered "what's newer, and can I have it?"

The Fix​

atmos toolchain update resolves each tool's newest available version and moves the pin forward for you, then installs it. Run it with no arguments to update everything in .tool-versions, or name specific tools to update just those. Tools pinned to a PR, commit SHA, or git ref are left alone — those pins are meant to stay exact, so update skips them with an explanation instead of silently doing nothing.

How to Use It​

Update everything:

$ atmos toolchain update
✓ terraform: 1.9.8 -> 1.11.4
✓ jq: up to date (1.8.2)
Updated 1 tool(s), 1 up to date

Update one tool, or preview first:

$ atmos toolchain update terraform --dry-run
terraform: 1.9.8 -> 1.11.4 (dry-run)
Would update 1 tool(s)

Tools are updated concurrently, with the same --max-concurrency control atmos toolchain install already supports.

Get Involved​

Try atmos toolchain update the next time a pinned tool falls behind. If you run into a tool whose update doesn't behave the way you'd expect, please open an issue.

The Problem​

The atmos ai skill list command already listed every official skill, showing each skill's name, source, and install status. Add --detailed, and it also showed a one-line description. But no view showed a skill's full instructions -- the actual content that teaches the AI its domain knowledge.

To read that content, you had two options. Install the skill first. Or open the Atmos repository on GitHub and find the right SKILL.md file. Neither option let you compare skills quickly. Neither option gave an AI agent a direct way to fetch and read a skill's content on its own.

The Fix​

The Agent Skills Directory lists every skill with its full content. Open the directory. Search by name, description, or category. Click a skill to read its complete instructions -- no install step required. Add a new skill to the Atmos repository, and it appears in the directory automatically.

Each skill's page also has a raw Markdown version. Add .md to the page's URL. This is the same convention the rest of the Atmos docs site uses. An AI agent can fetch this URL directly and read the skill's content.

Each skill's page also has a "Copy as Markdown" button. Use it to copy the skill's full content. Paste it into a chat session, or review it, before you install anything.

The atmos ai skill list command also gained a --format flag and a Category column, so the same categorization shown in the directory is available from the CLI.

How to Use It​

Browse and search the directory at atmos.tools/ai/skills. Or fetch a skill's content directly:

# Raw Markdown for one skill - readable by a human, fetchable by an agent
skill_name=atmos-ai
curl "https://atmos.tools/ai/skills/${skill_name}.md"

# Table view, now with a Category column
atmos ai skill list

# Machine-readable output for scripting
atmos ai skill list --format=json
atmos ai skill list --format=yaml

Get Involved​

See the Agent Skills guide to learn how skills are structured. It also explains how to contribute one. Share skill ideas and contributions in the Atmos community.

The Problem​

Delivering rendered Kubernetes manifests to a Git deployment repository (the source Argo CD or Flux reconciles) always wrote them as a directory — one generated file per manifest, no way to land a single file under an exact, caller-chosen name. That's a fine default for a directory of standalone resources, but it can't produce kustomization.yaml, so it couldn't support this pattern at all. Separately, Kustomize's own Kustomization and Component config objects don't have a metadata.name in the real Kustomize schema — they're local input to the kustomize build tool, not Kubernetes API resources — but Atmos's manifest validator required one anyway, rejecting perfectly valid Kustomize files.

The Fix​

A git provision target's path can now be an exact single-file destination, not just a directory. Set split: false to merge every rendered manifest into one file written at that path; leave it unset and Atmos infers the right mode from whether the path looks like a manifest filename (.yaml, .yml, or .json). Every existing configuration keeps its current directory behavior unchanged.

Atmos also now recognizes Kustomize's own Kustomization and Component kinds and no longer requires a metadata.name on them — matching Kustomize's own validation, not an opinion Atmos invented. For anything else, a new validate: false component setting opts out of Atmos's structural checks entirely.

How to Use It​

components:
  kubernetes:
    cert-manager-patch:
      provision:
        targets:
          deployment-repo:
            kind: git
            repository: deployments
            path: "kustomize/overlays/{{ .vars.environment }}/kustomization.yaml"
            commit:
              message: "Render manifests for {{ .vars.environment }}"
      manifests:
        - apiVersion: kustomize.config.k8s.io/v1alpha1
          kind: Component
          patches:
            - target:
                kind: ClusterIssuer
                name: letsencrypt-dns
              patch: |
                - op: add
                  path: /spec/acme/solvers
                  value:
                    - dns01:
                        route53:
                          region: "{{ .vars.aws_region }}"
                          hostedZoneID: "{{ atmos.Resolve \"!terraform.state route53 public_zone_id\" }}"

atmos kubernetes deploy cert-manager-patch -s plat-ue2-dev --target=deployment-repo

No split is set here — the path ends in kustomization.yaml, so Atmos writes it as a single file automatically. No metadata.name is needed on the Component object either. The real Kustomize overlay then includes the generated file as a remote component, so the Terraform-derived value flows through on every deploy without anyone touching the overlay by hand. See Generating a Kustomize component for GitOps for the full walkthrough.

Get Involved​

Try delivering a Kustomize component or patch through a git provision target in your own GitOps repo. Tell us what's missing — pull-request publishing for the git target, support for other Kustomize-only object kinds, or something else — by opening an issue at github.com/cloudposse/atmos.

The Problem​

Atmos workflows and custom commands already covered most of what a task runner needs: steps, templating, conditionals, parallel execution. But a handful of real gaps kept people from fully retiring go-task:

• No dependency ordering between named commands or workflows. You could make steps within one command run in parallel, but you couldn't say "run build before test and lint, and don't run build twice just because two things depend on it."
• No up-to-date checking. go-task's sources:/generates: skip a task when nothing has changed. Atmos had nothing like it — every step ran every time, even a slow compile step whose inputs hadn't changed since the last successful run.
• No continue-on-error. A single failing step stopped everything downstream, even for steps — like a linter — where you'd rather collect every result and report at the end.
• No precondition shortcut. Skipping an install step when a tool is already on PATH meant hand-rolling a shell check.
• Custom commands couldn't use parallel/matrix at all. The migration guide's own suggested workaround — wrap dependents in a parallel step with needs: — silently failed on custom commands; it only worked in workflows.

The Fix​

Custom commands and workflows now cover all of it, using the same when:/CEL condition engine and scheduler Atmos already had — no second, bespoke mechanism bolted on.

Dependencies between commands and workflows​

commands:
  - name: build
    steps: [...]
  - name: test
    dependencies:
      commands: [build]
    steps: [...]
  - name: lint
    dependencies:
      commands: [build]
    steps: [...]
  - name: release
    dependencies:
      commands: [test, lint]
    steps: [...]

build is declared as a dependency of both test and lint, but it only runs once — the graph dedups identical dependency invocations automatically. Dependencies run concurrently by default. Need the same command with different inputs? Parameterize it:

dependencies:
  commands:
    - name: build
      flags: { env: dev }
    - name: build
      flags: { env: prod }

Both invocations run — different parameters mean different graph nodes. Workflows get the same dependencies.workflows, including cross-file references via file:.

Skip steps that are already up to date​

steps:
  - name: compile
    inputs:
      sources: ["cmd/**/*.go", "go.sum"]
    artifacts:
      paths: ["bin/handler"]
    command: go build -o bin/handler ./cmd/handler

No extra configuration needed — declaring inputs/artifacts alone means "skip this step unless sources changed since the last successful run." Run it twice in a row and the second run skips entirely. Power users can reference the underlying facts directly (checksum.changed, timestamp.changed, or the raw per-file sources/artifacts records) for custom logic.

Skip a step when a tool is already installed​

steps:
  - name: install-stringer
    preconditions:
      tools: ["stringer"]
    command: go install golang.org/x/tools/cmd/stringer@latest

Resolved via Go's exec.LookPath — no shell, so it works identically on Linux, macOS, and Windows.

Continue past a failing step​

steps:
  - type: shell
    command: golangci-lint run ./...
    continue: always
  - type: atmos
    command: terraform apply vpc -auto-approve

continue: always mirrors GitHub Actions' continue-on-error: the step's own failure is still visible, later steps still run, and the overall exit status is unaffected.

parallel/matrix now works in custom commands​

The exact recipe that used to only work in workflows now works identically in custom commands:

commands:
  - name: release
    steps:
      - type: parallel
        steps:
          - name: test
            command: go test ./...
          - name: lint
            needs: [test]
            command: golangci-lint run ./...

Also Shipped​

A handful of smaller gaps closed alongside the above:

• platforms via when: — when: "os == 'darwin'" instead of a dedicated field, reusing facts already available everywhere else when: is.
• Native command aliases — aliases: [dep, d] on a custom command, registered in-process, distinct from the top-level subprocess-redirect aliases: config.
• internal: true — hide a command from atmos help/atmos list while leaving it fully invocable, for commands meant only to be run as someone else's dependency.
• values: on flags and arguments — restrict a flag to a fixed set of choices, with static validation and an interactive picker when a required value is missing.

How to Use It​

All of this is available today in custom commands and workflows — no flags to enable, no config migration required. See dependencies, inputs, artifacts, preconditions, and continue for the full field references, or the Alternatives page for how Atmos compares to go-task more broadly.

Get Involved​

If you're still running go-task alongside Atmos for one of these reasons, we'd like to hear about it — open a discussion on GitHub Discussions and tell us what's still missing.

What Changed​

Aqua's registry defines several package types for downloading tools. Atmos previously supported only two:

• github_release — assets attached to a GitHub Release
• http — arbitrary HTTP(S) URLs

Two more are now supported:

• github_archive — the auto-generated source tarball produced by GitHub for any tag, downloaded from github.com/{owner}/{repo}/archive/refs/tags/{version}.tar.gz. Always .tar.gz, regardless of the format field.
• github_content — a single file from a GitHub repo at a tag, downloaded from raw.githubusercontent.com/{owner}/{repo}/{version}/{path}. The required path field points to the file inside the repo.

Both implementations match upstream aquaproj/aqua exactly. For github_archive, the asset, url, format, and format_overrides fields are intentionally ignored (Aqua hardcodes tar.gz and the URL pattern). For github_content, the same fields are ignored — only repo_owner, repo_name, and path are used.

Before this release, any Aqua registry entry using either type failed with unsupported tool type: .... Those entries now resolve correctly.

How to Use It​

github_archive​

For a tool that ships its binary as a script inside its source tree — such as adr-tools:

packages:
  - type: github_archive
    repo_owner: npryce
    repo_name: adr-tools
    files:
      - name: adr
        src: adr-tools-{{trimV .Version}}/src/adr

The {{trimV .Version}} template expands to match GitHub's archive root directory (e.g., adr-tools-3.0.0/ for version v3.0.0), so files[].src points to the file inside the extracted archive.

github_content​

For a tool that ships as a single raw file in a repo — such as kubens from ahmetb/kubectx:

packages:
  - type: github_content
    repo_owner: ahmetb
    repo_name: kubectx
    path: kubens

The download URL becomes https://raw.githubusercontent.com/ahmetb/kubectx/{version}/kubens. No archive extraction is involved — the file is downloaded directly.

Why This Matters​

Aqua's upstream registry has hundreds of entries that use these two types — tfenv, tgswitch, adr-tools, kubectx, kubens, and many one-binary shell-script projects. Until now, those entries were dead in Atmos. Adding these two package types unblocks all of them without registry-level changes: pull the Aqua registry entry as-is and it just works.

The Aqua-compatible build/install types (go_install, go_build_install, cargo) remain unsupported — they require invoking a language toolchain at install time rather than downloading an artifact, which is a different installation model. A follow-up issue tracks that work.

Get Involved​

Atmos is open source on GitHub. File issues or open PRs if you hit any tools the registry can't resolve.

Why This Matters​

Device code is getting blocked: Microsoft-managed Conditional Access policies now block the device code flow in many tenants (error AADSTS530035), so azure/device-code fails there. The interactive browser flow carries full Conditional Access context, so it keeps working.

One command instead of two: azure/cli requires a pre-existing az login session. With azure/interactive, atmos auth login is the only command you run.

Silent repeat logins: Atmos tries silent acquisition from the persisted MSAL cache first. Refresh tokens make repeat logins silent — no browser after the first sign-in.

Drop-in for az login: Atmos writes the Azure CLI-compatible cache files (MSAL token cache and azureProfile.json), so after atmos auth login the az CLI works without ever running az login. Guest/B2B users are handled correctly using the real MSAL home account ID.

How to Use It​

auth:
  providers:
    azure-browser:
      kind: azure/interactive
      spec:
        tenant_id: "12345678-1234-1234-1234-123456789012"
        subscription_id: "87654321-4321-4321-4321-210987654321"
        location: eastus

  identities:
    azure-dev:
      default: true
      kind: azure/subscription
      via:
        provider: azure-browser
      principal:
        subscription_id: "87654321-4321-4321-4321-210987654321"
        location: eastus

Then authenticate:

atmos auth login

Atmos opens your default browser for sign-in (with MFA if configured), acquires Management, Graph, and Key Vault tokens, and caches them for azurerm, azuread, and azapi. Chain identities via azure/subscription exactly like the other Azure providers.

The spec shape is identical to azure/device-code: tenant_id (required), plus optional subscription_id, location, client_id (defaults to the Azure CLI public client), and cloud_environment (public, usgovernment, or china).

The flow requires an interactive terminal and a browser. For headless environments and CI/CD, keep using azure/oidc; where a browser can't be opened (e.g., SSH sessions), azure/device-code remains available.

Get Involved​

• Read the provider documentation and the Azure Authentication tutorial
• Report issues on GitHub