Vercel vs Cloudflare Pages vs Railway: Where to Deploy in 2026

These three platforms are usually compared on features, which is the wrong axis. All of them will deploy your app. What differs, and what will actually affect you, is the billing model, because each one turns expensive at a different point and in a different way.

The three billing shapes

Vercel charges for bandwidth and function invocations. The free tier is generous. Past it, you pay per gigabyte transferred and per million invocations, with no ceiling.

Cloudflare Pages charges nothing for static assets. Unlimited bandwidth, unlimited requests. Workers (the serverless runtime) are metered per request, but at a rate that is roughly two orders of magnitude cheaper than the equivalent on other platforms.

Railway charges for resources consumed: vCPU, memory, and network, metered by the minute, against a monthly credit on the free tier.

The important difference is not the price. It is what happens when you get a traffic spike.

On Cloudflare, a static site that goes viral costs the same as one nobody visits: zero. On Vercel, a static site that goes viral transfers bandwidth, and bandwidth is the line item that produces the screenshots people post of $3,000 invoices. On Railway, a traffic spike means your container needs more CPU and memory, and you pay for the hours it runs.

When each one is obviously right

Static site, pre-rendered, no server logic → Cloudflare Pages. There is no argument for paying for this. A blog, a documentation site, a marketing page, a directory: Pages serves it from the edge with unlimited bandwidth for free. The only reason to choose otherwise is if you need a framework feature that only Vercel's runtime supports.

Next.js with server-side rendering or ISR → Vercel, with caveats. Vercel is where Next.js is developed, so new features land there first and work best. The caveat is that SSR means function invocations, and function invocations plus bandwidth is the combination that produces surprise bills. Set a spending limit before you deploy, not after.

Long-running processes, background workers, a database that needs to be always on → Railway. Serverless is the wrong shape for a worker that polls a queue for six hours. Railway gives you a container, a persistent disk, and a managed Postgres, and bills you for what it uses.

Anything with a Postgres database and auth → consider Supabase alongside whichever host you pick. It is not a hosting platform for your frontend, but it removes the need to run a database, which changes which hosting you need.

The Vercel bandwidth question

This deserves its own section because it is the most common way people get hurt.

Vercel's free tier includes a bandwidth allowance. Once exceeded, bandwidth is billed per gigabyte at a rate that is reasonable per gigabyte and unreasonable per viral event. A page that goes from 1,000 to 500,000 visits in a day can transfer several terabytes.

There are mitigations that work:

• Set a hard spending limit in the dashboard. This is a two-minute action that most people skip.
• Put Cloudflare in front as a CDN proxy, so repeated requests are served from Cloudflare's cache rather than Vercel's origin. This is slightly awkward architecturally and it works.
• Move static assets to a separate host. Images and video are the bulk of the bytes. Serving them from Cloudflare R2 or Pages means the bandwidth does not hit Vercel at all.

The reason people get surprised is that the free tier feels like a plan rather than a trial. It is a plan, and it has a cliff.

Cold starts and the thing nobody measures

Serverless functions have cold starts: the first request after a period of inactivity waits for the runtime to initialise. For an API endpoint called a few times a minute, this is invisible. For an interactive app, it is a visible delay that users describe as "slow" without knowing why.

Railway does not have this problem because the container is always running. That is also why Railway costs more at low traffic: you are paying for idle time.

The trade is: pay for idle (Railway) or pay for spikes (Vercel). Static on Cloudflare avoids both.

A concrete recommendation

If I were starting today:

• Frontend on Cloudflare Pages, regardless of framework, as long as it can build to static output.
• Server logic on Cloudflare Workers if the logic is request-scoped and stateless, otherwise Railway.
• Database on Supabase for Postgres, or Railway's managed Postgres if it is already there.
• Vercel only when a specific Next.js feature requires it, and with a spending cap set on day one.

That stack has a predictable cost shape: near zero until you have real usage, then linear. No cliffs.

The thing all three get right

Preview deployments. Every branch gets a URL, so review happens on a real build rather than a screenshot. This was Vercel's original insight and it is now table stakes. If a platform does not do this well, it is not in the running.

What to check before you commit

1. Where is the cliff? Find the exact number where the free tier ends and what the next tier costs. Write it down.
2. Is there a hard spending limit? If not, set one manually or accept that you are one bad day away from a large bill.
3. What does egress cost? This is the line item that varies most between providers and the one that grows fastest.
4. Can you leave? All three are reasonably portable for static output. For serverless functions, the code is portable but the runtime APIs are not, so budget for a rewrite if you switch.