AWS App Runner is closed to new customers. Here is where to go

AWS App Runner no longer accepts new customers. AWS says so on the product page itself: new sign-ups stopped on 30 April 2026, existing services keep running, and there will be no new features. AWS points leavers at Amazon ECS Express Mode. That is one option and not the only sensible one — the wider field of container-as-a-service platforms has moved on since App Runner launched — App Runner's appeal was that you never touched a load balancer, a VPC, or a task definition, and ECS Express Mode hands two of those three back.

Written 20 August 2026, against the App Runner, Fargate, Cloud Run, Render, and Fly.io price lists published that week.

---

What AWS App Runner did

App Runner ran a container or a Git repository as an HTTPS service without you configuring anything underneath it. Point it at a GitHub repo or an ECR image, pick a vCPU and memory size, and it built, deployed, load-balanced, scaled, and issued a certificate. No VPC, no Application Load Balancer, no ECS task definition, no Kubernetes.

The ceiling was low and the shape was narrow. A service topped out at 4 vCPU and 12 GB of memory. It served HTTP and nothing else — no queue consumers, no schedulers, no long-lived workers. Connecting to an RDS database in your own VPC needed a VPC connector, and build failures were hard to read.

What "maintenance mode" means, exactly

Four things, in AWS's own words on the App Runner page:

AWS published the change on 31 March 2026 in its service availability updates, alongside the WorkMail wind-down. There is no forced migration and no shutdown clock. There is also no reason to build anything new on it.

What AWS App Runner costs

App Runner splits the bill in two: an active instance is billed for both vCPU and memory, a provisioned one — an instance that is up but not handling a request — is billed for memory alone.

Billing is per second, with a one-minute minimum on vCPU each time a provisioned instance starts handling requests.

A service on 1 vCPU and 2 GB, busy around the clock, costs $57.94 a month. That is 730 hours × ($0.064 + 2 × $0.007), plus the $1 automatic-deployment fee. The same service with no traffic at all still costs $10.22 a month in memory, $11.22 once the deployment fee lands — memory on a provisioned instance never stops billing.

What ECS Express Mode changes

Amazon ECS Express Mode launched on 21 November 2025, shortly before re:Invent, and is what AWS now recommends. It creates the ECS service, the Application Load Balancer, and the networking for you from a single command, so the deploy experience is close to App Runner's. The bill is not.

The arithmetic on our 1 vCPU / 2 GB service: $36.04 of Fargate plus about $16 of load balancer is roughly $52 a month, against App Runner's $57.94. You save a few dollars, you gain background jobs and real sizes, and you take on a load balancer, a VPC, and a task definition. If you are running one small service, that trade is bad. If you are running twenty behind one ALB, it is good.

App Runner alternatives, compared

Three notes, because rate cards do not compare themselves.

Two platforms hit zero, not one. Cloud Run scales instances to zero under request-based billing. Fly.io parks the Machine with autostop and then bills only its root filesystem. If your workload is bursty HTTP and nothing else, either is close to what App Runner felt like.

Render's $85 is the wrong row to quote. That tier is 2 vCPU and 4 GB. Against our 1 vCPU / 2 GB example the like-for-like tier is Standard at $25 a month, on a workspace that costs nothing until you need a team.

Cloud Run is no longer HTTP-only. Worker pools reached general availability in April 2026 and run long-lived pull-based processes — queue consumers, Kafka readers, CI runners — at $0.000011244 per vCPU-second, below the Service rate.

How to pick

Bursty HTTP, no background work, and you want the bill to hit zero overnight. Google Cloud Run. Per-request billing, no load balancer to own, and the free tier covers 2 million requests a month.

You are already deep in AWS and need the VPC. ECS Express Mode. You are paying for an ALB either way, and sharing one across up to 25 services is what makes the price work.

You want App Runner's simplicity back, plus the things it never did. A platform that runs a process rather than a request handler. That is where Lizard, Render, and Fly.io sit — compared line by line in the best PaaS providers in 2026. If you were considering a cluster instead, the Kubernetes alternatives are worth reading first.

Moving an App Runner service to Lizard

Lizard runs your container as a long-lived process in a Firecracker micro-VM, with a *.onlizard.com domain and TLS on the first deploy. There is no load balancer to create and no task definition to write.

npm i -g @lizard-build/cli
lizard login
cd your-app && lizard up

lizard up detects the stack and builds it — Go, Node, Python, Rust, Ruby, PHP, Java, or a static site — or uses your Dockerfile as it stands if the repo already has one. The pieces App Runner made you leave behind come from the same CLI:

• lizard add postgres redis s3 provisions a database, a cache, and S3-compatible storage in the same project; lizard secrets set DATABASE_URL='${{postgres.DATABASE_URL}}' --service api wires each connection string in by reference. No VPC connector.
• A worker with no HTTP port deploys exactly like a web service, so queue consumers and schedulers stop being someone else's problem.
• lizard ssh --service <name> -- <cmd> runs a one-off command inside the running VM, and lizard logs streams runtime output while lizard logs --build shows the build — the two things that made App Runner build failures painful.
• lizard git connect installs the GitHub App; lizard add -r owner/repo creates the service from that repo, after which pushes to the tracked branch redeploy automatically.
• Every command takes --json, so an agent can drive the migration and read what happened.

On our 1 vCPU / 2 GB example, measured at a realistic 25% average CPU and 50% average memory, Lizard comes to $15.22 a month against App Runner's $57.94. Lizard bills only for active resources, by the second, on what the VM measurably uses rather than the size you picked. The trade is the honest one: a Lizard service that is up bills every second it is up, so if your traffic is genuinely spiky and you want a zero overnight, Cloud Run and Fly.io's autostop win that row.

---

Your whole stack from one command

Free to start with $5 of credit and no card. Hobby is $5 a month.

Get started free → lizard.build/login

---

FAQ

Is AWS App Runner deprecated? Not deprecated — in maintenance. AWS stopped accepting new App Runner customers on 30 April 2026, and says existing services stay operational and accessible with no new features planned. No shutdown date has been published, but nothing new will be built on the service.

Can I still create a new App Runner service? Only if your AWS account was already an App Runner customer before 30 April 2026. New customers cannot start one. AWS directs them to Amazon ECS Express Mode instead.

What does AWS App Runner cost? $0.064 per vCPU-hour for an active instance and $0.007 per GB-hour of memory in primary regions, billed per second, plus $1 per application a month for automatic deployments and $0.005 per build-minute when building from source. Tokyo is higher, at $0.081 and $0.009. A 1 vCPU / 2 GB service under constant traffic works out at $57.94 a month, and about $10.22 a month with no traffic at all — $11.22 with the deployment fee — because memory on a provisioned instance keeps billing.

Why is App Runner more expensive than Fargate? Because the App Runner rate includes the load balancer, the certificate, the scaling, and the build pipeline. Fargate at $0.04048 per vCPU-hour looks cheaper until you add an Application Load Balancer at roughly $16 a month and the time it takes to wire up a VPC.

What is the best AWS App Runner alternative? It depends on the shape of the workload. Google Cloud Run for bursty HTTP that should cost nothing when idle. Amazon ECS Express Mode if you need the AWS VPC and are running enough services to share one load balancer. Lizard, Render, or Fly.io if you want App Runner's simplicity plus background workers, a shell into the running container, and a database from the same command.

Does App Runner run background jobs or workers? No. App Runner only ever ran HTTP services. Queue consumers, schedulers, and anything without a port had to live somewhere else — usually ECS, Lambda, or EventBridge. Lizard deploys a worker the same way it deploys a web service, and Cloud Run worker pools have done the same since April 2026.

How do I migrate from App Runner to Lizard? Install the CLI with npm i -g @lizard-build/cli, run lizard login, then lizard up in your project. An existing Dockerfile is used as it stands; without one, lizardpack writes a real multi-stage Dockerfile on the build node. Add lizard add postgres redis s3 for the managed pieces, move your environment variables with lizard secrets set, and attach a domain with lizard domain <host> --service <name>.

Is ECS Express Mode the same as App Runner? Close in feel, different underneath. Express Mode creates the ECS service, the Application Load Balancer, and the networking for you, so a deploy is one command. You still own an ALB, a VPC, and a task definition afterwards, and the compute is billed at Fargate rates rather than App Runner's all-in rate.

---

Sources

• AWS App Runner product page — the maintenance notice and the 30 April 2026 date
• AWS App Runner pricing
• AWS Fargate pricing
• Google Cloud Run pricing
• Render pricing, Fly.io pricing
• Cloud Run worker pools
• Lizard pricing and Lizard documentation