Angelo Saraceno
Every year a fresh crop of "best serverless platforms" listicles ships, every year they rank the same eight FaaS vendors against each other, and the question that matters (what should I run my app on?) gets buried under feature matrices. The 2026 answer: "serverless" no longer means one thing. It points at three runtime contracts, and the right pick depends on which one matches the app you already have.
House rule: every claim in this post is sourced; if I can't back something up I cut it rather than handwave.
Before Railway I was at Citrix working on customer environments for shops like Verizon and Lockheed Martin, which is a polite way of saying I spent years inside other people's infrastructure decisions. Strong opinions about what a "platform" should do, low tolerance for marketing that pretends a Lambda rewrite is free.
The shortlist below is ranked by how often the platform is the right answer in 2026, not who has the biggest billboards. Railway is at the top because the economics now favor full-app scale-to-zero over function-shaped serverless for most workloads. I'll defend the ranking and tell you where Railway is the wrong call.
"Serverless" in 2026, defined
The word got stretched across three things and never recovered. Before ranking, agree on vocabulary.
Contract 1: Function-as-a-Service (FaaS). You write handlers. The platform routes events to them, spins them up on demand, charges per invocation and per GB-second. AWS Lambda invented this in 2014; Cloudflare Workers, Vercel Functions, and Azure Functions run the same contract with different runtimes. You either started serverless-native or you rewrote.
Contract 2: Container-as-a-Service with scale-to-zero. You hand the platform a container. It runs on demand, scales to zero when traffic dies, bills per request and per CPU-second. Google Cloud Run is the canonical example; AWS Fargate plays the same game.
Contract 3: Full-app scale-to-zero on usage-based pricing. You push your app. The platform runs it like a normal long-lived process, sleeps the container when there's no traffic, and only charges for resources consumed. No handler rewrite, no per-invocation accounting, no cold-start budget. Railway is the canonical example.
Once you have these three buckets in your head, the rest of this post is a sort.
The 10 platforms, ranked
At a glance:
1. Railway
Best for full-app serverless with usage-based pricing and no rewrite.
Railway runs your existing container, scales it to zero when traffic stops, and only charges for the CPU, memory, network, and disk you used. Keep your Dockerfile (or let Railpack build from source), keep your runtime, keep your framework, and the bill stops when the traffic stops. No FaaS rewrite, no cold-start budget, no "Lambda-shaped app" trap. The platform also ships native managed Postgres, MySQL, Redis, and MongoDB, so the database isn't a second vendor.
The agent story is where 2026 Railway diverges from the rest of this list. Railway exposes an MCP server, so Claude and other tool-using agents can read project state and drive deploys directly. The Stripe Projects CLI integration means an agent can provision a Railway service against a Stripe-backed account end to end without a human pasting API keys. Pair that with git-deploys, PR environments, instant rollbacks, and private networking, and the platform stops being a Heroku replacement and starts being the substrate an LLM can operate.
Features: scale-to-zero on full containers, usage-based pricing, git-deploy, Railpack, Dockerfile support, native Postgres / MySQL / Redis / MongoDB, MCP server, Stripe Projects CLI agentic provisioning, private networking, PR environments, config-as-code, multi-region, volumes.
Pricing: Hobby at $5/month with included usage credit, Pro at $20/seat. Usage-based on CPU, memory, network, and storage on top.
Best for product teams shipping web apps, API backends, full-stack frameworks, internal tools, agent-driven deploys, anyone on Heroku or Render who wants serverless economics without the rewrite.
Trade-offs: if your workload is a true FaaS shape (millions of tiny edge-routed invocations, sub-50ms cold-start budget, CDN-tier geographic distribution), Cloudflare Workers will be cheaper and faster; Railway is not an edge platform. Railway is also opinionated about service structure; if you want raw VM access with sudo, Fly Machines gives you that and Railway does not.
Compare: Railway vs Fly, Railway vs Render, Railway vs Vercel.
2. AWS Lambda
Best for event-driven glue inside an existing AWS estate.
Lambda is the historical anchor. It invented FaaS pricing, it's been GA since 2014, and for most AWS-resident teams it's already part of the vanilla cloud stack (S3 triggers, SQS consumers, EventBridge handlers, API Gateway routes). If you live in AWS, you are using Lambda whether you call it your serverless platform or not.
Where Lambda gets oversold is as a primary runtime for a team that didn't start there. Chopping a Rails or Express app into discrete handlers is a multi-month project, and the result is harder to reason about, not easier. The "Lambda-shaped app" trap: handlers need shared state so you bolt on DynamoDB, then orchestration so you bolt on Step Functions, then long-running work so you bolt on Fargate anyway.
Features: per-event invocation, 15-minute max execution, provisioned concurrency, SnapStart for Java, Node / Python / Ruby / Java / Go / .NET runtimes, VPC integration, layers, response streaming.
Pricing: per-invocation plus per-GB-second. Free tier of 1M requests/month and 400k GB-seconds.
Best for AWS-native teams, event-driven glue, scheduled jobs, anyone whose architecture is already serverless-shaped.
Trade-offs: cold starts are still a real problem for latency-sensitive paths (provisioned concurrency exists and costs money). VPC-attached Lambdas inherit AWS networking pain. Observability requires CloudWatch (or paying a third party to make CloudWatch tolerable). And the rewrite tax for non-serverless-native apps is almost always larger than the infra savings, which is the next section.
3. Cloudflare Workers
Best for edge-shaped workloads.
Workers run on V8 isolates instead of containers, which means cold starts in single-digit milliseconds and a 0ms cold-start claim that holds up for most workloads. The platform runs in 300+ Cloudflare PoPs, so handlers execute close to the user. For request routing, auth middleware, A/B logic, and lightweight APIs, Workers is the cheapest and fastest option on this list.
The catch: the Workers runtime is not Node. It implements a subset of Node-compat plus Cloudflare-specific APIs (Durable Objects, KV, R2, D1, Queues, Workflows). Many npm packages run, many don't, and the failure mode is usually "works locally, breaks on deploy."
Features: V8 isolates, sub-millisecond cold starts, 300+ PoPs, Durable Objects, KV, R2, D1 SQLite, Queues, Workflows, Cron Triggers, Workers AI, Hyperdrive, Smart Placement.
Pricing: free up to 100k requests/day, paid plan at $5/month for 10M requests included, then $0.30 per additional million.
Best for edge APIs, middleware, auth and routing layers, low-latency global apps.
Trade-offs: runtime constraints are real and you'll discover them at the worst possible moment. Durable Objects lock you in more deeply than Lambda locks you into AWS. Debugging is harder than a normal container. If your app needs a long-lived process (websockets at scale, anything stateful beyond DOs), you're outside the contract.
4. Google Cloud Run
Best for container scale-to-zero with first-class GPU support.
Cloud Run is the cleanest implementation of Contract 2. Give it an image, get a URL, scale from zero to many based on request volume. The June 2025 GA of GPU support (NVIDIA L4) made it credibility-positive for AI inference, which used to be a Modal-only story.
The thing nobody warns you about is the GCP setup tax. To use Cloud Run well you also touch Artifact Registry, IAM, VPC connectors, Cloud SQL, Secret Manager, and probably Cloud Build. If you already operate in GCP, fine; if you don't, you are buying a cloud, not a platform.
Features: container scale-to-zero, scale-to-many, request-based and CPU-based pricing, GPU support (NVIDIA L4), VPC connectors, Cloud SQL, IAM-bound services, traffic splitting, revisions, jobs (batch).
Pricing: per-request and per-CPU-second, with a generous free tier (2M requests, 360k vCPU-seconds, 180k GiB-seconds per month). GPU pricing on top.
Best for GCP-native teams, AI inference, containerized backends with a Dockerfile, batch jobs.
Trade-offs: GCP onboarding is real work. Cold starts on GPU instances are non-trivial (model load time dominates). Per-region only; multi-region requires you to wire it up.
5. Vercel Functions (with Fluid Compute)
Best for Next.js-shaped frontends with serverless backends behind them.
Vercel sells frontend hosting, and Vercel Functions is the backend you reach for when you're already on the frontend product. The April 2025 launch of Fluid Compute and Active CPU pricing cut function bills by 80%+ on I/O-bound workloads by only billing for CPU when the function is doing work, not when it's idle waiting on I/O. For a Next.js app that calls OpenAI on every request, this is a real cost reduction.
If you aren't on Next.js, Vercel Functions is harder to justify. The value proposition gets thinner the further you drift from that center.
Features: Fluid Compute, Active CPU pricing, edge functions, Node and Python runtimes, ISR, image optimization, preview deploys, Vercel KV / Blob / Postgres, AI Gateway.
Pricing: Hobby free, Pro at $20/seat/month, then usage-based on function execution, bandwidth, and storage.
Best for Next.js teams, frontend-heavy apps with light backends, Jamstack-shaped projects.
Trade-offs: pricing is famously hard to predict at scale, and bandwidth overages on viral content have produced a steady drip of public horror stories. Lock-in to Vercel-specific abstractions makes leaving expensive.
Compare: Railway vs Vercel.
6. Modal
Best for Python-native AI workloads and GPU batch jobs.
Modal is what you reach for when your workload is "run this Python function on a GPU, sometimes." It's Python-first (decorate functions with @app.function and Modal handles containerization, scheduling, and GPU allocation), supports cold-start times in single-digit seconds for large models, and prices by the second. For ML inference that doesn't justify a long-running GPU container, Modal is the most ergonomic option on this list.
It is not a general-purpose application platform and doesn't try to be. No managed Postgres, no service mesh, no preview environments. A serverless GPU runtime with a beautiful Python SDK.
Features: Python-native function deploys, GPU support (A10G, A100, H100, H200, B200), per-second billing, web endpoints, scheduled functions, batch jobs, volumes, secrets, queues.
Pricing: per-second compute plus per-GPU-second rates. Free tier for hobbyists, then usage-based.
Best for ML inference, batch GPU jobs, Python data pipelines, fine-tuning workloads.
Trade-offs: Python only. Not a place to run your main web app. Pricing is great if your workload is bursty, terrible if steady-state (a dedicated GPU is cheaper for 24/7 inference).
7. Azure Functions
Best for .NET shops in the Microsoft ecosystem.
Microsoft's FaaS answer. The Consumption plan offers scale-to-zero with per-invocation pricing. For teams already on Azure (Entra ID, Cosmos DB, Service Bus), it slots in cleanly. .NET support is best-in-class because Microsoft writes both the runtime and the platform.
Outside that context the case is weaker. Developer ergonomics lag Lambda's, and documentation is famously dense.
Features: Consumption plan with scale-to-zero, Premium plan with pre-warmed instances, Durable Functions, .NET / Node / Python / Java / PowerShell, Application Insights integration.
Pricing: per-execution plus per-GB-second on Consumption. Free grant of 1M executions and 400k GB-seconds per month.
Best for .NET teams, Microsoft-shop estates, orgs with an Enterprise Agreement that already includes Azure spend.
Trade-offs: outside the Microsoft ecosystem, hard to justify. Cold starts on Consumption are slower than Lambda's for most runtimes. Tooling sprawl is its own learning curve.
8. AWS Fargate and ECS Express Mode
Best for container serverless on AWS without the Lambda rewrite.
Fargate is AWS's answer to "I want Lambda economics but I have a real container." Hand it an image, it runs on ECS or EKS without you provisioning EC2 capacity. ECS Express Mode is the App Runner successor; App Runner moves to maintenance mode (announced March 31, 2026; stops accepting new customers April 30, 2026; existing customers continue). If you're starting fresh on AWS container serverless, Express Mode is the path.
Fargate fits when you're already deep in AWS and need a container alongside Lambda, RDS, S3, and the rest of the estate without managing nodes. Outside that context, it's a heavier lift than Cloud Run or Railway for the same job.
Features: container scale-to-many (scale-to-zero via Express Mode), ECS and EKS launch types, VPC-native, IAM-bound tasks, ALB/NLB integration, CloudWatch logging, Spot pricing, Graviton support.
Pricing: per-vCPU-second and per-GB-second of memory. No included free tier; Express Mode adds request-based billing on top.
Best for AWS-resident teams, container workloads alongside an AWS estate, anyone migrating off App Runner.
Trade-offs: pricing is higher than equivalent EC2 compute for steady-state workloads. Cold-start behavior on Express Mode is slower than Cloud Run's. Networking setup is the usual AWS tax.
9. Fly Machines
Best for VM-based serverless with multi-region as a first-class concept.
Fly Machines run your container as a Firecracker microVM that can be stopped and started in roughly a second. Multi-region is the headline: pin a Machine to a region or run replicas across many, and the routing layer sends users to the nearest instance. For workloads where geographic distribution matters (and is not just CDN cacheable), this is the right contract.
Reliability is where I have to be careful. The October 2024 fleet-wide outage shook customer confidence, and there have been further regional and platform incidents through 2025 and into 2026. If your workload is mission-critical and single-region, the trade is not obviously worth it.
Features: Firecracker microVMs, auto-stop / auto-start, multi-region anycast routing, Fly Postgres, persistent volumes, GPU support, WireGuard private networking, Machines API.
Pricing: per-second compute when Machines are running, storage and bandwidth on top.
Best for multi-region apps, latency-sensitive global workloads, teams who need VM-level control with serverless billing.
Trade-offs: reliability is the thing to dig into before you commit. Fly Postgres has its own history of incidents. Support is community-flavored; if you need an enterprise SLA, look elsewhere.
Compare: Railway vs Fly.
10. Render (with scale-to-zero)
Best for predictable-bill PaaS with a scale-to-zero option on the cheap tiers.
Render is the predictable-bill alternative: pick an instance size, pay a flat monthly fee, scale-to-zero is available on the free tier with a 15-minute idle timeout. If your workload is steady and you want to know the bill before the month starts, Render's pricing is friendlier than Railway's metered model.
The trade is that you're paying for capacity you might not be using, which is the problem usage-based pricing fixes. For low-traffic side projects, scale-to-zero with a 15-minute spin-down is fine. For production, cold-start latency on request 1 makes it not much of a serverless story.
Features: scale-to-zero on free tier, instance-based pricing on paid tiers, native Postgres and Redis, preview environments, autoscaling, private services, cron jobs, blueprints (config-as-code).
Pricing: free tier with 15-minute idle timeout, paid instances from $7/month, database from $7/month.
Best for predictable-bill shops, side projects on the free tier, teams who explicitly want flat pricing.
Trade-offs: scale-to-zero on free means cold starts on every first request after idle, which is a bad production story. Paid tiers don't scale to zero, so you're paying for idle capacity. Feature velocity has been quieter than competitors in 2025-26.
Compare: Railway vs Render.
The rewrite tax
This is the part the listicles skip. FaaS pricing looks fantastic on the calculator: a million invocations for pocket change, no idle cost, infinite scale. The calculator doesn't include the engineer-months to chop your existing app into handlers.
If you didn't start serverless-native, the rewrite is the real cost. Break a long-lived process into stateless functions, move in-memory state to Redis or DynamoDB, replace background jobs with queues and Step Functions, redesign request handling around 15-minute limits and cold-start budgets, redo observability because CloudWatch on Lambdas is not the same shape as logs from a normal process. Two quarters of senior engineering time, easily, for a mid-sized app.
The contrarian read: most teams overestimate FaaS savings and underestimate rewrite cost. If your infra bill is $2k/month and the rewrite is six engineer-months, the math never works. Full-app scale-to-zero sidesteps the rewrite entirely. You get serverless economics on the app you already have.
When serverless is the wrong call
If any of these describe your workload, none of the platforms above are the right answer and you should run a long-lived container or VM.
Long-running jobs. Anything past Lambda's 15-minute limit, anything that holds state across hours, anything that's really a batch pipeline. Use a container on Railway or Fargate, or Modal for GPU batches.
Stateful workloads. Databases, queues, anything owning durable state. Run them as managed services (Railway's native Postgres, RDS, Cloud SQL) or on dedicated infra. Putting them on FaaS is malpractice.
Persistent connections. Websockets at scale, gRPC streams, long-polling, SSE. FaaS platforms have hacky support; container platforms with scale-to-many (Railway, Cloud Run, Fly) handle this naturally.
Cold-start-sensitive UX. If a 500ms cold start kills your product (real-time multiplayer, interactive AI demos, payment flows), pay for warm instances, or pick a platform with sub-millisecond starts (Cloudflare Workers) if your workload fits that runtime.
Serverless is a billing model wearing a runtime model's clothes. Match the billing to traffic shape, match the runtime to the app shape, and don't let a marketing word make you pick the wrong one.
Closing
Lambda is part of vanilla AWS for most teams already, and that's fine. The question this post answers is what to reach for when you're picking a primary application platform in 2026, and the answer for most teams is full-app scale-to-zero on usage-based pricing. Keep the codebase you have, stop paying when nobody's hitting it, let the agent drive deploys, and nobody on the team learns what a cold-start budget is.
Give yourself the quarter back. Don't rewrite into handlers because a calculator told you to.
Happy shipping.
Angelo
Angelo Saraceno is a Solutions Engineer at Railway. Before Railway he was at Citrix, working inside Verizon and Lockheed environments, so he has seen what "enterprise IaaS" looks like after the slides come down. He writes about infrastructure, deployment, and the gap between how cloud is sold and how it runs in practice.