#atmos - May 2026

@Erik Osterman (Cloud Posse) Has anyone tried using Atmos to generate ArgoCD Application manifests or Crossplane Claims?

One place we've had issues with using !terraform.state is inside of yaml:

policy: |
  {
    "Version": "2012-10-17",
    "Statement": [
      {
        "Sid": "ExternalSecretsAccess",
        "Effect": "Allow",
        "Action": [
          "secretsmanager:GetSecretValue",
          "secretsmanager:DescribeSecret",
          "kms:Decrypt",
          "kms:GenerateDataKey",
          "kms:DescribeKey"
        ],
        "Resource": [
          !terraform.state rds {{ printf "demo-%s" .vars.deployment_requirements.stage }} .rds_properties.db_instance_master_user_secret_arn,
          !terraform.state kms {{ printf "demo-%s" .vars.deployment_requirements.stage }} kms_key_arn,
        ]
      }
    ]
  }

@Erik Osterman (Cloud Posse) what would the level of effort be to update https://atmos.tools/cli/commands/terraform/generate/planfile to work with atmos CI to provide plan changes in GitHub Summaries?

❓️ recommended way to have atmos populate stack vars with secretsmanager secrets?

Hi team, could you have a look at this PR - https://github.com/cloudposse/atmos/pull/2402 - it suppresses multiple messages about updating kubeconfigs, if the kubeconfig didnt change

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

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

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) 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, 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

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?

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!

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

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

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

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.

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

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

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

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

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

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?

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

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

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

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

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