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

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

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

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

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) Has anyone tried using Atmos to generate ArgoCD Application manifests or Crossplane Claims?

Hey guys I think I found a bug with Atmos Stores and the identity field.. I have created an issue with more explanation but figure I should posted here:
https://github.com/cloudposse/atmos/issues/2377

Question. I'm using atmos terraform plan --all in GitHub action, but noticing the following in GitHub Summary. Is this expected?

Question, does anyone here use atmos + checkov together in GitHub actions?

atmos docs generate is a game changer! used it for a new project and it works amazing!

Following the documentation it seems like !literal should be working here:

field_template: !literal |
  {%- if alertDef.entityLabels.channel is defined -%}
    {{ alertDef.entityLabels.channel }}
  {%- else -%}
    _sandbox
  {%- endif -%}

but I get error *Error:* template: templates-all-atmos-sections:624: function "alertDef" not defined, is there something wrong with my usage or a bug?

I tried with 1.210.0 & 1.216.0

I just upgraded to 1.115 and saw this: Preserve Directory Hierarchy in Terraform State Buckets. Yeah! For weeks, I've been telling myself I need to report that I have to override all components manually because it doesn't preserve the /. A small feature, but very valuable. Thanks :).

Has anyone ran into issue that prevents using atmos locals? More in the thread.

Hi all, I have a question on datasources/templates

I have this datasource defined:
settings:
templates:
settings:
gomplate:
datasources:
env:
url: "stacks/data/{{ .vars.environment }}.yaml"

And I use it as described in the documentation:
ami: '{{{{ (index (datasource "env").ami .vars.aws_region) }}}}'

It works great if aws_region contains directly a string value but is not working if it reference another variable, for example aws_region: {{ .vars.region }}
I have templates evaluation set to 3 and as far as I understood, in the first evaluation aws_region should be resolved to the actual value of region and ami to '{{ (index (datasource "env").ami .vars.aws_region) }}' so in the second evaluation it should be evaluated correctly with the value originally contained into region.
Am I assuming something wrong? Is there any way to make it works if I'm doing something wrong? Thanks in advance

Hey I just feel like I stumbled upon a very cool configuration that will help us migrate from static traditional terraform dirs in a progressive way.
In our current static terraform we only use a default workspace and set specific backend keys for each dir. Eventually we'll migrate these static root modules into components but until they are all migrated in I was worried it would be difficult to leverage the atmos !terraform.state YAML function to lookup outputs in the older terraform root modules.
Then I had a crazy idea. If could create a dummy component that essentially only contains a context.tf could I then setup a stack that points to the older root modules where each component inherits from dummy but then specifies it's backend to make !terrafofrm.state work. To my surprise this actually works amazingly well!
Here's what one of these dummy instances actually looks like (bogus account id swapped in):

components:
  terraform:
    vpc/us-east-1-development:
      metadata:
        enabled: false
        terraform_workspace: "default"
        component: dummy
        name: vpc/us-east-1-development
      backend:
        s3:
          key: infra/terraform/123456789012/vpc/us-east-1-development/terraform.tfstate

Then I can use this in another real component in the same stack:

      vars:
        vpc_id: !terraform.state vpc/us-east-1-development vpc_id

Thought I would share in case this helps anyone else move into atmos
The metadata.enabled is very cool cause that ensures my CI/CD does not try to plan/apply this dummy component as well!

Hi guys!
Apologies for the next rookie question - is the Makefile deprecated?

Hello, I'm looking how to tackle atmos terraform destroy with GitHub Actions.
With vanilla Terraform, resources are deleted when source code files are removed from the codebase.
With Atmos components that is not the case, as we need deep merged yaml to even run terraform in the first place.
I'm looking for ways how to carry out deletions when PR with deleted yaml files gets created.

Hello. I've been looking into atmos generate and it seems it can't be specified under the global terraform key (like backend or providers). Am I missing something or is there a reason it must only be specified under a component?
I guess if I wanted a file more globally generated I could try having all my components inherit from one that does the generation...

Have you ever wanted to auto commit fixes like terraform fmt and realized that GitHub Actions won't run on those changes? GitHub does this as a circuit-breaker to prevent commit loops.

The workaround used to suck: create a static PAT or create a new github app, then distribute/manage/rotate those secrets.

Well, not anymore.

Now you can use atmos pro commit https://atmos.tools/changelog/pro-commit

Hi there, just confirming planfile to Github artifacts in native CI is not implemented in 215 right?

🧪 ci is an experimental feature. Learn more <https://atmos.tools/experimental>
WARN CI hook handler failed event=after.terraform.plan
  error=
  │ failed to upload planfile: failed to upload planfile: not implemented: GitHub Artifacts upload requires running within GitHub Actions (ACTIONS_RUNTIME_TOKEN and ACTIONS_RESULTS_URL must be set)
  │ (1) forced error mark
  │   | "failed to upload planfile"
  │   | errors/*errors.errorString::
  │ Wraps: (2) key=dev-primary/argocd-apps/0509682841e9b66922a344abd606567815703ad3.tfplan.tar store=github/artifacts
  │ Wraps: (3) Failed to upload planfile to store
  │ Wraps: (4) failed to upload planfile: failed to upload planfile: not implemented: GitHub Artifacts upload requires running within GitHub Actions (ACTIONS_RUNTIME_TOKEN and ACTIONS_RESULTS_URL must be set)
  │     └─ Wraps: (5) failed to upload planfile: not implemented: GitHub Artifacts upload requires running within GitHub Actions (ACTIONS_RUNTIME_TOKEN and ACTIONS_RESULTS_URL must be set)
  │       └─ Wraps: (6) not implemented: GitHub Artifacts upload requires running within GitHub Actions (ACTIONS_RUNTIME_TOKEN and ACTIONS_RESULTS_URL must be set)
  │         └─ Wraps: (7) not implemented
  │       └─ Wraps: (8) failed to upload planfile
  │     └─ Wraps: (9) failed to upload planfile
  │ Error types: (1) *markers.withMark (2) *safedetails.withSafeDetails (3) *hintdetail.withDetail (4) *fmt.wrapErrors (5) *fmt.wrapErrors (6) *fmt.wrapError (7) *errors.errorString (8) *errors.errorString (9) *errors.errorString
ℹ Executing command: atmos terraform apply argocd-apps --from-plan -auto-approve
🧪 ci is an experimental feature. Learn more <https://atmos.tools/experimental>

Hello 👋 I'm working on getting aws-ssosync setup, and I I see you all recently released v2.0.0.

I can't find this version published to the open tufu registry. Is this version only meant to be usable with Atmos?

Hello guys! I'm trying to use the github-action-atmos-terraform-plan in a github actions pipeline that deploys resources to Google Cloud but it fails because it seems to only supports AWS authentication:

Run aws-actions/configure-aws-credentials@v4.0.2
  
Error: Source Account ID is needed if the Role Name is provided and not the Role Arn.

Is there a way to skip the AWS credentials configuration action and make it work with GCP instead? Or is there a another atmos-terraform-plan action for GCP?

Hey guys I have a question about atmos toolchain I know we have the .tool-versions file but do we need to set the version again when declaring them as a dependencies?

for example on the org/_default I have this:

dependencies:
  tools:
    atmos: 1.214.0
    terraform: 1.14.2
    tflint: 0.61.0

but I will prefer to manage version in 1 place and just declare the tool that is need it that way I don't have to remember and update this too hahaha

Just another friendly reminder: if you are waiting on a resolution to an issue you have opened, please check if there's an associated PR. If there is, it's probably held up on validation, and any help we can get to validate those pull requests will expedite merging and cutting a release.

Hello,
I'm asking because I didn't see about this in the Atmos documentation. Is it possible to add the Git commit and branch to the variables? This would allow us to tag resources and thus track the code that created or modified them. Do you think this is a good idea? And Then would you consider adding this feature to the Atmos core?