Cloud
Cloudflare Workers vs Vercel Edge: Cold Starts, Pricing, Lock-In
April 202610 min read
Photo by Brett Sayles
Photo by Brett Sayles
This portfolio deploys on Vercel, my side projects run behind Cloudflare, and at work I operate boring VPS infrastructure — so I get to feel the trade-offs between the two serverless platforms with my own latency budgets and invoices. The comparison matters more in 2026 than it did two years ago, because the platforms have visibly diverged.
Cloudflare doubled down on V8 isolates running in every one of its data centers. Vercel, notably, walked back from the edge: its separate Edge runtime is no longer the headline, and Vercel Functions now default to a full Node.js runtime with Fluid compute — concurrency-optimized, region-anchored, scale-to-zero. Those are two genuinely different architectures, and picking between them is about which constraints you would rather live with.
Cloudflare Workers run your JavaScript in V8 isolates — the same sandboxing primitive as browser tabs — inside hundreds of points of presence globally. No containers, no VM boot, code executes wherever the request lands. The constraint is the environment: workerd is not Node.js. The runtime implements a large slice of Node APIs via compatibility flags, but native binaries and anything that assumes a real filesystem are out.
Vercel Functions execute in micro-VMs in a region you choose, defaulting to Washington D.C. — deliberately close to where most databases live. Fluid compute is the interesting part: instead of one isolated instance per request, concurrent requests share warm instances, so the idle time one request spends waiting on a database or an LLM API serves other requests. Vercel's docs pitch this directly at AI workloads, and it shows: I/O-heavy handlers get dramatically better economics than the classic one-lambda-per-request model.
Workers effectively do not have cold starts in the way you are used to. An isolate spins up in single-digit milliseconds during the TLS handshake, anywhere on the planet. For latency-critical paths — auth checks, redirects, A/B routing, API gateways — this is the killer feature, and there is nothing to tune.
Vercel's answer is statistical rather than absolute: Fluid compute reuses warm instances aggressively, so cold starts become rare instead of impossible. When one does happen it is a Node.js micro-VM boot — noticeably heavier than an isolate. The twist most people miss: a global edge function that talks to a single-region database pays cross-continent round trips per query, which usually costs more latency than the cold start did. Compute near the data beats compute near the user for most database-backed apps, and Vercel's region-first default is an honest admission of that.
Headline numbers from each platform's official pricing pages as of mid-2026:
| Dimension | Cloudflare Workers | Vercel Functions |
|---|---|---|
| Free tier | 100K requests per day, 10ms CPU per invocation | Hobby plan with bundled function usage for non-commercial projects |
| Paid entry point | 5 USD per month: 10M requests and 30M CPU-milliseconds included | 20 USD per seat Pro plan with usage-based function billing on top |
| Billing meters | Requests plus CPU-milliseconds only — wall-clock wait time is free | Active CPU, provisioned memory, and invocations under Fluid compute |
| Egress bandwidth | Free — no data transfer charges | Metered as Fast Data Transfer beyond plan allotments |
The philosophical difference: both platforms now bill compute on CPU actually burned rather than wall-clock duration — great for LLM-proxy workloads that wait on upstream APIs. The divergence is everything around compute: Cloudflare charges nothing for egress, which is decisive for media-heavy or high-throughput APIs, while on Vercel you are also paying for the platform — preview deployments, image optimization, observability — bundled into seats and usage meters.
Cloudflare: a compute platform you assemble
Wrangler, local dev via workerd, and a growing catalog of primitives: KV, R2, D1, Durable Objects, Queues. Enormous power, more assembly required, and the workerd-is-not-Node caveat surfaces in dependency choices.
Vercel: a framework deployment machine
Push a Next.js repo and everything — routing, ISR, image optimization, previews — just works. The polish is real and so is the coupling: the platform is at its best precisely when you are deepest inside its conventions.
Both platforms speak web-standard Request and Response, which keeps your handler code portable in theory. The lock-in lives in the services around the handlers:
From Jakarta, the difference is tangible: Cloudflare has presence in Indonesia, so Workers respond from nearby, while a default-region Vercel function answers from the US East Coast — roughly 200ms of pure geography per request. If your users are in Southeast Asia and your endpoint does not need a US-based database, the isolate model wins on physics alone.
Cloudflare is betting compute should run everywhere; Vercel is betting it should run near your data with maximum framework comfort. Both are right for different layers of the same app — and the strongest setups I run use Workers for the global edge layer and region-anchored functions or servers for the data layer. Pick per layer, not per brand loyalty.
Sources and further reading