Every stack accounted for.
Stackmuster scans your repositories for CloudFormation templates and keeps each stack in step with its template: created when a template is added, updated when it changes, deleted when it's removed. If it's not in the repository, it shouldn't be running.
One email when early access opens, around November 2026. Nothing else, and no sharing with anyone.
Moving off AWS Proton? Read the migration guide.
The problem
Not all at once, and never deliberately. It happens one reasonable decision at a time.
Someone deployed a change from a laptop during an incident, because that was the fastest way to stop the bleeding. The template in the repository and the stack in the account have not matched since, and nobody is certain which one is correct.
A service was retired a year ago. Its stack is still running, because deleting it means first working out what depends on it, and that has never been anyone's most urgent task. So it stays, and it bills, and the risk of removing it grows.
The tool that deployed them reached end of support. The stacks it created kept running, exactly as documented. The temporary manual process that replaced it is now the permanent way that stack gets updated.
If the retired tool in question is AWS Proton, the AWS Proton end of life migration guide covers what happens to your stacks after 7 October 2026, the options AWS points departing customers at, and the gap each one leaves behind.
How it works
A template lives in your repository. A deployment is an instance of that template inside Stackmuster. The stack is what exists in AWS.
How Stackmuster moves a template from a repository to a deployed stack, in three stages:
A fourth path runs back the other way: when a template is removed from the repository, the deployment deletes the stack it created rather than leaving it running.
Point Stackmuster at your repositories. It finds the CloudFormation templates in them and builds an inventory of the stacks those templates define.
Each template becomes a deployment: an instance of that template inside Stackmuster. Configuration happens once against a repository, not once per stack, so adding the two hundredth template costs the same as adding the second.
The deployment is what acts on AWS. It creates the stack when a template is added, updates it when the template changes, and deletes it when the template is removed from the repository, instead of leaving it behind.
Scope
The boundary matters more than the feature list, so here it is plainly.
So a stack you already have is not out of reach. Write a template for it and add that to a repository Stackmuster scans. If the stack name it would deploy under is already taken, Stackmuster stops and asks what to do rather than deciding for you. Choose to take the existing stack over, and it updates and deletes that stack from then on like any other.
Deploying CloudFormation normally needs credentials that are effectively full administrator. Stackmuster will let you attach an IAM permissions boundary to the access it deploys with, so you decide what it should never be able to do, whatever a template asks for, such as creating IAM users or access keys, or launching EC2 instances directly.
Comparison
Git sync is configured once per stack. Stackmuster is configured once.
Git sync creates and updates. It doesn't delete.
| Behaviour | CloudFormation Git sync | Stackmuster |
|---|---|---|
| Setup | Once per stack, via console | Once, per repo |
| Create / update | Yes | Yes |
| Delete when template removed | No | Yes |
| Scope | One repo + branch, one stack | Many templates, repos, accounts |
| Cost | Free | Free tier, then paid |
If you have a single repository and a handful of stacks, use CloudFormation Git sync. It is native, it costs nothing, and configuring it a few times by hand is not a burden worth solving. Stackmuster earns its cost when the number of stacks, repositories or accounts makes per-stack configuration the thing that stops scaling.
Who builds it
Stackmuster comes from a developer building deployment automation at Autyra, who kept meeting the same thing on client work: stacks still running that no longer matched any template in a repository. Setting each one up by hand was fine for a few, and stopped being fine somewhere past that.
Stackmuster is a product of Autyra Pty Ltd, an Australian automation consulting company. It is built on the same platform core as Automeer, Autyra's managed CI/CD platform, which is where the deployment engine comes from.
Early access
Stackmuster is not available yet. We are targeting November 2026 for early access, and this list is how we let you know it has opened.
You will get one email when early access opens, and an occasional note if something changes about the timing. No newsletter, no drip sequence, and your address is not shared with anyone. It is stored on infrastructure we run ourselves.
One email when early access opens, around November 2026. Nothing else, and no sharing with anyone.