#atmos - September 2026

Is there a way for atmos to gracefully handle doing a terraform state lookup on a stack reference that doesn't exist? Running into an error from one of our values that we are importing and actually overwriting

This is crazy, and it just shows how how much GitHub/Microsoft is subsidizing open source development. It's 9/4 and we've already spent the equivalent of ~$9,000 USD in build minutes on atmos. But since the project is Open Source, this is free.

atmos.tools/cli/configuration/schemas#…

Pined schemas does not exist
https://atmos.tools/schemas/atmos/atmos-manifest/1.228.0/atmos-manifest.json
Same for 1.224.1 and 1.219.0 which set as example

Atmos 1.228.0 ships a pretty slick lightweight streaming UI now for terraform operations. Just pass the --ui flag to test it out. It can also be enabled by default.

atmos config set components.terraform.ui.enabled true

Hello :),
I see that the AI section is still marked as experimental. Do you plan to add any new features, or is that not on the agenda for now?
I’m (finally!) testing generative AI with Atmos, and I have two questions:
- Why isn’t Bedrock authentication used like the rest (login via OAuth)?
- Are you going to add other providers (I’m thinking of OpenRouter, Opencode Go/Zen, Deepseek, etc.)? Anthropic is sooo expensive (Bedrock too).
Thanks.

when using the new secrets how can I use terraform plan? I have imported my s3 access and secret key via secrets but they are passed as MASKED to plan

newish

Did you know terraform registries mostly just return redirects to GitHub?

GitHub is cracking down on unauthenticated requests as it tries to stabilize the platform. Using GitHub as a registry is less and less reliable. It's also one of the reasons homebrew moved to OCI.

This is why Atmos supports a pass though Terraform Registry & Provider proxy so all requests are cached locally in your XDG cache folder. Combine that with the GitHub artifact cache, you can speed up your terraform runs in CI. Oh, and did you know atmos also supports pulling your modules from OCI container registries like the GitHub container registry? When you pull from container registries it's blazingly fast compared to git.

github.com/hashicorp/terraform/issues/39130

github.com/orgs/community/discussions/206581#…


Automatically retry transient errors with atmos:

atmos.tools/changelog/terraform-component-retry


Enable the registry cache:

atmos.tools/changelog/terraform-registry-cache


OCI vendoring

atmos.tools/cli/commands/vendor/pull#…

Hi, it looks like a bot closed a feature request I had open with no explanation and no prior warning. Could someone please reopen issue 1549?
https://github.com/cloudposse/atmos/issues/1549
Thank you in advance

Hey Guys! Just wanted to share that I very much appreciate how far you've come with Atmos ❤️. I love the direction you are going in and this year's roadmap.

Hello! I have opened a GitHub issue for an issue I am having relating to the Atmos toolchain. github.com/cloudposse/atmos/issues/3213 I would be happy to provide additional details/troubleshoot further if needed.
I wanted to keep the issue concise, but I would like to balance it with some positivity here. 🙂 I've been using Atmos since mid 2022 and it really has come a long way since then. It's incredible what you can do with it now! I greatly appreciate all of the work that's been put into it (and keeping it open source), it really has changed our infrastructure game for the better. Thank you!

Loving these new slack notifications.

ATMOS looks like it is trademarked in this picture.

Improved formatting for --ui coming in 1.230.0

Hello! I am coming with two questions. We’re on Atmos + legacy github-action-atmos-terraform-plan/apply, with settings.github.actions_enabled as an opt-in (only a few app components enabled).

1) Privileged / foundation components (aws-teams, iam, tfstate-backend, …): when actions_enabled is unset/false we get green Plan jobs but no real plan (step skipped), so PRs touching those components show no Terraform plan. Cloud Posse docs suggest default actions_enabled: true and disabling sensitive ones. We’re considering plan-in-CI for privileged components (visibility/history) while keeping apply manual or on a separate privileged workflow.
Is that still the recommended pattern under Atmos Native CI? Or is there a newer way to gate plan vs apply / privileged vs app components? Have you seen teams safely enable CI apply for foundation components, and how?

2) Production promotion: how do you currently prefer customers promote changes to production with Atmos/GitOps?