Cloud Run vs App Runner vs Azure Container Apps: 7 serverless container platforms ranked by when they force a Kubernetes migration (2026)

Key Points:

• Ranked by how soon they force a Kubernetes migration: AWS App Runner first (HTTP request-driven containers only, no native jobs or cron, no sidecars, a fixed list of vCPU/memory pairs, and closed to new customers since April 30, 2026), Google Cloud Run second (Jobs, sidecars, GPUs and a 60-minute request timeout cover much more), Azure Container Apps last (it already runs on Kubernetes with KEDA, Dapr and Envoy).
• The trigger is almost never raw compute. It is the first workload the abstraction cannot express: a background worker, a stateful service, a CRD or operator, GPU scheduling, a static egress IP, a specific CNI or network policy, or a compliance boundary that requires workloads in your own account.
• Exit cost differs as much as the ceiling. Cloud Run's Admin API v1 is Knative-compatible, so services, revisions and traffic splits map onto GKE cleanly. App Runner and Azure Container Apps config is proprietary and gets rewritten on the way out.
• Per-second billing stops being cheaper once a service is always on. One always-on 1 vCPU / 2 GiB service costs about $58/month on Cloud Run instance-based billing and $36/month on ECS Fargate in us-east-1, and five of them on Cloud Run cost more than a three-node EKS pool including the control plane fee.
• If your 18-month roadmap crosses the ceiling, run Kubernetes from day one and delegate the operations. Qovery deploys and operates applications inside your own AWS, GCP, Azure or Scaleway account, or on a cluster you already run, with git-push deploys, preview environments per pull request and managed cluster upgrades.

Which serverless container platform forces a Kubernetes migration soonest?

AWS App Runner forces a migration soonest, Google Cloud Run second, and Azure Container Apps last. The wider shortlist, in order, is AWS ECS Fargate, Fly.io, Render, and managed Kubernetes with an internal developer platform on top, which removes the migration event entirely.

App Runner runs HTTP request-driven containers with no native jobs, cron or sidecars. Cloud Run adds Jobs, multi-container sidecars and GPUs. Azure Container Apps is a Kubernetes environment that already exposes KEDA, Dapr and Envoy.

App Runner is the fastest way to get a container online on AWS and the fastest way to outgrow it. AWS now agrees: App Runner is "no longer open to new customers" and AWS "do[es] not plan to introduce new features" (AWS App Runner availability change).

In this article, "forces a migration" means your roadmap needs one of these and the platform cannot express it:

• Background workers, queue consumers, or cron jobs
• Stateful services (databases, brokers, anything that needs a StatefulSet and a persistent volume)
• Custom CRDs and operators
• A service mesh or service-to-service mTLS you control
• GPU scheduling
• Per-pod network policy or a specific CNI
• A static egress IP for partner allowlists
• A compliance boundary that requires workloads in your own cloud account

I have interviewed more than 200 CTOs, and the pattern is consistent. Teams rarely leave a serverless container platform for performance. They leave because one workload does not fit, and running two orchestration systems side by side is worse than consolidating on one.

One scoping note: serverless containers run your container image. Function-as-a-service products (AWS Lambda, Google Cloud Functions, Azure Functions) run your code inside the vendor's runtime and are out of scope here.

How do you know if your roadmap will cross the ceiling in the next 18 months?

Six criteria decide how long you can stay on a serverless container platform: workload coverage, Kubernetes proximity, networking and isolation, account boundary, the always-on cost crossover, and exit cost. Score your next four quarters of roadmap against each one before you pick.

1. Workload coverage. HTTP services only, or also background jobs, cron, queue consumers, stateful services and GPUs?
2. Kubernetes proximity. Does the platform already expose Kubernetes primitives (sidecars, init containers, KEDA scalers, liveness and readiness probes) so your skills and mental models transfer?
3. Networking and isolation. VPC integration, private ingress, service-to-service mTLS, static egress IPs, per-service network policy.
4. Account and compliance boundary. Do workloads run in your account, under your data residency, your BAA and your committed-spend discounts, or in the vendor's account?
5. Pricing model and crossover point. Per-second vCPU and GiB billing versus a right-sized node pool plus the managed control plane fee, for a service that is effectively always on.
6. Exit cost. How much of your build pipeline, config and runtime assumptions survive a move to Kubernetes. Knative-derived concepts transfer. Proprietary wrappers do not.

This is a ranking by migration ceiling, not by developer experience. Cloud Run wins most DX comparisons I have seen, and it still has a ceiling.

What is the side-by-side comparison of the 7 serverless container platforms in 2026?

The table ranks seven options from the one that forces Kubernetes soonest (AWS App Runner, rank 1) to the one that removes the migration because you are already on Kubernetes (Qovery on your own cluster or cloud account, rank 7).

What does compute cost on each platform in 2026?

Pricing below is as of October 2026, in us-east-1 (AWS), us-central1 (GCP) and East US (Azure).

Worked crossover: one always-on 1 vCPU / 2 GiB service costs ~$57.82/month on Cloud Run instance-based billing. Five of them cost ~$289/month. Three t3.medium nodes (6 vCPU / 12 GiB) on EKS cost ~$91/month plus the $73 control plane, ~$164 in total, before system overhead and before any Savings Plan (AWS EC2 on-demand pricing). The control plane fee dominates at one service and disappears into the noise at five.

Two numbers make the always-on argument stronger:

• AWS Compute Savings Plans cut compute costs "up to 66%" and EC2 Instance Savings Plans "up to 72%" (AWS Savings Plans). Google's resource-based committed use discounts go up to 55% for general-purpose machine series (Google Cloud CUDs).
• Node pools only win if you right-size them. Datadog found that "83 percent of container costs are associated with idle resources" (Datadog State of Cloud Costs 2024), and the State of FinOps 2026 ranks workload optimization and waste reduction as the top priority for FinOps teams (FinOps Foundation).

Why does AWS App Runner force a Kubernetes migration soonest?

AWS App Runner runs HTTP request-driven containers with no native job or cron workload type, no multi-container sidecars, and a fixed set of vCPU and memory combinations. The first queue consumer, scheduled task or stateful component sends you to ECS Fargate or EKS, and since April 30, 2026 new AWS customers cannot sign up for it at all.

Verdict: fine for an existing App Runner customer with one stateless web API. Wrong for anyone starting fresh, and wrong for teams with queue consumers, scheduled work or anything stateful.

The hard limits, from AWS's own docs:

• Fixed sizes: 0.25 vCPU (0.5 or 1 GB), 0.5 vCPU (1 GB), 1 vCPU (2, 3 or 4 GB), 2 vCPU (4 or 6 GB), 4 vCPU (8, 10 or 12 GB) (App Runner architecture).
• Concurrency: default 100 requests per instance, maximum 200 (App Runner API).
• Services: 30 per region by default, adjustable (App Runner quotas).
• VPC connector: once attached, "all outbound traffic from your application is directed through the VPC," and your service loses public internet and AWS API access unless you add a NAT gateway or VPC endpoints (App Runner VPC networking).
• Pause and resume: pausing drops compute to zero, and "your application loses its state" (App Runner pause).

The pricing never reaches zero while the service runs. App Runner bills $0.007 per GB-hour of provisioned memory even when idle, plus $0.064 per vCPU-hour and $0.007 per GB-hour while serving requests (App Runner pricing). A 1 vCPU / 2 GB service that sits idle still costs ~$10.22/month. Builds cost $0.005 per minute (AWS price list). Cloud Run on request-based billing charges nothing for idle instances that are not minimum instances.

AWS's roadmap had been pushing teams out for a while, and in 2026 it made that official. App Runner went GA on May 18, 2021 (AWS What's New), never shipped a job or multi-container workload type, and is now closed to new customers with no new features planned. AWS recommends Amazon ECS Express Mode as the replacement and publishes a migration guide (AWS App Runner availability change).

Migration paths:

• App Runner to ECS (Express Mode or Fargate): the short hop AWS recommends. You keep the container and AWS-native networking.
• App Runner to EKS: the path teams take once anything else already runs on Kubernetes, or when multi-cloud is on the roadmap.

In fairness, App Runner has the fewest knobs, so it has the fewest ways to misconfigure a service. For getting a container online on AWS in minutes, it delivered.

Where does Google Cloud Run hit its ceiling, and when do you actually need GKE?

Google Cloud Run covers far more than App Runner: Cloud Run Jobs for batch and cron, up to 10 containers per instance, Direct VPC egress, GPUs and a 60-minute maximum request timeout. You still need GKE for stateful services, custom operators and CRDs, service meshes, per-pod network policy and raw kubectl.

Verdict: best for stateless HTTP and event-driven services on GCP. Wrong for stateful workloads, operator-driven internal platforms, or anything that needs cluster-level control.

Google's published limits:

• Request timeout: default 5 minutes, "can be extended up to 60 minutes (3600 seconds)" (Cloud Run request timeout).
• Job task timeout: default 10 minutes, up to 168 hours (7 days), or 1 hour for tasks using GPUs (Cloud Run task timeout).
• Instance size: 8 vCPU and 32 GiB per instance (Cloud Run quotas). GPU configurations have their own higher minimums.
• Instances: 100 per revision by default (Cloud Run max instances).
• Concurrency: up to 1,000 concurrent requests per instance (Cloud Run concurrency).
• Sidecars: "up to 10 containers per instance including the ingress container" (Cloud Run deploying).
• GPUs: NVIDIA L4 (24 GB VRAM) or NVIDIA RTX PRO 6000 Blackwell (96 GB VRAM), one GPU per instance (Cloud Run GPUs).
• Container contract: the ingress container listens on the PORT environment variable (8080 by default), and the writable filesystem "is an in-memory file system, so writing to it uses the instance's memory" (Cloud Run container contract).

Jobs and sidecars closed real gaps. Scheduled and parallel batch work is covered, and so are log shippers and proxies running next to your app. Long-lived StatefulSets, custom scheduling, admission control and your own operators are still out of reach.

Knative heritage is why Cloud Run has the cheapest exit of the three. "The Service resource of the Cloud Run Admin API v1 is compatible with the Knative Serving API" (Cloud Run APIs), and Knative's model of Services, Revisions and Routes with fractional traffic is what Cloud Run exposes (Knative Serving). Your revision and traffic-split habits carry straight onto GKE.

Cold starts have a documented fix, and it costs money:

• Startup CPU boost gives "additional CPU during instance startup time and for 10 seconds after," and you pay for the boosted CPU during startup (Cloud Run CPU).
• Minimum instances is the honest fix. Those instances "do incur billing costs," at a lower idle rate on request-based billing and the full rate on instance-based billing (Cloud Run min instances). Set it and your scale-to-zero savings are gone.

On cost, Cloud Run shines for spiky traffic. Request-based billing is $0.000024 per vCPU-second and $0.0000025 per GiB-second while active, with 180,000 vCPU-seconds, 360,000 GiB-seconds and 2 million requests free per month (Cloud Run pricing). Once the service runs 24/7, the ~$58/month instance-based figure in the table above loses to a committed-use node pool hosting several services.

Is Azure Container Apps just managed Kubernetes, and why does it delay the migration longest?

Yes, in substance: Microsoft describes Azure Container Apps as "powered by Kubernetes and open-source technologies like Dapr, KEDA, and envoy," and it "doesn't provide direct access to the underlying Kubernetes APIs" (Microsoft). You get Kubernetes-shaped primitives without a cluster to run, which is why it pushes the migration decision furthest out of the big three.

Verdict: best for teams that want Kubernetes-shaped primitives without a cluster or a platform engineer. Wrong for teams that need arbitrary CRDs, custom operators, node access or a specific CNI.

What that foundation gives you:

• Event-driven scaling through KEDA, which ships "70+ built-in scalers" (KEDA).
• Jobs with three trigger types: manual, schedule and event (Azure Container Apps jobs).
• Sidecars and init containers in the same app (Azure Container Apps containers).
• Scale: up to 1,000 replicas configurable per app, with a default maximum of 10 (Azure Container Apps scaling).

Workload profiles decide your compute ceiling (workload profiles):

• Consumption: 0.25 to 4 vCPU and 0.5 to 8 GiB per replica.
• Dedicated: D-series up to 32 vCPU / 128 GiB, E-series memory-optimized up to 256 GiB, and dedicated A100 GPU profiles in a limited set of regions.
• Serverless GPUs: NVIDIA A100 and T4 with automatic scaling (serverless GPUs).
• Core quotas per environment exist, but Microsoft says the defaults "depend on factors that include the age and type of your subscription" (Azure Container Apps quotas). Check yours before you plan a big scale-out.

What still forces the move to AKS:

• Cluster-level extensions and your own operators or CRDs
• Custom admission control
• Node tuning, kernel parameters, or specific VM types outside the profiles
• A specific CNI or per-pod network policy
• Anything that needs direct API server access

One honest caveat: portability is conceptual, not manifest-level. Container Apps YAML is Azure-shaped, so an AKS migration rewrites your config even though KEDA scalers, Dapr components and revisions carry over as concepts.

Azure Container Apps is the most underrated of the three for teams that want KEDA and Dapr without an AKS operator on call. I would put it on more shortlists than it currently gets.

How do AWS ECS Fargate, Fly.io, Render and GKE Autopilot compare as alternatives?

These four widen the shortlist with different ceilings. ECS Fargate is the most capable non-Kubernetes orchestrator on AWS, Fly.io fits globally distributed low-latency apps, Render is the simplest managed experience, and GKE Autopilot is real Kubernetes billed per pod with no nodes to manage.

AWS ECS Fargate

• Full task and service model, sidecars, service discovery, long-running and batch workloads, and tasks inside your own VPC.
• $0.04048 per vCPU-hour and $0.004445 per GB-hour for Linux/x86 in us-east-1 (AWS price list), the cheapest always-on option in the cost table.
• Trigger: multi-cloud, the Kubernetes ecosystem (Helm, operators, Argo CD), or hiring engineers who expect kubectl.

Fly.io

• Firecracker micro-VMs close to users in 18+ regions, Anycast routing, persistent volumes at $0.15/GB-month, and a shared-cpu-1x 1 GB machine at $6.70/month (Fly.io pricing).
• Everything runs on Fly.io's "own metal" (Fly.io), not your cloud account.
• Trigger: enterprise networking, compliance, or a requirement to keep workloads inside your own AWS, GCP or Azure account.

Render

• Strong developer experience and predictable tiers: Standard is $25/month for 1 CPU and 2 GB, Pro is $85/month for 2 CPU and 4 GB (Render pricing).
• Five regions: Oregon, Ohio, Virginia, Frankfurt and Singapore (Render regions).
• Trigger: nearly always compliance, data residency, committed-spend discounts or scale economics, because workloads run in Render's account.

GKE Autopilot

• Real Kubernetes with pod-based billing: you pay per second for the CPU, memory and ephemeral storage your pods request, plus the $0.10 per cluster-hour management fee offset by the $74.40 monthly free-tier credit (GKE pricing).
• Minimum requests are small: 50m CPU and 52 MiB on clusters that support bursting, 250m CPU and 512 MiB on those that do not (Autopilot resource requests).
• Beats Cloud Run on operators, stateful workloads, and no per-request timeout. Loses on per-service scale-to-zero and the cluster fee once you run more than one cluster.

Where these beat Qovery: a solo developer or two-person team shipping one stateless service with no compliance requirements should pick Cloud Run or Render. An internal developer platform is overkill for that case.

How do you avoid the Kubernetes migration entirely with Qovery?

You avoid the serverless container ceiling by running Kubernetes from the start and handing the operations to someone else. Qovery is an internal developer platform that deploys and operates applications inside your own AWS, GCP, Azure or Scaleway account, or on a Kubernetes cluster you already run, so there is no vendor feature ceiling to migrate away from later.

• Your account, your boundary (BYOC). Workloads run in your cloud account, so the cloud bill, committed-spend discounts and compliance boundary stay in your name.
• No abstraction ceiling. Anything Kubernetes runs, you can run: jobs, cron, stateful services, operators, GPUs, service meshes, custom network policy. It is your cluster.
• Kubernetes without operating it. Git-push deployments, preview environments per pull request, auto-stop for non-production environments, managed cluster upgrades, per-environment RBAC, and databases backed by managed cloud services.
• Shipping without a dedicated DevOps engineer. Developers get the self-service flow they liked on Cloud Run or Render, and the platform team keeps control.
• The cost angle. Your node pool is billed to your account at your negotiated rates, Savings Plans and CUDs included. That is the difference that matters once services are always on and per-second billing stops helping.

Who should not pick Qovery: a solo developer with one small stateless service and no compliance requirements. Cloud Run or Render is simpler for that case.

In the ranking, Qovery sits last on "forces a migration soonest" because removing the migration event is the whole point.

How do I deploy to my own cloud account from Claude Code or Cursor?

Install the Qovery Agent Skills once, then ask your coding agent in plain language to deploy the app into your own AWS, GCP, Azure or Scaleway account. The agent runs the steps and asks you to approve each change.

1. Install globally for every compatible agent (Claude Code, Cursor, Codex, OpenCode, Gemini CLI):

curl -fsSL https://skill.qovery.com/install.sh | bash

1. Or install for the current project only:

curl -fsSL https://skill.qovery.com/install.sh | bash -s -- --project

1. Add the MCP Server to Claude Code (OAuth, read-only by default):

claude mcp add --transport http qovery https://mcp.qovery.com/mcp --callback-port 4242

1. Enable write access only when you want the agent to change things (this also requires write access enabled in the Qovery Console):

claude mcp add --transport http qovery "https://mcp.qovery.com/mcp?read_write=true" --callback-port 4242

The Skills deploy (qovery-onboard, qovery-deploy, qovery-troubleshoot, qovery-optimize, qovery-speedup, qovery-preview, qovery-terraform). The MCP Server operates what already exists.

Then ask: "Deploy this container to my GCP account with Qovery and give me a preview environment per pull request."

Full setup: AI agent quickstart and Qovery for Claude Code.