The infrastructure tooling market has a lock-in problem. Not the malicious kind — the gravitational kind. Platforms start by solving a real problem, then gradually expand until they become the center of your workflow. Before you know it, your state is in their backend, your runs are on their compute, your team has learned their UI, and switching costs are enormous.
We built Atmos Pro with a different constraint in mind. Instead of asking "how much of the workflow can we own?", we asked "what is the smallest surface area we can occupy while still being genuinely useful?" That question shaped everything — from the architecture to the pricing to the things we deliberately chose not to build.
Four principles
- 1Stay in GitHub.GitHub is where developers already live. Code review happens there. CI/CD runs there. Notifications flow through it. When we designed Atmos Pro, we made a deliberate choice: your day-to-day workflow should not change.Atmos Pro posts deployment plans as PR comments. It uses GitHub's OIDC tokens for authentication — no long-lived secrets sitting in your environment. It dispatches GitHub Actions workflows rather than running its own compute. The dashboard exists for when you need the big picture, but the daily work stays where it already is.This is not a concession. It is a design principle. GitHub has invested billions of dollars in building a developer experience that your team already knows. We would rather build on top of that investment than compete with it.
- 2Add, don't replace.Atmos Pro installs as a GitHub App. It works with your existing Atmos workflows and GitHub Actions configurations. It does not replace your CI system. It does not manage your Terraform state. It does not host your runners. It does not require you to restructure your repositories.It is a coordination layer — it handles the ordering, locking, and drift detection that are tedious to build yourself, and it stays out of the way for everything else. Think of it as the orchestrator that sits between your pull requests and your deployment workflows, solving the problems that every team eventually hits when they scale past a handful of stacks.We have seen too many teams adopt a platform that starts simple and then slowly becomes the center of gravity for their entire infrastructure workflow. By the time they realize the trade-off, the migration cost is prohibitive. We would rather stay thin and earn our place through utility, not dependency.
- 3Honest pricing.Your infrastructure bill should not go up because your infrastructure grows. We designed pricing around committer seats — the people who trigger deployments — not resources under management, not workflow runs, not concurrency limits.Dashboard viewers are always free. Every tier includes unlimited runs, unlimited self-hosted runners, and unlimited resources. The cost of your tooling should be proportional to the size of your team, not the size of your cloud bill.This is an intentional rejection of the resource-based pricing that dominates the infrastructure tooling market. When your pricing model penalizes growth, you create a perverse incentive for teams to consolidate or avoid the tool for certain workloads. We do not want to be something you use selectively. See the full breakdown on our pricing page.
- 4Accept the ecosystem.Terraform is not the only infrastructure tool, and it will not be the last. OpenTofu is doing important work. The orchestration problem — sequencing deployments, preventing conflicts, detecting drift — exists regardless of which IaC tool you use.We built Atmos Pro with this in mind. The coordination patterns we implement are not Terraform-specific in concept, even if Terraform and OpenTofu are where we start. Dependency ordering, state locking, drift detection — these are universal problems that arise whenever you manage infrastructure as code at scale.The infrastructure ecosystem is healthier when tools compose rather than compete. We would rather be one well-built layer in a thoughtful stack than a monolith that tries to do everything.
The design constraint
If Atmos Pro disappeared tomorrow, your GitHub Actions workflows would still work. That is the design constraint we hold ourselves to.
No proprietary state. No proprietary runners. No proprietary workflow format. Your Atmos configuration, your GitHub Actions workflows, your Terraform code — all of it works without us. We are an accelerant, not a dependency.
We think that constraint makes us build a better product, because we have to earn our place in your stack every day. If we stop delivering value, you can walk away without a migration project. That keeps us honest in a way that lock-in never could.
Where this comes from
This philosophy comes from experience — from years of working with platform teams and watching them get locked into platforms they could not easily leave. The pattern is always the same: a tool solves a real problem, the team adopts it, the vendor expands scope, and by the time the team wants to leave, the switching cost is measured in quarters, not weeks.
We built Atmos Pro to break that pattern. Read about why we built Atmos Pro for the full origin story, or see what it looks like in practice.
Try the lightest-weight approach
Atmos Pro installs in minutes and works with your existing GitHub Actions workflows. No migration required.
