#atmos - August 2026

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?

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

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.

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

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

Anyone doing anything cool with atmos docs?

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

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.

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

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?

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?

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

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

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?

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