cloudposse/atmos: one CLI runtime for Terraform, Kubernetes and Helm

The problem Atmos solves for platform teams

A team running Terraform across a dozen AWS accounts usually ends up with a shell script that exports AWS_PROFILE, another that writes backend.tf per environment, a third that installs the right Terraform binary before the run, and a CI job that guesses which directories changed. None of that is Terraform. It is glue, and it drifts between the laptop and the pipeline.

Atmos targets that glue. The README describes it as "the open-source runtime for infrastructure" that builds, authenticates and ships Terraform, OpenTofu, Packer, Ansible, Kubernetes, Helm and containers the same way locally, in CI and with agents. The audience is explicit in the README: Cloud Posse says it runs production infrastructure on AWS, Azure and GCP with Atmos, and that startups and enterprises managing thousands of components do the same. If you have one Terraform root module and one AWS account, this is not aimed at you.

Stacks, components and what the runtime actually does

Atmos models infrastructure as stacks and components. A component is a reusable unit of infrastructure, typically a Terraform root module. A stack is a configuration overlay that points components at a specific account, region and stage. The README frames this as "Model your platform once as stacks and components, authenticate once, and run the same commands everywhere," with DRY configuration replacing copy-paste per environment.

The runtime layer sits around that model. Auth is one identity layer across AWS, Azure and GCP using SSO, OIDC and federation, and the README states EKS and ECR login happen automatically. Secrets are declared per environment and sourced from what the README calls 10+ backends including 1Password, SSM, Vault and SOPS, then masked across output channels. Vendoring pulls dependencies just in time with version pinning and retries. A toolchain component auto-installs the exact Terraform, OpenTofu and Helmfile versions a stack needs, verified by checksum. Backends and providers are generated rather than hand-written.

Two details in the repository show how seriously the toolchain path is treated. The Dockerfile pins debian:trixie-slim because the comment says Checkov, installed through the Atmos toolchain as a PyInstaller bundle, needs GLIBC_2.38 or newer and fails on bookworm. And go.mod pins github.com/1password/onepassword-sdk-go to v0.3.1 with a comment explaining that v0.4.0 and later add a desktop-integration build guard that breaks under CGO_ENABLED=0, Atmos's cross-platform build mode. Those are the kinds of constraints you inherit when a CLI takes responsibility for installing other people's binaries.

Installing Atmos and running your first describe

The README points to https://atmos.tools for documentation and offers a GitHub Codespaces badge so you can try the CLI in a browser without installing anything. The repository also ships a Dockerfile that takes the Atmos version as a build argument, so a container image is a supported path. The Dockerfile requires ATMOS_VERSION to be set and fails the build with an error if it is not.

For a local install, the documented route is the atmos.tools site; the README itself does not print a package manager command, so check that page for your platform rather than copying a command from a blog post. Once the binary is on your PATH, the first useful thing to run is a describe, which the README's demo GIF shows as the way to inspect infrastructure configuration.

atmos describe stacks

That command prints the resolved stack configuration, which is the quickest way to confirm Atmos is reading your atmos.yaml and component directories rather than an empty default. If you are working from the repository itself, note that the root Makefile no longer performs development tasks. It prints a migration table and exits 1, mapping old targets to Atmos custom commands.

atmos build deps
atmos build

Those two replace what used to be make deps and make build. The same table maps make test-short to atmos test short and make lint to atmos lint --changed. If you are contributing to Atmos rather than using it, that Makefile is the first thing that will confuse you.

Where Atmos is the wrong tool

The stacks and components model is opinionated, and adopting it means restructuring how your Terraform is organized, not just adding a wrapper. If your infrastructure is a handful of root modules applied by hand or by a simple pipeline, the layering costs more than it returns.

The runtime also owns a lot of surface area. It installs tool binaries, manages credentials, fetches dependencies and can run containers and cloud emulators. Each of those is a place where a failure in Atmos is a failure in your deploy path. The Dockerfile's GLIBC note is a concrete example: a base image choice that would have been irrelevant to a plain Terraform workflow becomes a build-breaking constraint because Atmos installs Checkov for you.

Finally, the README is explicit that AI agents are a first-class target, with agent skills and an MCP server. If your organization does not want an infrastructure CLI exposing itself as an MCP server to a coding agent, that is a feature you have to actively scope out, and the README does not describe a lockdown mode for it. The README is also silent on rollback behavior for failed applies across components, so do not assume Atmos adds transactional semantics on top of Terraform state.

How Atmos differs from Terragrunt and plain Terraform

Terragrunt is the closest comparison most Terraform users will reach for. Both wrap Terraform to avoid repeating backend and provider configuration across environments. Terragrunt stays close to the Terraform CLI and its own HCL dialect; Atmos instead puts a component registry and stack model in front of several tools, and the README lists Packer, Ansible, Kubernetes, Helmfile and containers as component types alongside Terraform and OpenTofu. If your problem is only Terraform DRY-ness, Terragrunt is the smaller change. If your problem is that Terraform, Helmfile and a container build each have their own auth and toolchain story, Atmos is trying to collapse those into one runtime.

Against plain Terraform with a CI pipeline, the difference is where the logic lives. Plain Terraform plus CI means the pipeline decides which directories changed and which credentials to assume. Atmos moves that into the CLI itself: the README describes it as git-aware, detecting what changed and planning or applying only the affected components, and emitting matrices for CI. That is a real shift in responsibility, and it means your CI configuration gets thinner while your atmos.yaml gets more important.

Maintenance, releases and licence

The repository is not archived, and the last push was on 2026-09-10, ten days before this writing. Releases are frequent: v1.228.0 landed on 2026-09-06, with v1.229.0-rc.0 on 2026-09-08 and test builds in between. A release cadence that includes release candidates and test-tagged builds suggests the project expects users to pin versions rather than track main.

That cadence is also the upgrade cost. Atmos is a Go binary distributed as a CLI, and the pinned dependency comment in go.mod about the 1Password SDK shows that upstream changes can break Atmos's own build mode. If you vendor Atmos into a build pipeline, expect to follow releases rather than sit on one for a year.

The licence is Apache-2.0, which permits commercial use and modification and includes an explicit patent grant. The repository carries a NOTICE file, which Apache-2.0 expects you to preserve when redistributing. If you build a product around Atmos, read the NOTICE and your own legal team's guidance; nothing here is legal advice.

Editorial conclusion

Adopt Atmos if your team already runs Terraform or OpenTofu across many accounts and environments and is tired of maintaining wrapper scripts for auth, backends and tool versions. Do not adopt it if you have a single Terraform root module and no multi-environment matrix; the stacks and components model would be overhead with no payoff. Before committing, verify two things in your own repository: that the pinned Go toolchain in go.mod builds on your CI runners, and that the components you already have map cleanly onto Atmos component types rather than needing custom ones.

Frequently asked questions

Official sources

1. cloudposse/atmos on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases