👋 Hello. Is is possible to delete/unset a stack-scoped secret? For example: I ran atmos init -s organization w/ the following configured in mixins/organization:

secrets:
  vars:
    CLOUDFLARE_ZONE_ID:
      sops: organization
      required: true

I then attempted to run atmos unset CLOUDFLARE_ZONE_ID -s organization however this prompts me to select a component.

I'm using Atmos 1.233.2 on linux/amd64

Thanks for any help.

Ah just looked into it diff and plan operations are allowed on abstract components

is that intentional?

I understand the recommendation is to use the official helm component type now but we use helmfile elsewhere so still preference it

I think I may have found another bug, I have an abstract helmfile component in my catalog and when I run atmos helmfile diff it says it will create the release in the cluster:

metadata:
  component: reflector
  inherits:
    - reflector/defaults
  type: abstract

…/catalog/k8s-apps ❯ atmos helmfile diff -s ops-cluster-apps reflector
Adding repo emberstack <https://emberstack.github.io/helm-charts>
"emberstack" has been added to your repositories
Comparing release=reflector, chart=emberstack/reflector, namespace=reflector
reflector, reflector, ClusterRole (<http://rbac.authorization.k8s.io|rbac.authorization.k8s.io>) has been added:
-
+ # Source: reflector/templates/clusterRole.yaml
+ apiVersion: <http://rbac.authorization.k8s.io/v1|rbac.authorization.k8s.io/v1>
+ kind: ClusterRole
+ metadata:
+   name: reflector
+   namespace: reflector
+   labels:

I have quite a few use cases for this.

is this currently possible?

It would be cool if there was a way to adjust secret references based on profiles or something

Seems like the latest release of Atmos is failing the signature check when using .tool-versions:

 ❯ atmos toolchain install
[...previous tools...]
✗ Install failed : failed to verify downloaded asset: signature verification failed: .tools/bin/sigstore/cosign/v3.1.4/cosign [verify-blob --certificate-identity-
  regexp ^<https://github.com/cloudposse/.github/.github/workflows/shared-go-auto-release.yml@> --certificate-oidc-issuer <https://token.actions.githubusercontent>.
  com --
  bundle /var/folders/s3/x60v087551sg6kdzjm3r4sjr0000gn/T/atmos-verify-559584549.json /var/folders/s3/x60v087551sg6kdzjm3r4sjr0000gn/T/atmos-checksum-
  652188209.2_SHA256SUMS]: exit status 1
  Error: failed to verify certificate identity: no matching CertificateIdentity found, last error: expected SAN value to match regex
  "^<https://github.com/cloudposse/.github/.github/workflows/shared-go-auto-release.yml@>", got "<https://github.com/cloudposse/atmos/.github/workflows/release->
  pipeline.yml@refs/heads/main"
  error during command execution: failed to verify certificate identity: no matching CertificateIdentity found, last error: expected SAN value to match regex
  "^<https://github.com/cloudposse/.github/.github/workflows/shared-go-auto-release.yml@>", got "<https://github.com/cloudposse/atmos/.github/workflows/release->
  pipeline.yml@refs/heads/main"
✗ Install failed : failed to verify downloaded asset: signature verification failed: .tools/bin/sigstore/cosign/v3.1.4/cosign [verify-blob --certificate-identity-
  regexp ^<https://github.com/cloudposse/.github/.github/workflows/shared-go-auto-release.yml@> --certificate-oidc-issuer <https://token.actions.githubusercontent>.
  com --
  bundle /var/folders/s3/x60v087551sg6kdzjm3r4sjr0000gn/T/atmos-verify-559584549.json /var/folders/s3/x60v087551sg6kdzjm3r4sjr0000gn/T/atmos-checksum-
  652188209.2_SHA256SUMS]: exit status 1
  Error: failed to verify certificate identity: no matching CertificateIdentity found, last error: expected SAN value to match regex
  "^<https://github.com/cloudposse/.github/.github/workflows/shared-go-auto-release.yml@>", got "<https://github.com/cloudposse/atmos/.github/workflows/release->
  pipeline.yml@refs/heads/main"
  error during command execution: failed to verify certificate identity: no matching CertificateIdentity found, last error: expected SAN value to match regex
  "^<https://github.com/cloudposse/.github/.github/workflows/shared-go-auto-release.yml@>", got "<https://github.com/cloudposse/atmos/.github/workflows/release->
  pipeline.yml@refs/heads/main"

[...rest of the tools...]

✗ Installed 0 tools, failed 1, skipped 13

In my .tool-versions I have this:

atmos 1.233.2

Hey, having an issue with metadata.component inheritance in Atmos 1.233.0.

My stack inherits an abstract with metadata.component: lxd/talos-nodes. describe component shows that inherited metadata, but the top-level component
remains k8s_nodes. During describe affected, an atmos component lookup then tries using the nonexistent components/terraform/k8s_nodes directory.

catalog entry:

  k8s_nodes/lxd/defaults:
    metadata:
      type: abstract
      component: lxd/talos-nodes

stack entry:

  k8s_nodes:
    metadata:
      inherits:
        - k8s_nodes/lxd/defaults

Setting metadata.component explicitly on the stack entry fixes it...

is this intended behaviour?

Heads up github.com/cloudposse/atmos/issues/3475

Heads up! Whether you're hiring and looking for developers who are familiar with atmos, or you're a dev with atmos experience looking for work, feel free to reach out to me. Sometimes I can make intros. No promises 😃

Plugins are coming to atmos! We're starting with laying the foundational work, with initial support for writing auth extensions. You can see what the DX is writing auth plugins. Feedback welcome.

pr-3459.atmos-docs.ue2.dev.plat.cloudposse.org/changelog/native-auth-plugins

Another finding, I didn't open an issue, as I plan to switch to terraform_workspace_template, so JFYI

terraform_workspace_template does not work in Global Metadata - it fails on schema validation. Underlying functionality may be already in place
github.com/cloudposse/atmos/issues/3452

Hello! I might have found a bit of a bug with the !terraform.state YAML function. I have created a GitHub issue for it github.com/cloudposse/atmos/issues/3446. I would be happy to provide any other information if needed! Hopefully it's a legitimate issue and not a configuration issue on my part, that would make me look real dumb... 😅

Looking forward to trying out the new features introduced in 1.233! And thank you for fixing the last issue I opened (github.com/cloudposse/atmos/issues/3213) 😄

We just released Atmos 1.233.0

I am really excited about this release. It introduces 3 very significant features.
• Native AWS CloudFormation support (if you previously used AWS Rain - archived), then this is for you!
• Atmos Script (based on Starlark), every aspect of atmos can now be directly controlled in a python-like scripting language. Eliminate bash/incompatibilities and use starlark instead. You can use it in any workflows, custom commands, even as #!/usr/bin/atmos
• Atmos Policy Engine - you can control every thing atmos does now by policy. You can block functions (e.g. !exec), you can require webhooks to run when certain events happen, you can trigger hooks for stacks with certain labels, etc.
github.com/cloudposse/atmos/…/…

@Erik Osterman (Cloud Posse) is there any appetite to have labels be able to be an or operator also - meaning if I had a component with deployment: stg,prd it could be either deployment: stg, or deployment: prd, or both if that was passed in?

Hello! 👋 Haven't posted in here a ton as Atmos typically does the job for us. I run a team of DevOps/Platform/DBA folk. Our DBA has been battling this bug: github.com/cloudposse/atmos/issues/2088 for some time. Doesn't seem as if it's gained any traction. Curious if this will be addressed or if there is a workaround suggested?

We launched a new sidebar making it easier to find what you're looking for. Use the filter to quickly sift through available options.
atmos.tools/cli

Pretty awesome way to build idempotent lamba artifacts using atmos hooks. Using this to deploy a lambda we use to send a daily AWS budget cost report.

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?

Improved formatting for --ui coming in 1.230.0

ATMOS looks like it is trademarked in this picture.

Loving these new slack notifications.

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!

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.

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

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

newish

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

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.

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

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

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.

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

anyone have experience submitting packages to Chainguard?

@here — we’re working to bring Atmos into Iron Bank: p1.dso.mil/iron-bank

If you’re using Atmos with a federal government customer, please DM me. We’re gathering reference customers to support the submission, just need company name.

Hi Cloud Posse team,

At the beginning of this year, we started a successful migration away from a monolithic Terraform setup toward an Atmos-based component architecture. At this point, we already have more than 100 internal components used across our engineering teams.

One thing we approached differently from the patterns I’ve seen in Atmos/Cloud Posse is dependency resolution between components.

I’ve noticed that Atmos/Cloud Posse patterns make fairly extensive use of Terraform remote state to pass information between components. In our setup, we managed to avoid remote-state dependencies entirely by using provider data sources together with a tag-based resource discovery convention.

For example, an EKS cluster is tagged with a logical discovery identity like this:

eks_discovery_tags = {
  atmos_discovery_namespace     = var.namespace
  atmos_discovery_project       = var.project
  atmos_discovery_environment   = var.environment
  atmos_discovery_atmos_stack   = local.eks_discovery_stack
  atmos_discovery_resource_type = "eks"
  atmos_discovery_resource_key  = "default"
}

Consumers then discover the actual resource through the cloud provider API using these tags, rather than reading outputs from another component’s Terraform state.

In practice, this gives us a resource-discovery contract based on logical identity, while the cloud control plane remains the source of truth for resolving the actual resource. Terraform state is used for ownership and lifecycle management, but not as the communication mechanism between components.

We also use the concept of shared resources. A stack can act as a shared stack and provide infrastructure resources that are consumed by multiple other stacks. Those consumers do not need a direct dependency on the shared stack’s Terraform state. Instead, they discover the resources through the same logical discovery convention.

For example, a shared stack may provide an EKS cluster, VPC, subnets, Route53 zones, or other common infrastructure. Multiple application stacks can then reference those resources by their logical identity without needing to know which Terraform component created them or where its state is stored.

Conceptually, this gives us a relationship like:

shared infrastructure stack
        |
        +-- EKS
        +-- VPC
        +-- subnets
        +-- Route53
        |
        v
cloud provider API + discovery tags
        |
        +--> application stack A
        +--> application stack B
        +--> application stack C

This has been particularly useful for keeping shared infrastructure reusable without introducing explicit state-level coupling between the shared stack and every consumer.

Another side effect we found particularly useful is that our Atmos component definitions remain relatively clean. They describe the actual configuration of the component without also having to encode explicit remote-state relationships to its dependencies.

For example, our component definitions look roughly like this:

components:
  terraform:
    argocd:
      source:
        uri: git::<ssh://git@example.org/platform/platform-components.git//components/argocd>
        version: argocd-v1.7.1

      vars:
        health_check: true
        route53_zone_name: <http://dev.example.com|dev.example.com>

        git_repos:
          - url: '{{ .settings.project_repository }}'
            ssh_key_s3_bucket: tf-state-dev
            ssh_key_s3_key: /secrets/...

      provision:
        workdir:
          enabled: true

Dependencies such as the EKS cluster, VPC, subnets, or other infrastructure can be resolved by the component itself through the discovery convention, instead of requiring the stack definition to explicitly wire outputs from other Terraform states.

I’m curious whether Cloud Posse considered this kind of resource-discovery approach when designing the Atmos component model.

What were the main reasons for preferring remote-state/output-based dependencies between components instead?

Oh, another weird thing I am seeing. .workdirs are getting created with weird names, it's adding an h to strings so it's like
normal-hstring-hmore-hstrings - 1.226.1 first string is normal, others get prepended

@Erik Osterman (Cloud Posse) btw we ran into more concurrency errors using a dual core runner 🧵

Any idea how can be renamed vars like environment and stage? IE to rgn and acc_name

They are used in name_patern and even if I use name_template, and redefine terraform_workspace_pattern it will still fails, as in underlying CP modules exist data sources like this which have pre-hardcoded var names.

I tried a bunch of things, but looks like I can't set some setting like environment: '{{ .vars.rgn }}' and forget about it?

Hello,
When running atmos terraform deploy or atmos terraform apply --all with concurrency > 1, we see atmos ignore the provider/module cache in github and pull the provider for every component. Is that expected behavior?

❓️ there's no stack level retry settings, correct? Only way to easily put them on every component would be an abstract import on each?

For sure running into another bug with the masking thing. I also had to to set the cli flag to disable masking, the config in the atmos.yaml for some reason wasn't working completely.
Seems to be specifically when I'm using DAG also, because of the same thing with the whole RDS thing.

May have found an edgecase with DAG, not sure if intended

Anyone doing anything cool with atmos docs?

One of the frequent requests we get from customers is that they wish they knew all the things that have changed in Atmos that they should be taking advantage of... And this is actually possible today. If you run atmos ai skill install And use the "Atmos Modernization" skill, Claude can help you update your configurations to use the latest patterns.

atmos.tools/ai/agent-skills

atmos.tools/cli/commands/ai/skill

two more bugs, continue dive into --config
github.com/cloudposse/atmos/issues/2867
github.com/cloudposse/atmos/issues/2868