Cloudflare vs Vercel: How We Actually Decide Where to Deploy

This is not a "which is better" post, because the answer is neither and the question is lazy. Both platforms are excellent at what they were built for. The useful question is: what is your app actually made of, and where will each platform hurt?

The one difference that matters most

Cloudflare Workers do not run Node.js. They run on V8 isolates with a Web-standard runtime — fetch, Request, Response, Web Crypto — plus a growing compatibility layer for Node APIs.

The upside is real: no cold starts worth measuring, tiny per-request overhead, and your code running in hundreds of locations by default. The cost is equally real: any npm package that reaches for native bindings, the filesystem, or deep Node internals will not run there. You find out at deploy time, or worse, at runtime.

Vercel functions give you a real Node environment. Whatever you found on npm, works. That is worth a great deal when your API depends on a PDF library, an image processing package, or an SDK written in 2019.

So the first question is not about price or performance. It is: does your backend depend on the Node ecosystem, or is it mostly fetch, JSON and a database?

Where each one clearly wins

Vercel, when…

• You are building Next.js. Vercel makes Next.js. ISR, streaming, server actions, the newest rendering primitives — they land here first and they work without adapters. Fighting an adapter to save a few dollars is a bad trade on a deadline.
• Your API needs the Node ecosystem. Heavy npm dependencies, an SDK that assumes a filesystem, anything with native modules.
• Preview deployments are core to how the team works. Vercel's per-PR previews and the review workflow around them are still the best in the business.
• You value time-to-first-deploy above all. It is genuinely hard to get stuck.

Cloudflare, when…

• Bandwidth is a real number. Media, downloads, large assets, viral spikes. This is the difference between a shrug and a bill that ruins a month.
• The app is a static frontend plus a few endpoints. Which describes an enormous share of real products. Pages plus Workers plus D1 or KV is fast, cheap and pleasant.
• You want state at the edge. Durable Objects are genuinely differentiated — real-time collaboration, presence, rate limiting, per-user coordination — and there is no clean equivalent elsewhere.
• You already use Cloudflare for DNS, WAF and caching. Owning the whole request path from the DNS lookup to the response removes a lot of debugging archaeology.
• Egress costs matter. R2 charges no egress fees. If you serve files at volume, this alone can decide it.

The comparison, honestly

What we actually do

Our default split, after shipping on both:

• Marketing sites and product pages → Cloudflare Pages. Static HTML, prerendered at build, a couple of Functions for form handling. Fast, effectively free, nothing to babysit. This site runs exactly that way — the homepage is prerendered React, the product and blog pages are plain static HTML, and the contact form is a single Function.
• Next.js applications with real server rendering → Vercel. The adapter tax is not worth paying when the framework's own platform is right there.
• Anything with real-time state, presence or coordination → Cloudflare, on Durable Objects. There is not a close second.
• Anything serving big files → Cloudflare, with R2. Egress pricing decides it before anything else gets a vote.

The mistake to avoid

Do not pick a platform and then discover halfway through that a load-bearing dependency does not run on it. Spend twenty minutes at the start of the project doing the boring thing: list every dependency your backend needs, and check that each one runs on your target runtime.

Twenty minutes at the start, or a rewrite in week five. That is the actual choice, and it has nothing to do with which platform has the nicer dashboard.