Cloud
Cloudflare Workers vs Vercel Edge: Cold Starts, Pricing, Lock-In
April 202610 min read
Photo by Brett Sayles
Cloudflare Workers run JavaScript in V8 isolates — the same sandboxing primitive used by browser tabs — across hundreds of global points of presence, with no container or VM boot. Vercel Functions execute in micro-VMs anchored to a chosen region (defaulting to Washington D.C.) and use Fluid compute, which lets concurrent requests share warm instances instead of spinning up one isolated instance per request. These are genuinely different architectures optimized for different constraints.
Workers effectively eliminate cold starts as traditionally understood — isolates spin up in single-digit milliseconds during the TLS handshake, anywhere on the planet. Vercel's approach is statistical rather than absolute: Fluid compute aggressively reuses warm instances to make cold starts rare. However, a critical trade-off is that a globally distributed edge function querying a single-region database pays cross-continent round-trip latency per query, which often costs more total latency than a cold start would have.
Both platforms bill on actual CPU time burned rather than wall-clock duration, which benefits LLM-proxy workloads that spend most of their time waiting on upstream APIs. The key divergence is egress: Cloudflare charges nothing for data transfer, making it decisive for media-heavy or high-throughput APIs. Vercel bundles egress billing (as Fast Data Transfer) alongside platform features like preview deployments and image optimization into its seat and usage meters.
Both platforms use web-standard Request and Response objects, so handler code is portable in theory. Lock-in lives in the surrounding services: on Cloudflare it is primitives like Durable Objects and KV, which have no drop-in equivalents elsewhere and require a rewrite to migrate. On Vercel it is the framework integration — ISR, preview deployments, and the image pipeline — meaning migration means rebuilding platform features, not just moving function code. The recommended hedge for both is to keep state in portable stores like Postgres or S3-compatible object storage.
Cloudflare Workers are the clear choice for latency-critical edge logic — auth checks, redirects, geo-routing, API gateways — and for high-egress APIs and media serving, where free egress dominates the bill at volume. Vercel is better suited for Next.js products where shipping speed matters, especially with AI and I/O-heavy routes that benefit from Fluid compute. For users in Southeast Asia, Cloudflare's presence in Indonesia means Workers respond locally, while a default Vercel function answers from the US East Coast with roughly 200ms of extra latency per request.
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