[opensourcedex]

atmos is a free, open source orchestration & scheduling project written in Go and released under Apache-2.0. It has 1,409 GitHub stars, 197 forks and 289 open issues, and was last pushed 14 hours ago. On this registry it ranks #82 of 130 tracked projects in Orchestration & Scheduling, with 5 head-to-head comparisons available. It gained 19 stars over the last 30 tracked days.

What is atmos?

Atmos is the open-source runtime for infrastructure — a Go-based, Apache-2.0 licensed CLI that builds, authenticates, and ships Terraform, OpenTofu, Packer, Ansible, Kubernetes, Helm, and containers the same way on a laptop, in CI, and with AI agents, and it is aimed at the platform and DevOps teams who model cloud environments as declarative stacks and components.

What it is

Atmos lives in the Infrastructure & Operations / Orchestration & Scheduling space. It turns sprawling cloud infrastructure into one declarative system: a platform is modelled once as stacks and components, authenticated once, and then driven with the same commands locally, in CI/CD, and through AI agents. Every environment points at the same reusable root modules, and the rest is treated as configuration, so the same code deploys to every region, environment, and stage using DRY configuration rather than copy-paste.

The concrete problem it solves is tool sprawl. The project frames its purpose as stopping the practice of stringing together 25 tools, writing bespoke wrapper scripts, and maintaining glue between them. Authentication, secrets, vendoring, caching, the toolchain, workflows, CI, and AI are part of the runtime instead of a pile of plugins that must be wired together by hand. The ecosystem it operates in is the Terraform and OpenTofu world of HCL2 configuration, extended to Helm and Helmfile, Kubernetes, Packer, Ansible, and containers.

Key capabilities

  • Unified auth delivers one identity layer across AWS, Azure, and GCP using SSO, OIDC, and federation, with EKS and ECR login happening automatically and the same identity feeding Terraform, stores, and emulators.
  • Secrets are declared per environment and sourced from 10 or more backends, including 1Password, SSM, Vault, and SOPS, then masked across every channel.
  • Vendoring pulls every dependency just-in-time with version pinning and retries, removing the need for a separate vendor step.
  • Caching and mirroring provide a native build cache plus a transparent Terraform provider and module registry mirror.
  • The toolchain auto-installs the exact Terraform, OpenTofu, and Helmfile versions a stack needs, verified by checksum.
  • Workflows and automation chain anything using 25 or more step types and custom commands across every component.
  • GitOps and CI/CD support detects affected components, emits matrices, and catches drift, while AI and MCP integration exposes Atmos as an MCP server, offers 20 or more skills, and accepts an --ai flag on any command.

Who uses it and how

  • Cloud Posse builds and operates production infrastructure on AWS, Azure, and GCP with Atmos every day.
  • Startups and enterprises managing thousands of components use it as the layer above their Terraform and OpenTofu estate.
  • Platform teams plan and apply across every component in dependency order with bounded concurrency, with backends and providers generated automatically and drift caught automatically.
  • Teams that model Helmfile and Kubernetes releases beside the rest of the stack use the same CLI they already use for Terraform.
  • Developers run containers and dev containers as workloads and spin up cloud emulators locally so the whole stack runs on a laptop, with no account required to iterate.

Getting started

The README points to a browser-based trial through GitHub Codespaces, opened from the repository with no local setup. Installation and configuration documentation live at atmos.tools.

How it compares

Atmos sits above Terraform, OpenTofu, Packer, Ansible, Helm, and Helmfile rather than replacing them: those remain the execution engines, while Atmos supplies the identity, secrets, vendoring, cache, toolchain, and workflow layers around them. In this registry it reads as the orchestration layer for that tool set, not as a substitute for any single tool within it.

When to use it — and when not to

A self-hoster takes on operating federation across cloud providers, the chosen secrets backends, the provider and module mirror with its cache, and a checksum-verified toolchain. Teams with no Terraform, OpenTofu, Helm, or container estate, or those who want a vendor-managed hosted service, should look elsewhere, since the documented path is a self-run CLI plus a Codespaces trial. The repository also carries 289 open issues and the README excerpt is truncated mid-section, so expect to lean on the atmos.tools documentation.

project readme (upstream, from github) — read inline

Project Banner

Latest ReleaseLast UpdatedTestsOpenSSF ScorecardSlack Community

Run your infrastructure anywhere.

Atmos is the open-source runtime for infrastructure — it builds, authenticates, and ships Terraform, OpenTofu, Kubernetes, Helm, and containers the same way on your laptop, in CI, and with AI agents. Auth, secrets, vendoring, caching, the toolchain, workflows, and CI are built in. Point every environment at the same reusable root modules and treat the rest as configuration. Stop stringing together 25 tools.

Run it on your laptop. Run it the same in CI. Run it with agents.

Everything is open source and free.

[!TIP]

You can try out atmos directly in your browser using GitHub Codespaces

Open in GitHub Codespaces

Already start one? Find it here.

Screenshots


Example of running atmos to describe infrastructure.

Introduction

Atmos turns sprawling cloud infrastructure into one declarative system you can run consistently — locally, in CI/CD, and through AI agents. Model your platform once as stacks and components, authenticate once, and run the same commands everywhere. The same code deploys to every region, environment, and stage with DRY configuration — no copy-paste, no bespoke wrapper scripts, no glue.

Cloud Posse builds and operates production infrastructure on AWS, Azure, and GCP with Atmos every day — and so do startups and enterprises managing thousands of components.

Everything you'd otherwise bolt on

Auth, secrets, vendoring, caching, the toolchain, workflows, CI, and AI are part of the runtime — not a pile of plugins you wire together.

  • Unified Auth: One identity layer across AWS, Azure, and GCP — SSO, OIDC, and federation. EKS and ECR login happen automatically, and the same identity feeds Terraform, stores, and emulators.
  • Secrets Management: Declare secrets per environment, source them from 10+ backends (1Password, SSM, Vault, SOPS, and more), and mask them across every channel.
  • Vendoring: Pull every dependency just-in-time with version pinning and retries — no separate vendor step.
  • Caching & Mirroring: A native build cache plus a transparent Terraform provider and module registry mirror — warm in CI, instant on your laptop.
  • Toolchain: Auto-install the exact Terraform, OpenTofu, and Helmfile versions your stacks need — verified by checksum.
  • Workflows & Automation: Orchestrate, automate, and chain anything with 25+ step types and custom commands across every component.
  • GitOps & CI/CD: The same commands locally and in CI. Detect affected components, emit matrices, and catch drift.
  • AI + MCP: Chat about your infrastructure, run 20+ skills, expose Atmos as an MCP server, or add --ai to any command.

Run anything, the same way

  • Terraform & OpenTofu like a platform team. Plan and apply across every component in dependency order with bounded concurrency. Backends and providers are generated for you, and drift is caught automatically.
  • Kubernetes & Helm as first-class workloads. Model Helmfile and Kubernetes releases beside the rest of your stack, with the same CLI you already use for Terraform.
  • Containers and cloud emulators. Containers and dev containers are workloads too — and you can spin up cloud emulators locally so your whole stack runs on your laptop, with no account required to iterate.
  • Bring your own. Packer, Ansible, or your own component types plug into the same registry the built-ins use.

Your laptop is the CI. CI is your laptop.

Same command, same auth, same secrets, same toolchain — whether you run it locally or in a pipeline. Atmos is git-aware: it detects what changed and plans or applies only the affected components, so CI does exactly the work that changed — nothing more.

Built for your agents

Everything is declarative and self-documenting, so AI agents can reason about your infrastructure instead of stringing together 25 tools and praying. Atmos ships a catalog of portable agent skills — working across Claude Code, Cursor, Gemini, and Copilot — and an MCP server so any agent can install what it needs and drive Atmos directly, as native tools, with no custom integration.

Extend it without forking it

  • Custom Commands: Wrap any script as a first-class atmos command with flags, args, and identity.
  • YAML Functions: Resolve state, outputs, secrets, and Git metadata right inside your config.
  • Hooks: Run infracost, checkov, trivy, or any command on lifecycle events.
  • Stores: Plug in SSM, Secrets Manager, Key Vault, Vault, Redis, and more for cross-component data.
  • Validation: Enforce your own guardrails with OPA/Rego policies and JSON Schema.
  • Templates & Data Sources: Pull live data into your config with Go templates and Gomplate datasources.

Use Cases

Atmos has consistently proven its strength across the cloud infrastructure and DevOps domains:

  • Managing Large Multi-Account Cloud Environments: Suitable for organizations using multiple cloud accounts to separate different projects or stages of development.
  • Cross-Platform Cloud Architectures: Ideal for businesses that need to manage configuration of services across AWS, GCP, Azure, etc., to build a cohesive system.
  • Multi-Tenant Systems for SaaS: Perfect for SaaS companies looking to host multiple customers within a unified infrastructure. Define a baseline tenant configuration once, then onboard new tenants by reusing this baseline through pure configuration — no further code required.
  • Efficient Multi-Region Deployments: Define baseline configurations with stacks and extend them across regions with DRY principles through imports and inheritance.
  • Compliant Infrastructure for Regulated Industries: Create vetted configurations that comply with SOC2, HIPAA, HITRUST, PCI, and other standards, then share and reuse them across the organization via service catalogs, component libraries, vendoring, and OPA policies.
  • Empowering Teams with Self-Service Infrastructure: Let teams manage their infrastructure independently, using predefined templates and policies.

[!TIP] Don't see your use-case listed? Ask us in the #atmos Slack channel, or join us for "Office Hours" every week.

Telemetry

Atmos collects anonymous telemetry to help improve the product by understanding how it's used.

You can opt-out of telemetry collection in either of the following ways:

  • Set settings.telemetry.enabled: false in your atmos.yaml
  • Or set the environment variable: ATMOS_TELEMETRY_ENABLED=false

Note for Atmos Pro users: If you're using Atmos Pro, your workspace ID will be included in telemetry events. This allows our team to provide more effective support and assist with troubleshooting as part of your subscription.

To learn more about what is collected and how it works, see the Telemetry Documentation.

Documentation

Find all documentation at: atmos.tools

✨ Contributing

This project is under active development, and we encourage contributions from our community.

Many thanks to our outstanding contributors:

For 🐛 bug reports & feature requests, please use the issue tracker.

In general, PRs are welcome. We follow the typical "fork-and-pull" Git workflow.

  1. Review our Code of Conduct and Contributor Guidelines.
  2. Fork the repo on GitHub
  3. Clone the project to your own machine
  4. Commit changes to your own branch
  5. Push your work back up to your fork
  6. Submit a Pull Request so that we can review your changes

NOTE: Be sure to merge the latest changes from "upstream" before making a pull request!

🌎 Slack Community

Join our Open Source Community on Slack. It's FREE for everyone! Our "SweetOps" community is where you get to talk with others who share a similar vision for how to rollout and manage infrastructure. This is the best place to talk shop, ask questions, solicit feedback, and work together as a community to build totally sweet infrastructure.

📰 Newsletter

Sign up for our newsletter and join 3,000+ DevOps engineers, CTOs, and founders who get insider access to the latest DevOps trends, so you can always stay in the know. Dropped straight into your Inbox every week — and usually a 5-minute read.

📆 Office Hours

Join us every Wednesday via Zoom for your weekly dose of insider DevOps trends, AWS news and Terraform insights, all sourced from our SweetOps community, plus a live Q&A that you can’t find anywhere else. It's FREE for everyone!

License

License

Preamble to the Apache License, Version 2.0

Complete license is available in the LICENSE file.

Licensed to the Apache Software Foundation (ASF) under one
or more contributor license agreements.  See the NOTICE file
distributed with this work for additional information
regarding copyright ownership.  The ASF licenses this file
to you under the Apache License, Version 2.0 (the
"License"); you may not use this file except in compliance
with the License.  You may obtain a copy of the License at

  https://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing,
software distributed under the License is distributed on an
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express or implied.  See the License for the
specific language governing permissions and limitations
under the License.

Trademarks

All other trademarks referenced herein are the property of their respective owners.

Copyright © 2017-2026 Cloud Posse, LLC

README footer

Beacon

Frequently asked questions

Is atmos free to use?

atmos is open source under the Apache-2.0 licence. There is no licence fee and no seat count — you can self-host it or, where the project offers one, pay a vendor for a managed version instead.

What does atmos do?

Atmos is the open-source runtime for infrastructure — it builds, authenticates, and ships Terraform, OpenTofu, Packer, Ansible, Kubernetes, Helm, and containers

What is atmos written in?

atmos is primarily written in Go. Its source is publicly available at https://github.com/cloudposse/atmos, and it has 1,409 GitHub stars.