all posts

The best AWS App Runner alternatives in 2026

Ajay Kumar··9 min read

AWS App Runner exists because ECS asks too many questions. You point it at a container image or a GitHub repo, it builds, it runs, it gives you an HTTPS URL, and you never write a task definition. For a lot of teams that is exactly the right trade, and if it is working for you this post is not for you.

People start looking elsewhere for three reasons, and it is nearly always one of these three. The bill has a floor that does not care whether anyone visited. Something they need is not supported and the roadmap is quiet. Or the service is a small island inside AWS — the surrounding tooling, the logs, the IAM, the VPC connector — turns out to be more work than the ECS they were avoiding.

I build PandaStack, which is one of the options below. So take the section about my own product as a vendor pitch and discount it accordingly; what I will do in exchange is be specific about where the others are the better answer, because for several of these workloads they clearly are.

Work out which of the three problems you have

The alternatives sort cleanly by which complaint you are actually making, and picking on vibes gets you a platform that solves the wrong one.

  • The bill. App Runner charges for provisioned memory continuously and for compute when a request is being handled. A service nobody uses still has a monthly cost. If you run a dozen internal tools, staging copies, or per-customer environments, that floor multiplies and it is usually the thing that pushed you here.
  • A missing capability. Background workers with no HTTP port, WebSockets held open for hours, a persistent volume, a cron that runs inside the same image, a build that needs more RAM than the build environment has. Each of these has sent someone looking.
  • The surrounding AWS. VPC connectors, log groups, IAM roles, and the ALB you eventually add. If you are here because the glue got heavy, moving to another AWS service will not fix it and moving off AWS might.
Before comparing anything, get one number: what your current setup costs per month when it serves zero requests. That figure is the entire argument for scale-to-zero platforms and the entire argument against them, depending on whether it is $12 or $1,200.

The alternatives, honestly

  • Google Cloud Run — the closest like-for-like, and for many teams the straightforward answer. Request-based billing that genuinely reaches zero when idle, a mature CLI, and a container model close enough that a migration is mostly a Dockerfile and a DNS change. The catch is the same one App Runner has: you are inside a hyperscaler, so the surrounding services come with the same weight. Best if the cost floor was your problem and you have no objection to GCP.
  • Fly.io — Machines are fast-starting VMs you control directly, with volumes, private networking, and genuine multi-region placement. It handles the things App Runner does not: long-lived connections, workers without an HTTP port, apps that need a disk. You take on more operational responsibility in return. Best if a missing capability was your problem.
  • Render — the ergonomics people wish App Runner had. Git push deploys, preview environments per pull request, managed Postgres and Redis alongside, and a services model that includes background workers and cron. Not the cheapest at idle for web services, and the free tiers sleep aggressively. Best if you want a whole platform rather than a container runner.
  • Railway — very fast to get productive, good at ephemeral environments, and pleasant to use. Usage-based pricing that suits spiky and hobby-adjacent workloads. Teams that grow into serious compliance requirements sometimes find it thin there. Best for small teams optimising for time-to-first-deploy.
  • Koyeb and Northflank — both serverless-container platforms with global edges and more configurability than App Runner, sitting between Cloud Run's simplicity and Kubernetes' surface area. Northflank in particular is worth a look if you want managed databases and CI in one place without running the cluster.
  • DigitalOcean App Platform — the boring, predictable option. Flat monthly pricing, no surprise egress arithmetic, decent managed Postgres nearby. Fewer knobs than everything above, which is the point. Best if what you want is a small bill that never moves.
  • Kubernetes with Knative — the answer if you already run a cluster and the platform team exists. Do not choose this to escape App Runner; choose it because Kubernetes was already in your life.
  • PandaStack — apps run in Firecracker microVMs, deployed from a Git repo with no Dockerfile: the framework is detected, the runtime version comes from your repo's own .nvmrc or .python-version, and each deploy is blue-green into a fresh microVM. Idle apps sleep and cost nothing while asleep, and a purely static build is served straight from object storage with no VM running at all. The isolation boundary is a hardware-virtualised VM rather than a shared kernel, which matters if you run other people's code. It is a younger platform than everything above and the ecosystem is correspondingly smaller.

Five things to check before you migrate anything

Almost every painful migration I have watched went wrong on one of these, and all five are answerable in an afternoon.

  1. Does your app actually need a VPC? If it talks to RDS or ElastiCache inside a private subnet, moving the compute off AWS means moving or exposing the data too. That is the migration, not the container.
  2. What is the real cold path? Scale-to-zero is only free if the wake-up is acceptable to your users. Measure the first request after an idle period, on the platform, with your image — not the vendor's benchmark with a hello-world.
  3. Where do the logs go, and for how long? App Runner quietly puts them in CloudWatch. Some alternatives keep a few hours in a web UI and expect you to ship the rest somewhere. Decide before, not after an incident.
  4. Does anything depend on the instance living forever? In-memory sessions, a local upload directory, a scheduler goroutine that assumes one replica. Platforms that recycle instances will find these for you at an inconvenient hour.
  5. How do secrets get in? Parameter Store and Secrets Manager integration disappears the moment you leave. Every platform has an answer; check that yours supports rotation without a redeploy.

What a migration actually looks like

For a stateless HTTP service the mechanics are usually a day, and the calendar time goes to DNS and nerves. The pattern that works is to run both, in parallel, with the new one taking a fraction of traffic, until you stop thinking about it.

# 1. Stand the app up on the new platform from the same repo.
#    Most Git-driven platforms detect the framework; you supply what they can't guess.
pandastack app create \
  --name checkout-api \
  --git-url https://github.com/acme/checkout-api \
  --git-branch main \
  --port 8080 \
  --env DATABASE_URL=postgres://...,LOG_LEVEL=info

# 2. Deploy and watch the build, so a failure is visible now rather than at cutover.
pandastack app deploy <app-id> --follow

# 3. Hit the new URL with your real smoke tests before touching DNS.
curl -fsS https://<app-id>.pandastack.app/healthz

# 4. Shift a small slice of traffic at the DNS or CDN layer. Watch error rate
#    and p99 for a full business cycle — a weekday is not enough if you have
#    a weekend batch job.

# 5. Cut over, keep App Runner running and paid for one more week, then delete it.
Do not delete the App Runner service on cutover day. The cost of a week of overlap is trivial next to the cost of discovering, at 2am, that something you forgot was calling it. Delete it when you have gone a full week without thinking about it.

Pick by situation

  • You are staying on AWS and the bill is the issue → look hard at whether Cloud Run's model is worth a second cloud, or accept the floor.
  • You need workers, volumes, or long-lived connections → Fly.io or Render. App Runner is not going to grow these for you.
  • You want the whole platform — app, database, previews, cron → Render, Northflank, or PandaStack.
  • You have many low-traffic services → anything that truly bills nothing at idle, and verify the wake-up latency yourself.
  • You run untrusted or customer-supplied code → the isolation boundary is the decision, and a shared-kernel container is the wrong one. That is a microVM or a dedicated instance.
  • You want predictable and boring → DigitalOcean App Platform, and stop reading comparison posts.

The short version

App Runner is a good product with a narrow remit, and most people leaving it are not leaving because it is bad. They are leaving because their app grew a requirement the service does not have, or because the idle floor stopped making sense across a fleet of small services.

Name which of those it is before you shortlist anything. The platform that fixes an idle bill and the platform that fixes a missing WebSocket are not the same platform, and choosing on general impressions gets you six months into the wrong one.

Frequently asked questions

Is AWS App Runner being deprecated?

There is no deprecation announcement, and it continues to receive updates, but the pace of new capability has been slower than the container platforms it competes with — which is why the question gets asked at all. Treat that as a planning input rather than an alarm: if a feature you need is not there today, do not build a roadmap on the assumption that it arrives. The practical version of this concern is not whether the service disappears, but whether it grows with you. Check when the features you would want next were last shipped, and if the answer is a while ago, factor that into the decision rather than waiting.

Which App Runner alternative is cheapest for a low-traffic app?

For an app that is genuinely idle most of the time, the cheapest options are the ones that bill nothing while nothing is happening — request-billed platforms like Cloud Run, and microVM platforms that sleep an idle app and only charge for the seconds it runs. App Runner's provisioned memory charge continues regardless, so a low-traffic service is close to the worst case for its model. The comparison changes completely once traffic is steady: at constant load, a flat monthly instance from a provider like DigitalOcean is often cheaper than per-request billing, and the scale-to-zero platforms lose their advantage. Work out your duty cycle first — the percentage of time your app is actually serving — because that single number decides which pricing model wins.

Can I move from App Runner without rewriting my app?

For a stateless HTTP service that reads configuration from environment variables and listens on a port, yes — the app itself usually needs no changes at all, and the work is in the surrounding pieces. What does need attention is anything App Runner was quietly providing: the VPC connector to a private database, CloudWatch log destinations, IAM roles used for AWS API calls, and any assumption that the instance persists between requests. Rewrites become necessary when the app stored state on local disk, held in-memory sessions, or ran a scheduler assuming exactly one replica. Audit for those three before you start, and the migration is usually a Dockerfile or a build command plus a DNS change.

Does App Runner scale to zero?

It pauses compute when there are no requests, but you continue to pay for provisioned memory, so the bill does not reach zero the way it does on a request-billed or sleep-on-idle platform. This is the single most common source of surprise on an App Runner invoice: the service looks idle in the console and still generates a line item every month. If you run one production service, the difference is small enough to ignore. If you run twenty — staging copies, internal tools, one environment per customer — that floor multiplied by twenty is usually the whole reason people end up comparing alternatives in the first place.

Is a microVM platform a real alternative to App Runner?

Yes, and the interesting difference is the isolation boundary rather than the deployment experience, which is broadly similar on both. App Runner runs your container on shared infrastructure with a shared kernel; a microVM platform gives each app a hardware-virtualised guest with its own kernel. For your own trusted code that distinction is mostly academic and you should choose on price and features. It stops being academic the moment you run code you did not write — customer-supplied builds, AI-generated code, plugins from a marketplace — because a kernel-level container escape and a hypervisor escape are very different classes of problem. Snapshot-based platforms also tend to have a faster cold path than image-pull-based ones, which matters if you are relying on sleeping idle apps.

Keep reading

Run code in a microVM in one API call.

49ms p50 cold start. Fork, snapshot, and scale to zero.

Start free
Written by Ajay Kumar, Founder, PandaStack.