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

👋 Hello, team!

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

Hi, team. I was brainstorming an idea but I'm having some trouble with the execution. I'm just wondering if this seems do-able.

We use Atmos + Terraform to build everything. We run almost exclusively on K8s, mostly via Kustomize and ArgoCD. Injecting dynamic information from our Terraform into Kustomize can be a bit awkward at times. So, I had the following idea with Atmos:
• Create inline manifests with Kubernetes components. These manifests would actually be Kustomization files (either resources or components/patches).
• I would deploy these manifests to some dedicated branch in the repository that contains our other Kustomize manifests.
• I would configure the appropriate Kustomize configurations to "include" this dedicated branch as-needed.
• Example. I need to inject a security group ID created by some Terraform into an annotation or configmap somewhere. I could have an inline manifest (Kustomize patch) that gets deployed to a pre-determined location in the dedicated branch. Then the appropriate Kustomize configurations can "include" that manifest rendered and deployed by Atmos.
Problem is, I'm having some trouble choosing the file name. I often need the generated manifest to be called kustomization.yaml , but it seems like the name might be automatically generated. Is it possible to override this behavior? I saw the split setting for rendering, but I didn't see something similar when deploying an inline manifest.

And also, proposal, useful for make new atmos features works fine with all existing stable features from the start (except very weird corner cases)
https://github.com/cloudposse/atmos/issues/2865

one more bug
github.com/cloudposse/atmos/issues/2863

P.S. should I post them all here, or you're usually look in repo new issues inbox?

Hi all 👋

Not entirely sure if this is the right channel or #atmos-dev, but I posted a proposal for dynamic file generation (for_each) in atmos scaffold, see: github.com/orgs/cloudposse/discussions/126. Would appreciate some feedback there 🙏.

fyi github.com/cloudposse/atmos/issues/2839

Hi, there. I am currently working with atmos helmfile and is there a way that the values from stack config gets applied automatically when running command atmos helmfile diff/apply <component> -s <stack>, instead of passing values filename manually like below in helmfile.yaml. Also atmos generated values file eg: aws-useast1-metrics-server.helmfile.vars.yaml are getting with stack identification values like namespace, environment, stg where some helm charts are failing with validation errors like chart doesn't allow those extra values. Thank you. @PePe Amengual

repositories:
  - name: metrics-server
    url: <https://kubernetes-sigs.github.io/metrics-server/>

releases:
  - name: metrics-server
    chart: metrics-server/metrics-server
    version: 3.13.0
    namespace: kube-system
    createNamespace: false
    force: false
    values:
      - aws-useast1-metrics-server.helmfile.vars.yaml

Anyone else experience fatal error: concurrent map iteration and map write when using DAG?

Hey there 👋,

New to contributing, not totally sure this is the right place to raise this — point me elsewhere if so!

I finally had time to prototype the native RDS IAM auth idea I floated a while back in a discussion, I linked more context on the original issue but looking at adding atmos aws rds token, plus a rds onnect follow-on — both are draft PRs.

Would love a gut-check on whether it's worth pursuing and the right direction.

Wrote it all up here:
github.com/orgs/cloudposse/discussions/121#…

❓️ is there an atmos native way to arbitrarily look up things from a state backend, if they aren't technically managed by your stack?

Running the curl install listed on the homepage of atmos, immediately ran into the following. Is this supposed to run as sudo? First time posting here, so let me know if this is the wrong way to go about reaching out.

cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=24.04
DISTRIB_CODENAME=noble
DISTRIB_DESCRIPTION="Ubuntu 24.04.4 LTS"

Does anyone tried atmos.tools/changelog/tags-and-labels ?

For some reason, these doesn't work for me (I located them in most top _defaults.yaml):

  metadata:
    labels:
      some_tag: some_value
  vars:
    tags: !labels

Inside generated .tfvars.json after atmos terraform plan:

"tags": {
    "unrelated_tag": "foo"
  },

atmos v1.223.0

Hi, there. I surprised that it not covered from day 1 of hooks introduction
Can you please take a look?
github.com/cloudposse/atmos/issues/2799

really enjoying DAG, seems to be working decently with a PoC for targeted stack precedence

Trying to implement a blue/green pattern in atmos. DAG doesn't work across multiple stacks yet does it?

The recent changes to --help is very welcomed. It's a much better DX then providing all the help information.

Hey everyone! Wondering if anyone else has seen this behavior:

We noticed that after a recent update to cloudposse/github-action-setup-atmos@v3, our atmos terraform deploy and atmos terraform apply commands in GitHub Actions started completing instantly (0 seconds, exit code 0) with no terraform output — no init, no plan, no apply.

The install path changed from /home/runner/work/_actions/cloudposse/github-action-setup-atmos/atmos to /opt/hostedtoolcache/atmos-wrapper/1.222.0/x64. Actions runs using the old path on July 3 worked fine (5-minute deploys); runs using the new wrapper path on July 4+ silently no-op.

Workaround: Setting install-wrapper: "false" resolves it — deploy commands run terraform as expected.

Are we missing a configuration step for the wrapper, or is this a known issue with the latest release? Happy to provide workflow snippets or run logs if helpful. Thanks!

@Erik Osterman (Cloud Posse) Do you know if you can set authentication for an oci JIT source component? Or if it's documented somewhere specific? Specifically a terraform.$component.source.uri

so sick !

Hi. Can you look into github.com/cloudposse/atmos/issues/2376 bug? It still exist in 1.222.0

Hello, I ran into an issue with Native CI in JIT vendored components, added a bug report for it: github.com/cloudposse/atmos/issues/2684
Basically if you source a component direct from github to use directly, and specify a workdir, the native ci planfile logic looks in the wrong spot for the planfile

Hi, do you accept issues made by AI? I found a bug it seems and made codex to file the bug report here: github.com/cloudposse/atmos/issues/2680

Is there some command to apply all components in a specific stack? All flag applies all components in all stacks, not specific one.

Hey, team. I think there might be a documentation snafu.

Here in the Native CI docs, it shows an example of how one can set up Github OIDC auth. This did not work. Atmos complained that the profile was not valid.

auth:
  providers:
    github-oidc:
      kind: github/oidc
      region: us-east-1
  identities:
    plat-dev/terraform:
      provider: github-oidc
      role_arn: arn:aws:iam::111122223333:role/atmos-terraform
      default: true   # Use this identity unless a component overrides it

Fortunately, atmos auth validate was pretty helpful and suggested useful changes, which I was later able to confirm in the more thorough auth section in the Atmos docs. I would humbly suggest that the example for the Native CI section should look something like this.

auth:
  providers:
    github-oidc:
      kind: github/oidc
      region: us-east-1
      spec:
        audience: <http://sts.amazonaws.com|sts.amazonaws.com>
  identities:
    plat-dev/terraform:
      kind: aws/assume-role
      via:
        provider: github-oidc
      principal:
        assume_role: arn:aws:iam::111122223333:role/atmos-terraform
      default: true   # Use this identity unless a component overrides it

Hey, everyone. Random unimportant question.

I think I know the answer, considering the obvious focus of Atmos and Atmos Pro using Github/Gitlab. But I'm curious. Has the team ever considered a Kubernetes Operator approach similar to tofu-controller or burrito? We've been using Atmos for some time now, but we're also a heavy Kubernetes + ArgoCD shop. So, naturally, I found the approach intriguing.

hello, anyone able to confirm if planfile artifact storage to gh artifacts has been implemented as of v1.221.1?

We've published a media kit for atmos! If you've wanted some atmos logos, we got 'em.

https://atmos.tools/media-kit

I’m looking forward to Atmos secrets management. We use Sealed Secrets for our application layer since everything runs on Kubernetes. Managing secrets as code makes deployments much more portable across regions and accounts.

However, for our infrastructure layer, secrets are stored in Secure SSM Parameters and Secrets Manager. The lack of portability has become a small pain point when managing a DR region, so I’ve been considering a move to SOPS. After another practice run of our DR runbook last week, I’m definitely making the switch soon. The timing of Atmos secrets management with SOPS support couldn’t have come at a better time.

Btw, it's a really minor issue, but atmos ai skill does not support vscode natively, as it expect skills in some specific folders.
I've had to make it available this way:

cd <my VScode workspace>
atmos ai skill install cloudposse/atmos -y --force
mkdir -p .github/skills && for d in ~/.atmos/skills/cloudposse/atmos/*/; do ln -sfn "$d" ".github/skills/$(basename "$d")"; done

I recorded a 20-minute overview of the Atmos Changelog covering all of the latest features that have come out over the past month.

https://us02web.zoom.us/clips/share/tQmxbpnfQxGWs-bpWl4sAA

• Atmos Git for GitOps — Manage repositories as first-class Atmos resources; clone, diff, commit, push, and publish generated artifacts through lifecycle hooks.
• Secrets Management — Declare component secret dependencies and manage secrets natively in Atmos.
• CI Caching — Cache toolchains, providers, modules, vendored components, and remote imports to accelerate local and CI runs.
• Terraform Registry Cache(Experimental) — Cache providers and modules for faster, reproducible, and more resilient builds.
• Terraform/OpenTofu RC Management(Experimental) — Define CLI runtime configuration in atmos.yaml; Atmos manages temporary RC files automatically.
• Terraform DAG Concurrency — Dependency-aware execution with concurrent planning and deterministic ordering.
• Interactive Workflows & Commands — 25+ interactive step types for building CLI wizards and guided workflows.
• Atmos Pro STS Tokens — Just-in-time GitHub tokens for CI access to private resources.
• Git Repository Metadata Functions — YAML functions exposing repository metadata.
• atmos.Resolve Template Function — Evaluate YAML functions inside templates.
• Install from Branches & Tags — --use-version supports Git refs directly.
• Dotenv Support in !include — Include .env files directly in YAML.
• !append YAML Function — Extend inherited lists.
• !unset YAML Function — Remove inherited configuration keys cleanly.
• ECR Public Authentication — Authenticated pulls from public.ecr.aws to avoid rate limits.
https://atmos.tools/changelog

hello, we're trying to standardize on making every component declare a standard instance and a dr instance of said component. So under stacks/catalog/network/default.yaml for example, we'd declare our VPC twice referencing components/terraform/network as the component. Now under stacks/deploy/dev.yaml we import our stacks/catalog/network and in the dev.yaml, we'd like to be able to toggle that DR instance on or off. The idea is that every environment has to opt out of provisioning a DR environment. What approach would you recommend to address this? We've had trouble getting a variable passed over to the metadata.enabled because anything we pass gets converted to a string and enabled needs a bool

Hi team, I recently started using the required_providers, required_version and providers atmos fields and wanted to share some findings and get a sense of whether I'm on the right track.

In 1.221.0 you can now define your own custom components. https://atmos.tools/changelog/custom-component-types