Atmos Pro launched two weeks ago, and the response from the community has been exactly what we hoped for — thoughtful feedback from teams who have been dealing with these problems for years. Platform engineers who have spent months building custom orchestration scripts, teams who have been burned by drift they did not catch in time, organizations juggling dozens of AWS accounts with no unified view of what is deployed where. These are the people we built this for, and hearing their reactions has been both validating and energizing.
We have been building Atmos Pro with early users for the past year, and their input has shaped every feature we shipped at launch. Now we want to share where we are headed next. This is not a speculative roadmap full of things we might get to someday. These are the problems our users are telling us to solve, informed by patterns we see across the teams already using Atmos Pro in production.
Some of our early users manage hundreds of stacks across dozens of AWS accounts. At that scale, every interaction with the system needs to be fast — loading the dashboard, filtering drift status, searching event history. A platform team managing 200 stacks across 40 accounts should not wait longer than a team managing 10 stacks across 2 accounts. We are investing heavily in performance work to ensure Atmos Pro handles organizations with 500+ stacks and thousands of resources under management without compromising the experience.
This includes pagination improvements across the dashboard, smarter data loading that fetches only what you need, and optimized queries for cross-repository analytics. We are also rethinking how we surface aggregate information — rollup views that give you the health of an entire environment at a glance, without requiring you to drill into individual stacks. When your infrastructure is that large, the dashboard needs to be a command center, not a search engine.
Today, Atmos Pro detects which stacks a pull request touches based on the files changed. This is useful — it tells you what you are directly modifying — but it is only the beginning. The harder question is: what else does this change affect?
We are building dependency-aware impact analysis — the ability to understand the downstream effects of a change across your entire infrastructure graph. Change a VPC module, and Atmos Pro will show you every stack that depends on it, across every environment and every repository. Change a shared security group configuration, and see exactly which services inherit that change. This is the kind of visibility that turns a risky change into a confident one. Instead of guessing at blast radius, you see it clearly before you merge. Instead of relying on tribal knowledge about which stacks connect to which, you get a definitive answer computed from your actual dependency graph.
Our commitment to being GitHub-native is not just about where the app installs — it is about making the GitHub experience genuinely richer for infrastructure teams. Upcoming improvements include more detailed PR comments with plan summaries, so you can see exactly what Terraform will change without leaving the pull request. We are working on collapsible plan output that highlights additions, modifications, and destructions in a format that is easy to scan during code review.
We are also building tighter integration with GitHub deployment environments and more granular status check reporting. Today you get a single status check for your infrastructure changes. Soon, you will see individual checks per affected stack, making it immediately clear which parts of a change succeeded and which need attention. The goal remains the same: your workflow stays in GitHub, and it gets better over time. We are not building a separate UI that competes with your pull request — we are making your pull request the best place to review infrastructure changes.
ENTERPRISE ROADMAP
Multiple GitHub organization support for large enterprises
Webhooks and API for integrating with internal tools and workflows
GitHub Enterprise Server support for on-premises installations
SOC 2 Type II certification (in progress)
Self-hosted deployment options for regulated industries
Enterprise infrastructure has enterprise requirements. We are building the compliance, security, and integration features that large organizations need to adopt Atmos Pro with confidence. These are not afterthoughts — they are driven by conversations with teams at financial institutions, healthcare companies, and government contractors who want the workflow improvements Atmos Pro provides but need to meet regulatory and security standards first. We are committed to earning trust at the enterprise level without compromising the simplicity that makes Atmos Pro effective for smaller teams.
Atmos Pro is not becoming a CI system. It is not becoming a state backend. It is not becoming a module registry. There
are excellent tools for each of those, and we integrate with them rather than replacing them.
This is a deliberate constraint, not a limitation. Our
design philosophy centers on providing the minimal glue to connect the tools you already use. Every feature we build is evaluated against that principle. If something exists and works well in the ecosystem, we integrate with it. We only build what is missing. This keeps Atmos Pro lightweight, reduces your switching costs, and ensures we stay focused on the coordination problems that nobody else is solving well.
We are building Atmos Pro for platform teams, and platform teams are telling us what to build next. If you have thoughts on what we should prioritize — a pain point we have not addressed, an integration that would save your team hours — we want to hear about it. Join us in our
Slack community or reach out directly. The best products are built in conversation with the people who use them, and that conversation is just getting started.
Get started today
The Free tier includes everything you need to experience Atmos Pro — ordered deployments, locking, drift detection, and the full dashboard.
|