If you work with AWS CloudFormation across multiple environments, you probably know this routine.
You have Development, Test, and Production AWS accounts.
Development is moving constantly. Test is usually a little behind. Production is further behind.
And when you're ready for a release, someone has to figure out:
What exactly changed in Dev?
Which of those changes are already in Test?
What is Test running that Prod isn't?
And most importantly:
What actually needs to be promoted?
The frustrating part is that AWS CloudFormation doesn't really answer these questions across environments. The same logical infrastructure can also have completely different stack names in different accounts. So before you can even compare them, you need to know that those stacks represent the same thing.
That was the problem I wanted to solve.
Meet PromoteOps
PromoteOps connects to your multiple AWS accounts and generates a report showing the promotion state of your CloudFormation stacks.
Instead of manually going through stacks and trying to figure out what's different, you get a clear view of what's current and what's behind.
Everything is current:
When something is outdated:
And when you need to understand exactly why a stack is considered outdated, you can inspect the CloudFormation template diff directly.
So the workflow becomes:
Report → Identify → Diff → Plan → Promote
From reporting to promotion
Once I had the ability to identify what needed to move between environments, I wanted to make the promotion itself part of the workflow.
So I built PromoteOps as an MCP server.
It exposes tools such as:
- report_stacks
- diff_stack
- plan_stack_promotion
- execute_stack_promotion
This allows an MCP-compatible AI client to interact with the infrastructure instead of treating the report as a static dashboard. You can ask what's different between environments, inspect a stack's changes, create a promotion plan, review it, and then execute the promotion. But infrastructure changes shouldn't be treated like a simple file operation. So the promotion workflow includes safeguards.
PromoteOps verifies the target environment hasn't changed since the promotion plan was created and prevents stale plans from being blindly executed.
The goal isn't to let AI blindly deploy infrastructure.
It's to give AI a structured and controlled way to understand what's happening before anything gets promoted.
The problem in one sentence
PromoteOps answers a simple question that becomes surprisingly difficult with CloudFormation across multiple AWS accounts:
What's ready to move from Dev → Test → Prod?
And once you know the answer, it can help you move it.
It's open source
PromoteOps is available on npm and GitHub:
npm: https://www.npmjs.com/package/promoteops
GitHub: https://github.com/Hitesh1326/promoteops
If you work with CloudFormation across multiple AWS accounts and this problem sounds familiar, I'd genuinely like to hear how you handle it today.
Top comments (0)