Every engagement ends with the same slide. The app is built, the client loves it, and then someone in the back asks where it will live, and the room splits into two camps with the fervor of a sports rivalry. Vercel vs Cloudflare for deployment is the closest thing infrastructure has to a bar argument, and like most bar arguments, both sides are right about different questions.
I've shipped client tools on both platforms. I've also migrated one tool from one to the other at month four because the invoice grew teeth, which is the kind of education you only need once.
So here's the honest version, with the partisanship removed and the bill included.
Pick Vercel when the app is Next.js-first, the team wants zero infrastructure thought, and traffic is modest. Pick Cloudflare when traffic is heavy, the budget is thin, or you want Workers, KV, and R2 primitives at the edge for pennies. The real deciders are framework fit, egress pricing at scale, and who operates the thing after the engagement ends.
The Real Question Behind Vercel vs Cloudflare for Deployment
The question is never which platform is better. It's which platform is better for this workload, this team, and this client's credit card. A marketing site, an internal dashboard, and a public API serving ten million requests a day are three different animals that happen to share a DNS system. Any comparison that doesn't name the workload first is a horoscope.
Both platforms are genuinely good, which is what makes the decision annoying. You're not choosing between right and wrong. You're choosing which trade-offs you'd rather defend in a meeting six months from now.
Framework Fit Wins First
If the app is Next.js with all the trimmings (server components, ISR, image optimization, middleware), Vercel is the home stadium. It runs those features the way their authors intended, with preview deployments that make stakeholders unreasonably happy. This is exactly why it anchors the Next.js internal tools stack: the framework's party tricks just work, and nobody reads docs on a Friday afternoon.
Cloudflare's answer is Workers: framework-agnostic, close to the metal, and happiest when you think in small composable functions backed by KV, R2, and D1. You can run Next.js there through adapters, and support keeps improving, but you're living the ported life. Some framework features behave differently at the edge, and your deployment docs become a page longer.
The heuristic I use on engagements: if the repo's package.json leads with Next.js and the roadmap mentions server components, stop deliberating and deploy where the framework is native. If the repo is a grab-bag of webhooks, scheduled jobs, and a thin API over storage, Workers will feel like it was designed for exactly that, because it was.
Worth saying out loud: the split-brain option is legitimate. Plenty of engagements end up with the marketing site and app on Vercel and the heavy webhook or file-processing work on Workers, each doing what it's good at. It costs you one extra dashboard to monitor and buys you the right price-performance on both halves. Purists hate it. Invoices love it.
The Bill at Scale
At hobby scale both platforms are nearly free, which is why the argument stays theoretical for so long. The difference shows up with traffic. Illustrative numbers that will age like milk but keep the shape: at a million requests a month you might pay $25 versus $5; at ten million requests with real bandwidth, something like $2,400 versus $310, mostly because of egress pricing. Data leaving the building is where bills are born.
Remember who pays after you leave. A client's finance team will tolerate a $40 platform line item forever; a $900 one gets a meeting. When the workload is heavy and the buyer is cost-sensitive, the FDE stack essentials bias toward primitives you can meter and explain in plain words: requests, gigabytes, seconds.
One more trap: bandwidth-heavy features hide in innocent places. A dashboard that streams photos, a report generator that emails PDFs, a public file-download endpoint for partners. Any of these can turn a cheap app into an egress story, so grep the roadmap for the words "download," "export," and "video" before you sign off on a platform.
This is where my month-four migration came from. We'd built a partner portal on the wrong side of the fence: modest traffic, but a file-download endpoint that moved real gigabytes every day. The first three invoices were cute. The fourth had a line item that made the client's finance lead forward it to me with no comment, which is the worst kind of comment. Moving the download path to object storage with an egress-free exit took one weekend and cut the bill by two-thirds; the lesson cost a single awkward meeting.
Cold Starts and Edge Myths
Cloudflare's isolates start in single-digit milliseconds because they skip the whole container boot. Traditional serverless functions can take hundreds of milliseconds cold. This matters enormously for user-facing global apps and approximately zero for an internal tool used by forty people in one timezone who all click the button at 9 AM anyway.
The word "edge" deserves suspicion too. Running compute near users is great when your users are everywhere. When your users are a warehouse in Ohio, the edge is called "the server in Virginia," and that's fine. Don't pay a complexity tax for a latency benefit nobody will ever feel, and don't let anyone sell you a globe when you needed a forklift.
Measure before you optimize, because perceived latency is sneaky. On one internal tool we logged the full round trip and found the platform contributed 90 milliseconds while the client's own VPN contributed 400. Moving platforms to chase cold starts would have fixed the wrong tenth of the problem. The expensive latency usually lives in your queries, your chatty frontend, or the corporate network, none of which care which logo is on the invoice.
What the Client IT Team Can Operate
Call it the least glamorous decider, because it usually wins: after handoff, who opens the dashboard? Vercel's console is friendly to generalists, deploys are git pushes, rollbacks are a click. Cloudflare's dashboard is powerful and dense, wonderful for engineers, occasionally intimidating for the office admin who got voluntold into owning the website.
Match the platform to the operator you'll never meet. If the honest answer is "nobody will operate this," choose the one with fewer knobs and route the alert emails to yourself. And if the client's data can't leave their own metal at all, that's a different conversation entirely; the self-hosted stack for client sites is the map for that one.
The FDE Decision Checklist
Six questions, in order. One: framework fit, because Next.js features in active use lean Vercel. Two: traffic, because more than a few million monthly requests means you model both bills before choosing. Three: primitives, because KV, queues, and object storage stitched close to compute lean Cloudflare. Four: the operator, meaning the human who owns this after month six. Five: egress cost at twice your expected traffic. Six: which 3 AM failure email you'd rather receive.
Most engagements land on boring answers, which is the point. Deploys should be the least interesting part of the project, a non-event that happens every Friday without ceremony. Pick the platform that makes shipping dull, then get back to the part clients actually pay for: the software.