hello, anyone able to confirm if planfile artifact storage to gh artifacts has been implemented as of v1.221.1?

We've published a media kit for atmos! If you've wanted some atmos logos, we got 'em.

https://atmos.tools/media-kit

I’m looking forward to Atmos secrets management. We use Sealed Secrets for our application layer since everything runs on Kubernetes. Managing secrets as code makes deployments much more portable across regions and accounts.

However, for our infrastructure layer, secrets are stored in Secure SSM Parameters and Secrets Manager. The lack of portability has become a small pain point when managing a DR region, so I’ve been considering a move to SOPS. After another practice run of our DR runbook last week, I’m definitely making the switch soon. The timing of Atmos secrets management with SOPS support couldn’t have come at a better time.

Btw, it's a really minor issue, but atmos ai skill does not support vscode natively, as it expect skills in some specific folders.
I've had to make it available this way:

cd <my VScode workspace>
atmos ai skill install cloudposse/atmos -y --force
mkdir -p .github/skills && for d in ~/.atmos/skills/cloudposse/atmos/*/; do ln -sfn "$d" ".github/skills/$(basename "$d")"; done

I recorded a 20-minute overview of the Atmos Changelog covering all of the latest features that have come out over the past month.

https://us02web.zoom.us/clips/share/tQmxbpnfQxGWs-bpWl4sAA

• Atmos Git for GitOps — Manage repositories as first-class Atmos resources; clone, diff, commit, push, and publish generated artifacts through lifecycle hooks.
• Secrets Management — Declare component secret dependencies and manage secrets natively in Atmos.
• CI Caching — Cache toolchains, providers, modules, vendored components, and remote imports to accelerate local and CI runs.
• Terraform Registry Cache(Experimental) — Cache providers and modules for faster, reproducible, and more resilient builds.
• Terraform/OpenTofu RC Management(Experimental) — Define CLI runtime configuration in atmos.yaml; Atmos manages temporary RC files automatically.
• Terraform DAG Concurrency — Dependency-aware execution with concurrent planning and deterministic ordering.
• Interactive Workflows & Commands — 25+ interactive step types for building CLI wizards and guided workflows.
• Atmos Pro STS Tokens — Just-in-time GitHub tokens for CI access to private resources.
• Git Repository Metadata Functions — YAML functions exposing repository metadata.
• atmos.Resolve Template Function — Evaluate YAML functions inside templates.
• Install from Branches & Tags — --use-version supports Git refs directly.
• Dotenv Support in !include — Include .env files directly in YAML.
• !append YAML Function — Extend inherited lists.
• !unset YAML Function — Remove inherited configuration keys cleanly.
• ECR Public Authentication — Authenticated pulls from public.ecr.aws to avoid rate limits.
https://atmos.tools/changelog

hello, we're trying to standardize on making every component declare a standard instance and a dr instance of said component. So under stacks/catalog/network/default.yaml for example, we'd declare our VPC twice referencing components/terraform/network as the component. Now under stacks/deploy/dev.yaml we import our stacks/catalog/network and in the dev.yaml, we'd like to be able to toggle that DR instance on or off. The idea is that every environment has to opt out of provisioning a DR environment. What approach would you recommend to address this? We've had trouble getting a variable passed over to the metadata.enabled because anything we pass gets converted to a string and enabled needs a bool

Hi team, I recently started using the required_providers, required_version and providers atmos fields and wanted to share some findings and get a sense of whether I'm on the right track.

In 1.221.0 you can now define your own custom components. https://atmos.tools/changelog/custom-component-types

In atmos+pro, you can now mint short-lived narrowly scoped GitHub tokens that span repos. Think of it like AWS STS but for GitHub.

https://atmos-pro.com/changelog/2026-05-29-cross-repo-sts

This makes it trivial to read stack configs, source components, or really anything you do that needs a short-lived cross-repo token.

I found some interesting design differences between my own GCP components vs. Cloud Posse AWS components. I designed my GCP components to always take explicit var.project_id , this concept of account_map is quite confusing. 😃

Especially when tofu allows to use variables within provider blocks nowadays.

is there an obvious way to exec/drop to a raw tty via a custom command? E.g. I'm trying to do something like:

commands:
  name: ssh
  steps:
    - type: shell
      output: raw
      command: "exec aws ssm start-session --target {{ .Arguments.instance_id }}"

but the exec seems to be within a subprocess itself, so doesn't replace atmos and the terminal gets all bunged up, most obviously if you try and Ctrl-C a command in the session, atmos itself takes teh Ctrl-C exits, and then the session ends with SIGPIPE 😞

Feels like a common need I would have thought, but I'm failing to find the right invocation in the docs...

Is atmos interactive workflows released (v1.220.0)?
• https://atmos.tools/changelog/custom-commands-step-types
• https://atmos.tools/workflows#step-types

Hi, is the atmos manifest schema updated with each release? I'm running 1.219.0 and I can see required_providers in the output from atmos describe stacks so I found the page mentioning this (a blog post) but can't seem to find anything in the actual documentation nor do I see the fields in the manifest schema, so after adding the providers as per the example, atmos describe stacks is tripping up because the stack yamls no longer validate against the manifest schema at https://atmos.tools/schemas/atmos/atmos-manifest/1.0/atmos-manifest.json

Edit to clarify manifest schema, not json schema. I know I can comment out the schema from my atmos.yaml to bypass the error, but just curious how often is the online schema updated?

Hey I have a question about atmos toolchain on atmos release 1.220.0 there was an update to how the toolchain verifies downloaded packages, it now will do checksums and signature/attestations this is great but on the PR it mention that this should be no breaking but if the package only has checksums it will fail with 404 I believed this should be a warning unless this is intentional

Coming to an atmos near you!
• Provider and Registry cache that works across all components
• Native GitHub Actions cache support (compatible with provider and registry cache and toolchain!)
• Custom Components (thanks @Ben Smith (Benbentwo) for validating)
• Native Secrets Management

Hello,
I finally took the time to test the command-adding feature. I added tflint, kics, trivy, checkov, and tfupdate in just a few lines. Atmos downloads the app and launches it in the right place. Really cool!

Can I combine yaml functions? I have some challenges passing JSON via !terraform.state, it gets turned into object, and I just want it as string.

I'd like to give a massive shout out to @shirkevich for working closely with us to implement parallel/concurrent execution in Atmos. In the upcoming release, you can control concurrency of --all and --affected for plan and apply operations.

e.g.

atmos terraform plan --all -s prod --max-concurrency=4

https://atmos.tools/changelog/terraform-dag-concurrency

Hey guys
I have a question, Is there a way to filter out some global variables? for example I have configure region as a vars on the _defaults for the org but there is just 1 component where I will like to not pass that region to, is there a way to do this?

With the recent shift toward native CI, and the deprecation of the GHAs (🥳 ) what's the current guidance for drift detection w/ native CI?

Hey Guys,
I would like to know if support for aws secrets manager or encrypted params in param store is comming?
https://atmos.tools/stacks/sharing-state/stores

Upvote! https://www.reddit.com/r/Terraform/comments/1tr1hun/comment/oosbzmi/

(not sure who posted this, but thanks!)

Hey!
I have open a new issue for ECR loging multiple times:
https://github.com/cloudposse/atmos/issues/2562

Hello, is there any way I can use variable in atlantis integration template? I don't want to add concept of tenant or stage to our terraform when we have slightly different variables. Something like this:

    project_templates:
      project-1:
        name: "{{var.name}}-{{var.custom_name}}"

I tried workarounds with passing things like this but it didn't work

vars:
  custom_name: <value>
  stage: {{ .vars.custom_name }}

For truly reproducible deployments, it would be… thats a good use case

Is it fairly easy and recommended to start committing component terraform lockfiles using atmos?

One of the annoying things about GitHub Actions is when you use the dynamic GITHUB_TOKEN to commit files, those commits don't trigger github actions. If your workflows require checks to pass before merging, then you can't merge the PR. There a plenty of workarounds, all of them involve either managing your own GitHub App or creating a static PAT.

There's a better way: https://atmos-pro.com/changelog/2026-05-29-commit-from-ci

support self-hosted Git hosts in describe affected
Please Review https://github.com/cloudposse/atmos/pull/2543

Neat way to use Atmos Pro to review changes in a PR.
https://atmos-pro.com/changelog/2026-05-23-github-chatops

Using Atmos 1.220, one final change would be awesome to achieve what I'm at properly: Use local components for dev environments, while pinning these same components for prod environments. This allows to safely change component code in PR with impact only on dev, and restrict what affects prod to only the prod stack files and a prod catalog (see below) which can be protected by CODEOWNERS. This seems to be the only way to have dev and prod in the same repo while still allowing to vet dev changes with a usual GitHub PR approval process, while ensuring such changes can't change prod without a special approval enforced by the CODEOWNERS.

So, for each usual stacks/catalog/component/XXX.yaml, I also define:

stacks/catalog_prod/component/XXX.yaml as:

import:
  - <http://github.com/my-org/my-repo//stacks/catalog/XXX.yaml?ref=v1.0.0|github.com/my-org/my-repo//stacks/catalog/XXX.yaml?ref=v1.0.0>  # ⚠️ TODO: use variable for git ref. unsupported yet

components:
  terraform:
    XXX/base:
      source:
        uri: <http://github.com/my-org/my-repo//components/terraform/XXX|github.com/my-org/my-repo//components/terraform/XXX>
        version: "{{ .settings.context.deployment_repo_version }}"

Those prod_components are the components imported by prod stacks.
The only remaining bit I'd like fixed is the hardcoded "v1.0.0" ref in the import line. I'd like to be able to use the same variable I use for the component source version, which is defined once, globally, for all components. Would that be possible anyhow?

Anyone have experience with tfmigrate

https://github.com/cloudposse/atmos/pull/2534

Feedback welcome on this proposed enhancement to Atmos.

This does a few things

1. introduces a new atmos terraform migrate command that calls tfmigrate
2. supports lifecycle hooks, so these can run automatically
3. supports passing your already configured backend for terraform to tfmigrate for idempotent migration
Why? Ever run into errors like this because a provider was deleted from the state? Migrations can help with that.

Error: failed to read provider configuration schema for <http://registry.opentofu.org/cloudposse/template|registry.opentofu.org/cloudposse/template>: failed to instantiate provider "<http://registry.opentofu.org/cloudposse/template|registry.opentofu.org/cloudposse/template>" to obtain schema: unavailable provider "<http://registry.opentofu.org/cloudposse/template|registry.opentofu.org/cloudposse/template>"

Hi there, can someone please clarify atmos vendors feature? It looks similar to the terrafrom/source block from terragrunt where terragrunt can pull the module from the registry/github at runtime and feed your values/inputs keeping your component directory folder clean in source control. However, it seems atmos needs an atmos vendor pull run before I run plan/apply commands right?

A sudo review of atmos: Atmos Native CI is awesome. Great job @Erik Osterman (Cloud Posse) and team. To implement CI, it's basically two workflows (eg, tf plan, and tf apply) each with two jobs thats has 2 2-4 steps. Only dependency were atmos and jq. Rating: 9.5/10 ⭐️ .

Hi, Are you updating homebrew actively as part of your release process, or is homebrew pulling from your releases?
It's still referencing version 1.218 as the latest one. That's unusual, after 6 days.
https://formulae.brew.sh/formula/atmos#default

good morning, just submitted https://github.com/cloudposse/atmos/issues/2485 - let me know if there are any questions or concerns

11:10:02     Error
11:10:02
11:10:02     **Error:** Atmos manifest JSON Schema validation error in the file
11:10:02     'azure/eastus/prd/app-47.yaml': { "valid": false,
11:10:02     "errors": [ { "keywordLocation": "", "absoluteKeywordLocation":
11:10:02     "<https://json.schemastore.org/atmos-manifest.json#>", "instanceLocation": "",
11:10:02     "error": "doesn't validate with <https://json.schemastore.org/atmos->
11:10:02     manifest.json#" }, { "keywordLocation": "/type", "absoluteKeywordLocation":
11:10:02     "<https://json.schemastore.org/atmos-manifest.json#/type>", "instanceLocation":
11:10:02     "", "error": "expected object, but got null" } ] }

This appears to happen while running atmos describe stacks --process-templates=false when we have a json schema configured for any stack and atmos encounters a stack yaml that is fully commented out

https://atmos.tools/cli/configuration/ai/tools
Suggestion (new feature request)
We have our repo structured:

components/
  terraform/
stacks/
  azure/
    <region>/
      <environment>/
        <stack>.yaml

We'd like to configure the lowest environment so that ai has full permissions there but read only in dev and higher.

has there been a change to user auth flow for atmos auth login? Now I get a redirect to sign in in the browser rather than with my access keys

❓️ Is there a 15 minute builtin cooldown if atmos fails to download a source when JIT-ing?

why is it that the atmos list commands take a while to run whilst fetching outputs and stuff but if I execute the atmos tui is instantaneous

Nice, so even though the docs dont explicitly have config details for how to configure copilot standalone cli to install and use the atmos skills, it was able to figure out how to install and configure the skills into itself anyway. Neat!

Hey hoping for some guidance with a bit of a design issue and possibly a bug in atmos. We try to explicitly define egress from our EC2 services using references to other security groups in the egress rule. And we like to define our security group rules in the component that defines the service. So this leads to this situation:
• a database component which defines a variable which is a map of all security groups IDs that should be added as ingress rules to the db.
• a client service component which has a map var for configuring it's egress rules.
My temptation is to use outputs for the sg ids in both these cases even though I realize it's a circular dependency. We'll never configure with a component dependencies link in a situation like this.
When we tried this with !terraform.state used for both vars in both components we're finding that atmos describe affected eventually fails with a stack overflow. While I realize the cycle here I'm guessing it's still a bug that this ends up in a stack overflow?
This is what I was hoping we could do:

components:
  terraform:
    services/test-client:
      vars:
        egress_security_groups:
          db_x:
            security_group_id: !terraform.state services/db_x security_group_id
            port: !terraform.state services/db_x db_x_sql_port

    services/db_x:
      vars:
        client_security_groups:
          test-client: !terraform.state services/test-client security_group_id

And since we would not use dependencies in this case our process would be the circuit breaker.
• add a new client service which defines it's sg in output
• next up you could add to the db client config
• finally you can do a final PR to setup the egress back on the new client service
Do you have any guidance on how to better handle this?

hey guys, is anyone using !store with auth? I opened an issue, but I believe there are some bugs. Probably needs the same treatment as the !terraform.state functions

@Erik Osterman (Cloud Posse) is there any plans to consolidate atmos terraform plan and atmos terraform generate planfile so that running atmos terraform plan --all would permit creating plan files as binary and json (with or without feature flags)?

Hey guys,
Just a small follow-up on this PR: https://github.com/cloudposse/atmos/pull/2389
The PR addresses an issue with Atmos stack validation when stack directories contain YAML files that are not Atmos stack/component files.
In our setup, some stack folders also include YAML files used by other tools. These paths are already excluded in atmos.yaml via stacks.excluded_paths, but the validate command still attempts to process them. As a result, validation can fail on files that should be ignored.
The fix is fairly small: it makes stack validation respect the configured excluded_paths by adding them to the excludedPaths list in validate_stacks.go.
I wanted to ask whether I simply need to be more patient with the review process, or if I may have missed something in the contribution process. Any guidance would be appreciated.

@Erik Osterman (Cloud Posse) curious what direction you guys are going for maintaining your terraform modules?

We just launched MCP support for Atmos Pro.

Atmos Pro continuously tracks stack health, deployment failures, Terraform drift, and historical changes across your infrastructure — and now Claude has API access to all of that operational context directly inside the conversation. You can ask things like “what’s drifting?”, “when did this start failing?”, “show me the logs for the last deployment”, or even “open a PR to fix this failing component”, without digging through dashboards, GitHub Actions runs, or Terraform output manually. Claude can reason about issues using full awareness of your Atmos stacks, components, environments, deployment history, and live operational state.

https://atmos-pro.com/changelog/2026-05-09-mcp-server