AWS Proton shuts down October 7: what to do now

AWS Proton is a managed deployment service from Amazon Web Services, and it shuts down on October 7, 2026. After that date you cannot open the console or reach any Proton resource, and AWS says all Proton data is deleted. The infrastructure you already deployed keeps running. What disappears is the layer that updates it: templates, environments, service definitions and deploy pipelines. If you still manage services through Proton, export those templates now and pick a replacement this week. The plan at a glance: export, choose, then cut over one service at a time.

What happens when AWS Proton shuts down

Proton lets platform groups publish approved templates and lets developers deploy from them. According to AWS's end-of-support guide, the shutdown date is October 7, 2026. New customers could not sign up after October 7, 2025.

Here is what changes on that date, based on the same guide:

Item	After October 7, 2026
Proton console and API	No longer accessible
Templates, environments, service definitions	Deleted with all Proton data
Deployed CloudFormation stacks	Keep running
Resources those stacks created (VPCs, ECS services, databases)	Keep running
Updating them through Proton	Gone

The risk is not an outage. The risk is simple. The next change you need, such as a security patch, has no pipeline to ship it.

Why AWS is discontinuing Proton

AWS says in its Proton FAQ that other AWS and AWS Partner tools meet infrastructure-as-code policy needs better. AWS has not named a single successor service. Its migration guide lists four options instead, and each one drops something Proton did.

Step 1: Export Proton templates before the data is deleted

Export first and decide second. AWS lists five migration steps. Inventory your Proton resources. Select an option. Extract your template data. Build the new setup. Then move production workloads.

Start with the inventory. These AWS CLI calls list what you own:

aws proton list-environment-templates
aws proton list-service-templates
aws proton list-environments
aws proton list-services

For each template, download the schema, the infrastructure files and the pipeline definitions into a Git repository. Record which template version every service uses. Proton tracks versions, as the Spacelift explainer on Proton notes. A new tool will not know them unless you write them down.

This is the one step you cannot redo. AWS states that data is retained only until October 7, 2026, so a missing template has to be rebuilt from memory.

Step 2: Compare the four AWS Proton options

AWS names four options in its guide. The right one depends on how much self-serve your developers need.

Option	Best for	What you give up
CloudFormation Git sync	Groups already on CloudFormation who want GitOps	No environments, no advanced pipeline features, relies on GitHub features
Harmonix on AWS	Enterprises that want an internal developer portal	Not maintained by an AWS service team, may need customization
AWS CodePipeline and CodeBuild	Groups that want maximum control	More implementation work, less out-of-box self-serve
GitHub Actions	Smaller groups already on GitHub	Tied to GitHub, more work to enforce platform controls

CloudFormation Git sync is a feature that updates a stack when you push to a Git repository. The CloudFormation Git sync documentation explains the setup. Harmonix on AWS is an AWS Partner reference implementation built on Backstage, which is an open-source developer portal framework. The other two options use AWS CodePipeline with AWS CodeBuild, or GitHub Actions.

Spacelift is a commercial infrastructure automation vendor. Its Proton explainer lists Spacelift itself as the main option, plus Argo CD for Kubernetes workloads. Spacelift sells a competing product, so weigh that comparison accordingly.

Which Proton option should you choose?

Choose by headcount and by the Proton feature you used most. AWS recommends Git sync for a simple GitOps flow and Harmonix for a portal. It suggests CodePipeline for control and GitHub Actions for GitHub-based groups.

1. You mostly used Proton to give developers a parameter file and a push-to-deploy flow. Use CloudFormation Git sync. AWS says it offers a similar developer experience to Proton.
2. You used Proton environments to separate dev, staging and production. Plan extra work. AWS lists "no concept of environments" as a Git sync limitation, so model each environment as a separate stack or repository.
3. You run a platform group with dozens of services. Evaluate Harmonix. Or pair CodePipeline with a portal you already run.
4. You are a small group that lives in GitHub. Use GitHub Actions and keep CloudFormation templates in the same repository.

If none of these fits, delay the tool choice and not the export. The export protects you in every case.

Step 3: Cut over one service at a time

Do not migrate everything at once. Move one low-risk service first and confirm the new pipeline can update an existing stack without recreating it. AWS says only the delivery pipelines are affected by the shutdown, so the stacks are yours to adopt.

For example, consider a staging API service with one stack and one pipeline. A safe order looks like this:

1. Pick a non-production service.
2. Recreate its template in the new repository.
3. Reference the existing CloudFormation stack, so the new pipeline manages it instead of creating a duplicate.
4. Run a no-op change and confirm the stack reports zero resource replacements.
5. Repeat for production services in a quiet window.

The key check is step 4. A pipeline that proposes to replace a database or a load balancer has not adopted the stack correctly. Stop and fix the template before you apply anything.

What if you read this after October 7?

Your running infrastructure is still fine after the deadline. The stacks Proton created exist in CloudFormation, and you can manage them there directly, as AWS confirms for deployed resources.

Open CloudFormation in the AWS console and find the stacks that carry the Proton service names. Download each current template. These templates are generated, so they read worse than your source templates, but they describe what is actually running. Then choose an option from the table above and adopt the stacks. You lose the original template history. You keep control of the resources.

Other infrastructure deadlines this month

October is crowded with end-of-life dates. Kubernetes 1.34 reaches end of life on October 27, and GitHub's ubuntu-latest moves to Ubuntu 26.04 on October 19. If you are already auditing deadlines, put Proton at the top, because it is the one with a hard data-deletion date.

What a Proton migration costs

The options are mostly free to start. CloudFormation Git sync, CodePipeline, CodeBuild and GitHub Actions bill on usage or fall within free allowances. AWS has not published a price for a Proton substitute. The real cost is work hours, so budget a few days per service for rewriting and testing templates. Allow more if you depended on Proton environments. This is a planning estimate, not an AWS figure.