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