What is the fundamental architectural difference between Cloudflare Workers and Vercel Functions?

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.

Do Cloudflare Workers really have no cold starts?

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.

How do the two platforms differ on pricing, especially for egress and AI workloads?

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.

Where does the real lock-in live on each platform?

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.

When should you choose Cloudflare Workers over Vercel, and vice versa?

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.

Cloudflare Workers vs Vercel Edge: Cold Starts, Pricing, Lock-In

Two very different bets on serverless compute. Comparing Cloudflare Workers and Vercel Functions on cold starts, pricing models, DX, and exit costs.

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.

Two Different Compute Models

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.

Cold Starts: Different Problems Entirely

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.

Pricing: CPU Time vs Active CPU Plus Memory

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.

Developer Experience: Platform vs Framework

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.

Lock-In: Where the Exits Are

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:

Cloudflare's gravity is its primitives. Durable Objects and KV have no drop-in equivalents elsewhere; an app built around them is a rewrite to move. R2's S3-compatible API is the friendly exception.
Vercel's gravity is the framework integration. Migrating a plain API route is trivial; migrating an app that leans on ISR, preview deployments, and Vercel's image pipeline means rebuilding platform features, not just moving functions.
The hedge for both: keep state in portable stores — Postgres, S3-compatible object storage — and treat platform-exclusive primitives as conscious, documented bets rather than defaults.

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.

How I Actually Choose

Next.js product where shipping speed is the constraint: Vercel, with Fluid compute doing real work for AI and I/O-heavy routes.
Latency-critical glue at the edge — auth, redirects, geo-routing, API gateways: Cloudflare Workers, no contest.
High-egress APIs and media serving: Cloudflare, because free egress dominates the bill at volume.
Database-centric backends: either platform anchored in one region next to the database — or honestly, a boring VPS, which is still where most of my production workloads live.

The Takeaway

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