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//i|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?

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.

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

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?

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

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

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) 😄

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

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

terraform_workspace_template

, so JFYI

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

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 😃

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

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?

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

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

is this currently possible?

I have quite a few use cases for this.

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 understand the recommendation is to use the official helm component type now but we use helmfile elsewhere so still preference it

is that intentional?

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

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