Vercel alternatives
Sorted by the reason teams actually leave: the bill, the function limits, or a workload that never belonged on a request-scoped platform.
The verdict
Cloudflare suits edge economics, Railway and Render suit a container you want to own, Fly.io suits compute placed near users, and AWS suits a system that has earned its own infrastructure. Most teams whose only complaint is a moderate-traffic bill should fix a config problem before they switch.
The complaint has two different shapes and they get the same answer far too often. One is a genuine architecture mismatch: a background job or a long-running connection forced into a function that was never built to hold it. The other is a bill that spiked because images were not optimized or a route that should be static kept rendering on every request.
Only the first one is a reason to move. The second is a configuration fix, and it is the more common of the two by a wide margin.
How we judged these
Verified
We run Vercel in production on this site and on three client systems: Shift Link, TrialTriage and Lexpair. We also run AWS in production on six others, including TankAware and Cruise Search. The Vercel-versus-AWS judgement below draws on live infrastructure on both sides, not a trial account.
Cloudflare, Railway, Render and Fly.io are judged against their own documentation, since we have not run a production system on any of the four. That distinction is marked in each entry below rather than blurred.
- What triggers the switch
- The specific complaint that sends a team looking, not a general feature comparison.
- Compute model
- Whether the platform runs bounded functions, containers, or servers you configure yourself.
- Operational burden
- What a small team has to own after the move that Vercel owned for them.
- Migration friction
- What genuinely carries over from a Next.js app and what has to be rebuilt.
The field
| Platform | Best for | Compute model | Long-running jobs | Config ownership |
|---|---|---|---|---|
| Vercel (incumbent) | A Next.js front end shipped fast | Bounded functions, edge for static | Capped: 300s on Hobby, 800s max on Pro/Enterprise | Minimal, by design |
| Cloudflare (Pages/Workers) | Edge-heavy traffic at moderate cost | Workers at the edge, different runtime limits | Bounded, and the runtime is not Node by default | Low, but ports need rework |
| Railway | A container a team wants to own | Long-running containers, not request-scoped functions | Yes, a container can run indefinitely | Moderate: you own the container |
| Render | Similar to Railway, simpler pricing | Containers and managed services | Yes, background workers are a first-class service | Moderate: you own the container |
| Fly.io | Compute placed near specific users | Full VMs (Firecracker), deployed by region you choose | Yes, no duration cap | Higher: you pick regions and size instances |
| AWS | A system that has earned its own infrastructure | Whatever you configure: EC2, containers, or managed services | Yes, without platform limits | High: someone owns patching and on-call |
Ranked, by why the bill or the limit is the problem
Edge economics for traffic that is mostly static or simple
The right move when the complaint is purely the invoice on high-traffic, mostly static pages. Cloudflare's network and pricing are built around exactly that shape of traffic. A marketing site or a content-heavy app can move without much redesign.
Workers run on a different runtime than Node, not a Vercel-compatible one. A Next.js app using Vercel-specific APIs needs its compatibility layer checked route by route before the move, not assumed.
Best for
- A marketing or content site with high read traffic and light logic
- A team already comfortable with a non-Node edge runtime
- Cost per request matters more than framework convenience
Not for
- A Next.js app leaning on Vercel-specific features without checking Cloudflare's compatibility layer first
- A background job or a long database transaction
A container you own, without configuring the container yourself
Answers the duration-cap complaint directly. A Railway service runs as a container, not a request-scoped function. A background job or a long-running process becomes a normal deployment instead of a workaround, and setup keeps most of the git-push-to-deploy convenience that made Vercel easy to like.
The trade is real ownership of a running container: you watch memory, restarts and scaling behaviour that Vercel's function model hid from you. That is the point of moving, and also the new job.
Best for
- A queue worker or background job that outgrew a function's duration cap
- A team that wants a container without hand-writing infrastructure
- A backend service that needs to hold a persistent connection
Not for
- A team that wants zero infrastructure to think about at all
- A pure static or edge-cacheable front end, where the container is overhead
- 03
Render ↗
The same container model as Railway, with simpler pricing
Solves the same problem as Railway. A container runs as long as the job needs, and managed Postgres and background workers are first-class services rather than something bolted on. Render's pricing is published per tier, which makes forecasting easier than usage-based billing.
Deploy speed and the preview-URL habit that made Vercel easy to review do not fully transfer. A team used to a preview link on every pull request will notice the gap.
Best for
- A team that wants a background worker and a database as one bill
- Predictable, published pricing over usage-based billing
- A backend service alongside a separately hosted front end
Not for
- A team relying on per-pull-request preview URLs as part of how it reviews work
- A pure static site with no backend to speak of
- 04
Fly.io ↗
Compute you place close to specific users
Answers the region complaint specifically. Vercel functions default to a single region, which adds a round trip when a database sits elsewhere. Fly runs full virtual machines in regions you choose. Compute can sit next to the database instead of a continent away.
That control comes with sizing and region decisions Vercel made for you by default. A team picking Fly for one slow route, without a real multi-region need, has taken on more than the problem required.
Best for
- An app whose database sits in a specific region and latency to it is measurable
- A workload that benefits from running physically near a subset of users
- A team comfortable choosing and sizing virtual machines
Not for
- A team whose real complaint is cost, not latency
- A first product with no evidence yet of where its users are
- 05
AWS ↗
Full control, once a system has earned the operational weight
We run AWS in production on six client systems, so this entry draws on infrastructure we operate, not documentation alone. It gives up every limit Vercel imposes: no duration cap, no fixed payload ceiling, and control over where data sits. That control has a cost. Someone now owns patching, scaling and being on call.
The systems we run there needed it: long-running compute, strict data placement, or infrastructure a client already operated. A first product rarely starts with those requirements. Moving to AWS before they exist trades a platform bill for a staffing cost.
Best for
- A system with real compliance or data-placement requirements
- Long-running or resource-heavy compute a function model cannot hold
- A team already operating AWS infrastructure elsewhere
Not for
- A small team shipping a first product with no dedicated infrastructure owner
- A workload that a container platform like Railway or Render already solves
A Vercel front end paired with infrastructure elsewhere
Common questions
01What does moving off Vercel actually cost?
A Next.js application itself is portable, since Next.js runs on plain Node without Vercel. What does not carry over is the deploy workflow. Preview URLs per pull request, instant rollback and zero-config edge caching are platform features, and teams underestimate how much review process was built around them.
02Is Cloudflare actually cheaper than Vercel at scale?
For traffic that is mostly static or edge-cacheable, usually yes. That is the exact shape Cloudflare's network is priced around. An app doing heavy dynamic compute per request narrows the gap, and the bigger saving often comes from fixing a route that renders dynamically when it should not.
03Why is Netlify not ranked here?
Netlify answers the same question Vercel does: a managed front-end platform with functions and edge delivery. Teams choosing between the two are picking a vendor for the same job, not solving a different limit. This list is sorted by why someone would leave the model entirely, and Netlify does not answer that.
04When is AWS actually worth the extra operational weight?
Once a system needs long-running compute, strict control over where data sits, or infrastructure a client already runs. A small team shipping its first product usually reaches that point later than it expects. We keep Vercel or Supabase as the default, and move pieces to AWS only when a specific requirement demands it.
Related
- how we run Vercel in production →The documented function limits and the region default that catch teams out.
- AWS, reviewed from six production systems →When the operational weight of AWS is worth it, and when it is not.
- web app development →How we design the front end and infrastructure split before either is chosen.
