AWS Closed App Runner to New Customers on April 30 — and Proved the PaaS Layer Is the First Thing Even a Hyperscaler Cuts

On April 30, 2026, AWS stopped accepting new customers for App Runner, the service that let you point at a GitHub repo and get a running, load-balanced, HTTPS-terminated container back with no VPC, no ECS cluster, and no task definition to write. The announcement itself is five sentences long: "After careful consideration, we decided to close AWS App Runner to new customers. Existing AWS App Runner customers can continue to use the service as normal, including creating new resources and services. AWS continues to invest in security and availability for AWS App Runner, but we do not plan to introduce new features."

Nobody's app went down. Nobody got a shutdown deadline. If you were already running on App Runner on April 29, nothing changed for you on April 30 — you can still deploy, still scale, still spin up new services under your existing account. What changed is that App Runner will never get another customer, another feature, or another reason for AWS to keep investing engineering time in it beyond keeping the lights on.

That's a smaller event than a shutdown, and a much bigger signal: the company that owns the compute, the load balancer, the certificate manager, and the build pipeline underneath App Runner still decided the thin layer gluing them together wasn't worth maintaining as its own product. If AWS won't carry that layer forward on infrastructure it fully owns, no vendor's git-push convenience layer is safe from the same math — and that argument doesn't depend on whose pricing page looks cheaper this quarter.

What Actually Happened, and When​

The timeline is short and, unusually for a deprecation, not vague:

• May 2021 — AWS launches App Runner: point it at a container image or a source repository, and it builds, deploys, load-balances, health-checks, and auto-scales the result behind an HTTPS endpoint.
• March 31, 2026 — AWS quietly publishes an "App Runner availability change" page in its documentation, the first public signal that new signups were ending.
• April 30, 2026 — App Runner formally closes to new customers. This is the operative date: AWS's own docs use it as the line between "can still sign up" and "can't."
• No date after that — There is no announced end-of-life, no forced migration deadline, and no stated timeline for when maintenance mode might become something more final. AWS's language is deliberately open-ended: "we do not plan to introduce new features," not "we will shut this down on X."

That last point matters for calibrating the rest of this post. This is not a Railway-style outage, not a Fly.io feature deprecation with a hard cutoff date, and not a "your data will be deleted" notice. Existing App Runner customers can keep building on it indefinitely, in the same sense that you could keep building on a product with no roadmap indefinitely. The honest description is: App Runner is now permanently frozen at its April 2026 feature set, with a security-patch-only commitment and a closed door for anyone who isn't already inside.

What App Runner Actually Was​

App Runner never shipped new infrastructure. It shipped orchestration on top of infrastructure AWS already sold you separately:

• AWS Fargate for the actual compute — serverless containers, no EC2 instances to manage.
• An Application Load Balancer for HTTPS termination, health checks, and traffic routing.
• A source-to-container build step (AWS's own buildpack-style pipeline) so you could deploy straight from a GitHub repo without writing a Dockerfile.
• AWS Certificate Manager for the TLS certificates behind custom domains.
• CloudWatch for logs and metrics, wired up automatically.

Every one of those pieces still exists today, unaffected, generating revenue for AWS exactly as before. What App Runner sold was the glue: one API call and a monthly fee in exchange for not having to wire those five services together yourself, and not having to own the roadmap decisions about how they should evolve together. That glue is precisely what AWS decided to stop investing in — not the compute, not the load balancer, not the certificates. The DX layer.

The Economics: Why "AWS Already Owns Everything" Makes This Worse, Not Better​

Here's the argument that makes App Runner's closure different from a typical vendor-risk story, and why it cuts deeper than a monthly-bill comparison.

The usual case for self-hosting instead of a hosted PaaS is a cost spreadsheet: a managed web service plus worker plus Postgres costs $X/month on Render or Railway, versus$Y/month for an owned box, and self-hosting wins once your traffic clears some threshold. That's a real, useful comparison — and it's also not what happened here. App Runner's pricing was never the problem. AWS didn't shut down a product that was bleeding money on infrastructure costs; the underlying Fargate tasks, ALB hours, and data transfer were priced and billed exactly the same whether you reached them through App Runner or configured them by hand. AWS keeps every dollar of that revenue regardless of which front door you walked through.

What a monthly TCO spreadsheet can't price in is this: the DX layer sitting between you and the infrastructure has its own separate survival calculation, one that has nothing to do with whether the compute underneath is profitable. Coverage of the closure converged on the same read — App Runner was "always a thin wrapper around ECS Fargate," and rather than maintain two products that solved the same problem at different levels of abstraction, AWS chose to consolidate engineering effort into one (ECS Express Mode, covered next) and stop investing in the other. That's a roadmap-ownership decision, made independently of whether App Runner customers were happy, growing, or paying on time.

A pricing comparison can tell you what a platform costs this month. It cannot tell you whether the vendor still wants to own the product a year from now — and April 30 is proof that even the vendor with the deepest pockets and the least reason to economize on maintenance will still make that call unilaterally, on a timeline you don't get a vote in.

The Migration Path Has a Hole in It — Even Inside AWS's Own Portfolio​

AWS's recommended replacement is Amazon ECS Express Mode, a genuinely capable feature that launched at re:Invent in November 2025. Feed it a container image and two IAM roles, and it provisions a full stack in one API call: an ECS service on Fargate, an Application Load Balancer with HTTPS, auto-scaling, CloudWatch monitoring, and security groups — at no additional charge beyond the underlying resources. Up to 25 Express Mode services can share a single ALB. On paper, it's App Runner's simplicity with the rest of ECS available if you outgrow the defaults.

But read AWS's own migration guide, and the gap shows up in the first "before you begin" bullet: "Container image requirement — ECS Express Mode deploys a container image. If your App Runner service is deployed from source code, first add a build step that creates a container image and pushes it to a registry such as Amazon Elastic Container Registry."

App Runner's headline feature — point it at a repo, get a deploy on every push, no Dockerfile required — has no equivalent in its own recommended successor. If you were one of the customers who used App Runner's source-based deploys specifically because you didn't want to own a build pipeline, migrating means building one now: a Dockerfile, a GitHub Actions workflow, an ECR repository, an OIDC trust relationship for the CI role, and two new IAM roles for Express Mode itself.

If you want deploy-on-push back, that also means wiring AWS's own amazon-ecs-deploy-express-service GitHub Action into that workflow yourself. None of this is exotic engineering. All of it is work that App Runner used to do for you and that its replacement, from the same company, does not.

That gap is the concrete version of the abstract argument above: "AWS will migrate you smoothly" turns out to mean "AWS wrote a very good guide for the migration you now have to do yourself." The vendor that owns literally every layer of the stack still couldn't — or didn't choose to — make the successor product a drop-in replacement.

This Is Heroku's Shape, Not an AWS One-Off​

The reason App Runner's closure is worth writing about instead of filing as AWS trivia is that it's not a novel pattern — it's the same one Salesforce ran on Heroku two months earlier, at a completely different scale and with a completely different ownership structure:

Two vendors on opposite ends of the spectrum — one a 20-year-old acquired platform, one a hyperscaler's newest convenience product — landed on the identical shape of decision within ten weeks of each other: keep existing customers whole, stop selling to new ones, stop building new things, don't announce when it ends. That convergence is the actual finding here. It means the git-push convenience layer isn't safe because the vendor is small, isn't safe because the vendor is large, isn't safe because the vendor is unprofitable, and isn't safe because the vendor is thriving. It's a separate product decision from all of those variables, made whenever a company decides the DX layer no longer earns its keep relative to something else on the roadmap — and the decision gets made by someone who was never obligated to ask you first.

Owning the Layer AWS Just Proved Isn't Guaranteed​

The practical takeaway isn't "avoid managed compute" — Fargate, ALB, and ECS Express Mode are all still there, still supported, and still reasonable choices. It's narrower than that: the git-push-to-HTTPS layer itself, the thing that decides how your deploys work and whether new features ever ship for it, is a product with its own lifecycle, separate from the infrastructure it sits on. That layer can be closed to new customers by a company that owns every dependency underneath it and loses no infrastructure revenue by doing so.

Bex.co exists for the same reason App Runner did — push a git repo, get a running HTTPS service, no Dockerfile or Kubernetes manifest required — except the layer runs as a Cluster API controller on machines you own, exposing a Render-compatible API instead of a proprietary one. Nobody can close it to new customers, because there's no "new customer" gate between you and your own infrastructure: the control plane you're running today is the same one you'll be running in five years, on hardware nobody else can decide to stop investing in on your behalf.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.