AWS Proton end of life: what happens to your stacks, and what to do next

AWS Proton stopped accepting new customers on 7 October 2025 and reached end of support on 7 October 2026. At that point the service was switched off and the data held inside it was deleted.

The part that matters most is the part that is easiest to miss. AWS has been clear that the infrastructure Proton deployed is not affected: your CloudFormation stacks and the resources inside them remain intact and keep running. What disappears is Proton itself: the templates registered in it, the environment and service definitions, and the delivery pipelines it managed for you.

That distinction shapes the whole migration. This is not a rescue operation for production infrastructure. It is a rebuild of the delivery path that sits in front of it.

If you were still running Proton when it ended, this guide covers what actually broke, what you can still recover, the one migration problem that catches people out, and how to choose between the replacements AWS recommends, including the cases where the right answer is a free AWS service rather than anything you pay for.

The timeline

Check these dates against the current AWS documentation if you are planning around them. AWS publishes the authoritative timeline and it is the version that counts.

What you actually lose

It helps to separate the things Proton did for you, because they end up in different places after migration.

The template catalogue. Proton held versioned environment and service templates and enforced which versions a team could use. That inventory was deleted with the service. Whatever was in Proton and nowhere else is gone, so the first task is getting what survives into a repository you control.

The self-service layer. Developers requested a service and Proton provisioned it from an approved template without them writing infrastructure code. Nothing in the native AWS toolchain replaces this directly. Most teams replace it with a repository convention and a pull request instead, which is less polished and considerably easier to reason about.

The delivery pipelines. Proton generated and ran the pipeline that took a template and deployed it. This is the piece that leaves the largest hole, and it is the piece most migration plans underestimate.

The record of what produced each deployment. Which template version, and which parameter values, produced each deployed service instance. That is the quiet problem. Your stacks survive, but the thing that knew why they look the way they do does not.

What you keep

Everything Proton deployed. The CloudFormation stacks stay in your account in whatever state they were last left. The resources they describe, the load balancers, the databases, the queues and the roles, keep running and keep billing. Nothing was torn down on 7 October 2026, and missing the date did not cause a production outage on 8 October.

This is genuinely good news, and it is also the source of the problem that shows up three months later. On the day after end of support you have live production infrastructure with no pipeline in front of it and no clear path from a repository to a deployed stack. The stacks are not orphaned in the sense of being broken. They are orphaned in the sense that nothing is responsible for them any more.

Export what you have, first

Do this before anything else. With the service off, the definitions held in Proton are not recoverable, and reconstructing them from deployed stacks is considerably harder than exporting them was. What you can still capture is whatever lives outside Proton, plus anything you saved before the shutdown. It is worth doing even if you have not chosen a destination yet.

Capture and commit to a repository:

1. List every environment and service. If you saved the output of aws proton list-environments, aws proton list-services and aws proton list-service-instances before the shutdown, that is your inventory.
2. Pull every template version. Environment templates, service templates and every major and minor version still in use. The template bundles themselves live in the S3 bucket you registered them from, so check that the bucket still holds every version you care about. A bundle is the IaC files, the manifest, and the schema.
3. The schema files specifically. They define your input parameters, the contract between your platform team and your developers. They are hard to reconstruct and easy to export.
4. Record the spec for every deployed instance. Each service instance had a spec supplying the parameter values that made that instance what it is. Without it you have a template and no idea what was passed into it.
5. Map instances to stacks. For each service instance, note the CloudFormation stack it produced. This mapping is what lets you reattach a new pipeline to an existing stack later, and it is tedious to reconstruct after the fact.
6. The rendered CloudFormation for each deployed stack. Proton’s rendering engine produced real CloudFormation and handed it to the stack. You can retrieve the rendered template from the deployed stack itself, and it is still available after the Proton shutdown because the stack survived. It is the ground truth for what is actually running.
7. Your template sync configuration, if you used one, including which repository and branch each template was syncing from.
8. The pipeline definitions Proton was running, so you know what the replacement has to do.
9. Commit all of it. Templates, specs and the inventory, in a repository, with history. This is the artefact the rest of the migration is built on.

Before the shutdown, both the Proton console and the aws proton CLI could enumerate environments, services, service instances and templates. Whatever you saved from them, and whatever you recover from S3 and the deployed stacks, belongs in version control rather than in a spreadsheet.

If you do nothing else, do this.

The problem nobody warns you about

Here is the thing that turns a one-week migration into a one-month migration.

Proton templates are not CloudFormation templates. They are Jinja-templated CloudFormation. AWS’s template authoring documentation is direct about this: you use Jinja syntax to reference input parameters, and Proton’s rendering engine combines your Jinja-templated IaC files with input parameter values to generate the final IaC file at provisioning time.

That means the files in your template bundles are not valid CloudFormation. You cannot lift them into CloudFormation Git sync, CodePipeline, or GitHub Actions and expect them to deploy. Something has to resolve the Jinja first, and since 7 October the thing that used to do that is gone.

You have two realistic options, and the right one depends on how much variation your templates actually carry.

Convert Jinja parameters into native CloudFormation parameters. Every {{ ... }} reference becomes a Parameters entry, and the values that Proton held per service instance move into whatever your new tool uses for per-deployment configuration. This keeps one template serving many deployments, which is what you had. It is more work up front and it is the right answer if your templates genuinely vary across environments.

Or flatten to rendered output. Take the rendered CloudFormation for each deployed stack and commit that as a plain template per stack. Faster, no Jinja to unpick, and honest about what is actually running. You do trade away the abstraction, and you now maintain many near-identical templates instead of one parameterised one.

Most teams should convert the templates that carry real variation and flatten the ones that were only ever deployed once. Deciding that per template, rather than picking one approach for everything, is usually the difference between a manageable migration and a painful one.

A related point worth noting before you start: Proton separated environments from services, and service templates could consume environment outputs as inputs. If you relied on that, the cross-references need somewhere to live in the new setup: most commonly CloudFormation exports, SSM Parameter Store, or explicit parameter passing. It is easy to miss until something fails to resolve.

The options AWS points you at

AWS directs departing Proton customers at its native toolchain. All of these are reasonable, and which one fits depends mostly on how many stacks you run and how many accounts they live in. They are not equivalent, and they replace different parts of what Proton did.

CloudFormation Git sync

Git sync connects a CloudFormation stack to a branch in a Git repository. Commit a change to the template and CloudFormation deploys it. There is no pipeline to build and no build service to pay for, and the repository becomes the definition of the stack. It is the closest thing to a native successor for the deployment half of Proton, and it is free.

You connect a Git provider through CodeConnections, store your template and a stack deployment file in the repository, and CloudFormation keeps the stack in sync with the branch. The deployment file carries parameters and tags, so it is a genuine parameterised deployment rather than a plain apply.

It is the closest native equivalent to what most teams want, and for a small estate it is the right answer. Two things are worth knowing before committing to it at scale. A Git sync configuration monitors one repository and branch and manages one stack. You create it per stack through the console or the API and activate it by merging a pull request, so the setup cost scales linearly with the number of stacks. For a handful of stacks that is a pleasant afternoon. For two hundred stacks across a dozen accounts it is two hundred configurations to create and maintain by hand.

It also has no teardown path. Removing a template from the repository does not remove the deployed stack. Git sync creates and updates, and deletion stays a manual step. That matters more than it sounds, and we come back to it below.

Use it if: you have a small number of stacks, you want to stay entirely within AWS, and you want to stop paying attention to this problem. For a lot of former Proton users this is genuinely the correct answer, and you should take it.

There is a longer, itemised comparison of Stackmuster and CloudFormation Git sync, including the cases where Git sync is the better choice.

CodePipeline and CodeBuild

Building the pipeline yourself with CodePipeline and CodeBuild gives you complete control, which is exactly the appeal and exactly the cost. You define the stages, the approvals, the cross-account roles and the CloudFormation deploy actions. Teams already invested in the AWS-native toolchain often land here.

Expect the work to be front-loaded and ongoing: a pipeline definition per service, plus the CloudFormation that describes the pipelines themselves, plus the cross-account trust that lets a pipeline in one account deploy into another.

Use it if: your Proton pipelines did real work, such as testing, approvals or multi-stage promotion, and you need to reproduce that rather than just get templates deployed.

GitHub Actions or another external CI system

If your organisation already runs CI somewhere, deploying CloudFormation from it is straightforward. Configure OIDC federation so the runner assumes a role in the target account rather than holding long-lived keys, then call aws cloudformation deploy from a workflow.

This is frequently the fastest route out of Proton, because the CI system, the review process and the permissions model already exist. The trade-off is that the deployment logic ends up as workflow files copied between repositories, and those copies drift.

Use it if: your team already lives in GitHub and the pipeline logic is straightforward. Be deliberate about how you handle AWS credentials, using OIDC rather than long-lived keys, and about how you manage multiple accounts.

Harmonix on AWS

Harmonix, built on Backstage, is the closest thing to a replacement for Proton’s self-service developer portal. If the part of Proton you miss is developers requesting infrastructure without writing it, this is the direction to look. It is the only option that replaces the developer portal half of Proton rather than the deployment half.

It is a substantially larger thing to operate than a pipeline. Running Backstage is a project in itself, and it is worth being honest about whether the self-service layer was delivering enough value to justify that.

Use it if: what you actually valued about Proton was the self-service experience: developers picking a template and getting infrastructure without filing a ticket. None of the other three give you that, and if it is what you are trying to preserve, the other three will disappoint you regardless of how well they deploy.

Choosing between them

None of these options delete a stack when its template is removed from the repository. That’s the gap Stackmuster is being built to close. See where Stackmuster fits (early access from November 2026).

The “Replaces which part of Proton” column is the one most likely to send a migration in the wrong direction. Proton was two products in one: a deployment engine and a self-service catalogue. Work out which half you were actually using before you choose, because the four options split cleanly along that line.

Beyond that, a rough guide based on where the pain actually falls.

• A handful of stacks in one account. Use CloudFormation Git sync. It is native, free, and the per-stack setup cost is irrelevant at that size.
• An existing CI system your team already trusts. Deploy from it with OIDC. The fastest path with the least new surface area.
• Deep AWS-native commitment and appetite for owning the pipeline. CodePipeline and CodeBuild.
• The self-service portal was the point. Look at Harmonix, with clear eyes about the operational cost.
• Many stacks across many repositories and accounts. This is where the per-stack configuration models stop scaling, and where the lifecycle question below starts to matter.

The question that shows up later

Most teams that migrated out of Proton optimised for one thing: having something that deployed before October. That was the correct priority. A compromise that works beats an elegant design that is not finished.

The thing to keep an eye on is what happens over the following year, because whichever option you choose, the same gap tends to open up.

Migrations run under deadline pressure produce partial coverage. Some stacks get a new pipeline. Some get deployed by hand once, to make the deadline, with the intention of wiring them up properly later. Some belong to a service that was being decommissioned anyway, so nobody bothers, and the stack is still there, still costing money, with nothing watching it. If you suspect that has already happened, here is how to find forgotten CloudFormation stacks across every region.

Every option above creates and updates stacks. None of them delete a stack when its template is removed from the repository. So the repository slowly stops being the source of truth it is supposed to be. A service is retired, someone deletes the template, the pull request is approved, and the stack keeps running in the account. The next person to look at it does not know what depends on it, so nobody deletes it. That is how an account accumulates infrastructure nobody will take responsibility for.

The result is a set of production stacks with no delivery pipeline behind them and no record tying them to a repository. Which is roughly where Proton left you on 8 October, except now it is your own doing and there is no deadline to force the cleanup.

Proton’s shutdown is a reasonable moment to notice this, because it is the second time the same thing has happened. A tool was retired, and the stacks it deployed outlived it.

Two things help, neither of which requires buying anything:

• Inventory before you migrate, not after. The list of stacks you exported in step 6 above is the only complete picture you will ever have. Keep it, and check the new setup against it when you are done.
• Decide the teardown story explicitly. Whatever you choose, write down what is supposed to happen when a template is deleted from the repository. If the answer is “nothing, someone deletes the stack manually”, that is a valid answer, but it needs to be a decision, not a discovery.

A migration checklist

• Export every template version, spec and inventory record from Proton into a repository.
• Map each service instance to the CloudFormation stack it produced.
• Decide whether each template gets converted from Jinja or flattened to its rendered output.
• Decide where the deployment logic lives after Proton.
• Stand up the new path for one non-critical service first and prove it end to end.
• Confirm the new pipeline can update an existing stack, not only create a new one.
• Replace Proton’s parameter handling with something explicit, and check the values match what is deployed.
• Work out where environment outputs consumed by service templates will live.
• Sort out cross-account deployment before you need it under pressure.
• Write down what the process is now, while the reasoning is fresh.
• Decide who is responsible for deleting a stack when its template is removed.

That last item is the one that gets skipped. It is also the one that costs money every month it stays unanswered.

Where Stackmuster fits

Stackmuster manages the full lifecycle of CloudFormation stacks from Git. It scans repositories for templates, and each template becomes a deployment: an instance of that template inside Stackmuster, which creates, updates and deletes the corresponding stack. Configuration happens once against a repository rather than once per stack, and it works across multiple repositories and multiple AWS accounts.

The point of difference is the last part of the lifecycle. If a template is removed from the repository, the stack is torn down rather than left running. If it is not in the repository, it should not be running. If it is in the repository, it should be current.

Deploying CloudFormation normally needs credentials that are effectively full administrator, and a pipeline built to replace Proton usually ends up holding them. 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.

Two things to be straight about. Stackmuster is not available yet. Early access opens around November 2026, after Proton’s end of support, so it was never going to help with the October deadline. If you still need a deployment path, use one of the native options above. Git sync is free and it is the right answer for a lot of people.

And it works from the repository. In AWS it never scans anything outside CloudFormation, does not discover stacks it did not deploy, and will not find the infrastructure Proton left behind. It prevents the next round of this problem rather than cleaning up the last one.

If you need somewhere to run pipelines now, Automeer is our managed CI/CD platform and it exists today.

If the problem you expect to have once the migration settles is a set of stacks nobody is accounting for, join the early access list and we will get in touch when it opens.

Frequently asked questions

Is AWS Proton being discontinued?

Yes. AWS Proton stopped accepting new customers on 7 October 2025 and reached end of support on 7 October 2026. At that point the service was switched off and the data held inside it was deleted.

What happens to CloudFormation stacks deployed by AWS Proton?

They keep running. AWS has been clear that the infrastructure Proton deployed is not affected: the stacks stay in your account in whatever state they were last left, and the resources inside them keep running and keep billing. What they lost is the delivery pipeline in front of them, so nothing is responsible for them until you put a new deployment path in place.

Can I still use AWS Proton after 7 October 2026?

No. End of support on 7 October 2026 switched the service off, and Proton’s templates, environment and service definitions and pipeline configuration were deleted with it. The stacks it deployed continue to run, unchanged and unmanaged by Proton.

What replaces AWS Proton?

AWS points departing Proton customers at its native toolchain: CloudFormation Git sync, CodePipeline and CodeBuild, or an external CI system such as GitHub Actions for deployment, and Harmonix on AWS for the self-service developer portal. They replace different halves of Proton, so work out whether you relied on the deployment engine or the self-service catalogue before you choose. For a handful of stacks in one account, Git sync is native, free and usually the right answer.

How do I export my AWS Proton templates?

Proton’s own copy of your templates was deleted at end of support, so recover them from what lives outside it. The template bundles, meaning the IaC files, the manifest and the schema, live in the S3 bucket you registered them from; check it still holds every version you care about. The rendered CloudFormation for each deployed stack can still be retrieved from the stack itself, because the stack survived. Commit both to a repository, along with any inventory and specs you saved before the shutdown.

Sources

• AWS Proton end of support
• Authoring templates and creating bundles for AWS Proton
• How Git sync works with CloudFormation