Parag Agrawal

Posted on Apr 13 • Originally published at turbodeploy.dev

AWS App Runner Is Dead — Here's What You Should Use Instead (2026)

#serverless #cloudcomputing #aws #cloud

If you're running apps on AWS App Runner — or were thinking about using it — you need to read this.

AWS has announced that App Runner will no longer accept new customers starting April 30, 2026.

This isn't speculation. It's in the official AWS documentation. Existing customers can still use the service and create new resources, but AWS has confirmed they won't be introducing new features. The service is entering maintenance mode — which, in AWS language, is one step before eventual deprecation.

If you're currently on App Runner, you need a migration plan. If you were evaluating it for a new project, you need a new direction.

This post covers everything: what happened, why AWS made this call, and exactly what you should use instead — with specific migration steps.

What Was AWS App Runner?

For those unfamiliar, App Runner was AWS's answer to Heroku/Render/Railway. Launched in 2021, it was designed to be the simplest way to deploy containerized web applications on AWS.

The pitch was compelling:

✅ Point to a container image or source code repository
✅ App Runner handles build, deploy, HTTPS, scaling, and load balancing
✅ No need to configure VPCs, ECS clusters, task definitions, or ALBs
✅ Runs on Fargate under the hood
✅ Auto-scales to zero (you only pay when your app gets traffic)

It was genuinely good for simple use cases. If you wanted to deploy a single API or web app without learning ECS, App Runner got you there in under 5 minutes.

So why is AWS killing it?

Why AWS Is Sunsetting App Runner

AWS hasn't published an official "here's why" blog post, but the reasoning becomes clear when you look at the timeline:

The Real Reason: ECS Express Mode

In late 2025 / early 2026, AWS launched ECS Express Mode — a new feature within Amazon ECS that provides almost everything App Runner offered, but within the ECS ecosystem.

ECS Express Mode automates:

Cluster creation on Fargate
Application Load Balancer provisioning
HTTPS/TLS configuration
Security groups and networking
Auto-scaling policies
CloudWatch monitoring and logging

In other words, ECS Express Mode makes ECS nearly as simple as App Runner — but with full access to the ECS feature set. It's App Runner's simplicity, with ECS's power.

Having two services that do essentially the same thing creates confusion and maintenance overhead for AWS. App Runner was always a thin wrapper around ECS Fargate anyway. Rather than maintaining two products, AWS chose to consolidate into one — and ECS Express Mode is the survivor.

What This Means for the Broader Market

This is actually a positive signal for the industry. It means:

AWS is investing heavily in making ECS simpler — which validates the core thesis that container deployment needs to be easier
The "App Runner" approach of simplicity-first is the right direction — AWS just decided to build it into ECS rather than maintain a separate service
ECS Fargate is the long-term bet — if you're building on ECS Fargate today, you're on the right side of AWS's strategy

This is also exactly the thesis behind TurboDeploy. More on that later.

The Timeline: What's Happening When

Here's what you need to know:

Date	What Happens
Now (April 2026)	App Runner is fully functional for existing customers
April 30, 2026	App Runner stops accepting new customers. If you haven't created an App Runner service before this date, you won't be able to.
Post April 30	Existing customers can continue using App Runner, create new services, and manage workloads. AWS will maintain security and availability.
Future (date TBD)	No new features will be added. Eventually, AWS will likely announce a full sunset date.

The writing is on the wall. Even if you're an existing customer, starting a migration now — while there's no time pressure — is the smart move.

What Should You Use Instead?

You have three main options, depending on your needs. Let's break down each one.

Option 1: Amazon ECS Express Mode (AWS's Official Recommendation)

This is the most direct replacement. AWS explicitly recommends ECS Express Mode for App Runner users.

What you get:

Nearly identical simplicity to App Runner
Provide a container image → get a running service with ALB, HTTPS, auto-scaling
Full access to underlying ECS resources (you can customize later)
No additional cost beyond standard Fargate + ALB pricing
Shares ALBs across up to 25 services to reduce costs

How to get started with ECS Express Mode:

Go to the Amazon ECS console
In the left nav, select Express mode
Click Create
Enter your container image URI (from ECR or any public registry)
(Optional) Configure CPU, memory, environment variables
Click Create — done

That's it. ECS Express Mode provisions the cluster, service, ALB, security groups, auto-scaling, and CloudWatch monitoring automatically.

Key difference from App Runner: Express Mode requires a pre-built container image. App Runner could build from source code. So you'll need a CI/CD step (like GitHub Actions) to build and push your Docker image to ECR before Express Mode can deploy it.

→ We'll cover this end-to-end in our upcoming post: How to Set Up a CI/CD Pipeline with GitHub Actions and AWS ECS

Who this is best for: Developers who are comfortable with Docker and want to stay 100% within the AWS ecosystem with minimal setup.

Option 2: Amazon ECS Fargate (Standard Mode)

If you need more control than Express Mode provides — or you want to understand what's happening under the hood — standard ECS Fargate gives you full power.

What you get:

Complete control over networking, IAM roles, task definitions, and deployment strategies
Blue-green and rolling deployments
Custom health check configurations
Integration with any CI/CD system
Multi-container task definitions (sidecars, logging agents, etc.)

The trade-off: You're back to configuring VPCs, ALBs, target groups, security groups, and IAM roles manually. This is significantly more complex than Express Mode.

→ We'll publish a full step-by-step guide: How to Deploy a Docker Container on AWS ECS Fargate

Who this is best for: Teams with DevOps experience who need fine-grained control over their infrastructure.

Option 3: A Deployment Platform That Handles the Complexity for You

Both ECS Express Mode and standard Fargate still require you to:

Build and push Docker images yourself (or set up CI/CD)
Manage your own ECR repositories
Configure environment variables through AWS interfaces
Deal with AWS IAM role setup
Monitor deployments through the AWS console

If you want the App Runner experience — "point to my code and deploy" — but don't want to lose the benefits of running in your own AWS account, this is where tools like TurboDeploy come in.

TurboDeploy sits in the gap between "PaaS simplicity" and "AWS control":

You connect your AWS account via a secure IAM role
You point to your GitHub repo
TurboDeploy handles the Docker build, ECR push, ECS service creation, ALB setup, and monitoring
Everything runs in your AWS account — you're not moving to someone else's cloud

This is essentially what App Runner was supposed to be, but with the added benefit that TurboDeploy doesn't need to be an AWS service to keep working. If TurboDeploy disappears tomorrow, your ECS services keep running in your account, unchanged.

Who this is best for: Developers and startup founders who want the App Runner "just deploy it" experience without vendor dependency.

→ Learn more: Why We're Building TurboDeploy — The Problem with Cloud Deployment in 2026

Comparison Table: Your Migration Options at a Glance

Feature	App Runner (dying)	ECS Express Mode	ECS Fargate (Standard)	TurboDeploy
Setup complexity	Very Low	Low	High	Very Low
Build from source code	✅ Yes	❌ Need CI/CD	❌ Need CI/CD	✅ Yes
HTTPS/TLS	✅ Automatic	✅ Automatic	⚙️ Manual (ACM + ALB)	✅ Automatic
Auto-scaling	✅ Built-in	✅ Built-in	⚙️ Manual config	✅ Built-in
Custom domains	✅	✅ (via Route53)	⚙️ Manual	🔜 Roadmap
Full AWS resource access	❌ Limited	✅ Full	✅ Full	✅ Full
Scale-to-zero	✅	❌	❌	❌
Long-term viability	❌ Sunsetting	✅ AWS investment	✅ Stable	✅ Active development
Runs in your account	✅	✅	✅	✅
Additional cost	App Runner pricing	Fargate + ALB only	Fargate + ALB only	Fargate + ALB + TurboDeploy

Step-by-Step: Migrating from App Runner to ECS Express Mode

If you have an existing App Runner service and want to migrate to ECS Express Mode, here's the recommended approach:

Step 1: Inventory Your App Runner Services

List all your App Runner services and document:

Container image source (ECR or source code)
Environment variables
CPU and memory configuration
Custom domain mappings
Auto-scaling configuration

aws apprunner list-services --region us-east-1

Step 2: Ensure Your Container Image is in ECR

If your App Runner service builds from source code, you'll need to set up a container build pipeline first. The simplest approach:

Add a Dockerfile to your repository (if you don't have one)
Create an ECR repository in your AWS account
Set up GitHub Actions to build and push on every commit

# Create an ECR repository
aws ecr create-repository --repository-name my-app --region us-east-1

→ Don't have a Dockerfile? Check out: How to Write a Production-Ready Dockerfile

Step 3: Create an ECS Express Mode Service

Open the ECS Console → Express mode → Create
Enter your ECR image URI
Configure CPU, memory, and environment variables to match your App Runner settings
Click Create

Your new service will be live in minutes with an AWS-managed URL.

Step 4: Set Up DNS Migration (Blue-Green)

AWS recommends a blue-green approach for zero-downtime migration:

Create a Route 53 weighted routing record set
Point 10% of traffic to the new ECS Express service
Monitor for errors, latency, and functionality
Gradually increase to 25% → 50% → 100%
Decommission the App Runner service once all traffic is migrated

# Example Route 53 weighted record
my-app.example.com → App Runner URL (weight: 90)
my-app.example.com → ECS ALB URL    (weight: 10)

Step 5: Tear Down App Runner

Once all traffic is on ECS and you're confident everything works:

aws apprunner delete-service --service-arn arn:aws:apprunner:us-east-1:123456789:service/my-app/xxx

What About Non-AWS Alternatives?

If the App Runner sunset makes you question your AWS commitment entirely, here are your options outside the AWS ecosystem:

Platform	Best For	Trade-off
Railway	Quick deployments, modern DX	Usage-based pricing, you don't own infra
Render	Predictable pricing, easy setup	Less flexibility than AWS
Fly.io	Global edge deployment	More complex networking model
Coolify (self-hosted)	Full control on your own VPS	You manage the PaaS layer + the server

These are all solid options, but they come with the platform tax trade-off: you're paying for convenience with someone else's infrastructure.

The Bigger Picture: What This Tells Us About Cloud Computing in 2026

The App Runner sunset isn't just a product lifecycle event. It's a signal about where cloud deployment is heading:

1. Simplicity is becoming a feature of existing services, not separate products

Instead of creating new "simple" services, cloud providers are making their core services simpler. ECS Express Mode is ECS-made-easy, not a separate product. Expect the same pattern from other AWS services.

2. Containers on Fargate is the "default" deployment model

AWS is clearly betting on ECS Fargate as the standard way to deploy containerized applications. Not Lambda (too limited for many workloads), not EKS (too complex for most teams), but ECS on Fargate.

→ We explore this further in: ECS vs EKS vs Lambda — How to Choose the Right AWS Compute Service

3. The developer experience gap is still the real problem

Even with ECS Express Mode, deploying to AWS is still harder than Vercel or Railway. The gap is smaller than it was in 2021, but it's still there. And that gap is exactly the space where tools like TurboDeploy add value.

TL;DR — What To Do Right Now

If you're currently on App Runner:

✅ Don't panic — your services keep running
✅ Start planning migration to ECS Express Mode
✅ Set up a Docker build pipeline if you don't have one
✅ Test ECS Express Mode with a non-critical service first
✅ Migrate production services using blue-green (Route 53 weighted routing)

If you were considering App Runner for a new project:

✅ Use ECS Express Mode for the closest experience
✅ Or try TurboDeploy for an even simpler experience that deploys to your AWS account
❌ Don't start with App Runner — the service is entering end-of-life

If you're unsure which option is right:

Read our decision guide → How to Choose Between a PaaS and AWS for Your Startup

👉 Join the TurboDeploy waitlist → — Deploy to AWS without the AWS headache.

DEV Community