#1Edge runtimes: which platform fits the workload

What we tested: We evaluated the tools and techniques described in this article using real developer workflows. All browser-based tools on this site run locally, your data never leaves your machine.

The practical choice is not “which runtime is coolest?” It is “where does my request need to be, how much memory does it need, and how much Node compatibility do I actually require?”

I choose by workload, not branding. If the route is mostly auth, routing, or header rewriting, the global isolate model is hard to beat. If the job is Next.js SSR with heavier dependencies, Vercel’s compute model can make more sense. If I want strong defaults and explicit permissions, Deno’s model is attractive.

This comparison stays focused on the trade-offs that matter in production: latency, memory, regional reach, and the kind of code each platform is happiest running.

#2The Big Architectural Convergence

In 2022, the edge market had a clear split: Cloudflare Workers (V8 isolates), AWS Lambda@Edge (containers), Vercel (serverless functions), Deno Deploy (V8 isolates). In 2026, almost everyone runs V8 isolates:

• Cloudflare Workers, V8 isolates, the original
• Vercel Edge Runtime, built on Cloudflare Workers under the hood
• Vercel Fluid Compute, V8 isolates with reused execution contexts and bigger CPU/RAM
• Deno Deploy, Deno-flavoured V8 isolates with explicit permissions
• Netlify Edge Functions, powered by Deno

The exception is AWS Lambda@Edge with Node, which still uses containers and pays 250–800 ms cold starts as a result. Most teams have moved off it.

Why V8 isolates won: a V8 isolate is a lightweight JavaScript runtime, not a process. The host platform can hold thousands of them in memory at once and route each request to the appropriate isolate in <5 ms, no container boot, no VM spin-up.

#3The same handler, three platforms

The convergence on Web Standards APIs (Request, Response, Headers) means a simple handler is portable. This exact function runs on Cloudflare Workers, Vercel Edge, and Deno Deploy without modification:

export default {
  async fetch(request, env) {
    const url = new URL(request.url);
    const start = performance.now();

    // Read a KV binding (Cloudflare) / env var (Vercel/Deno), same API
    const greeting = env.GREETING ?? "Hello from the edge";

    const body = JSON.stringify({
      message: greeting,
      region: request.headers.get("cf-ipcountry") ?? "unknown",
      ttfb_ms: (performance.now() - start).toFixed(2),
    });

    return new Response(body, {
      headers: {
        "content-type": "application/json",
        "cache-control": "s-maxage=60, stale-while-revalidate=300",
      },
    });
  },
};

The platform differences only surface when you reach for proprietary APIs, Cloudflare's env.KV, Vercel's geolocation(), or Deno's permission model. For routing, auth, and header manipulation, the code above is genuinely portable.

#2Cold Start Performance

The 2026 numbers (typical, not pathological):

Cloudflare uses "shard and conquer" consistent hashing to route repeat requests for the same Worker to the same PoP node, so the same isolate is reused and the warm rate sits at 99.99%. The other 0.01%, the genuine cold start, is single-digit milliseconds because spinning up a new isolate is fundamentally cheap.

The practical implication: cold start is no longer a primary selection criterion between V8-based platforms. They're all fast enough that other factors dominate.

#2Global Network Reach

This is where the architecture choices actually diverge.

• Cloudflare: code runs at 330+ PoPs with 300 Tbps of total network capacity. There is no region selection because there are no regions, every deployment is global by default. 95% of users are within 50 ms of an execution location.
• Vercel: serverless functions run in 19 regions, default iad1 (Virginia). Static assets are global; compute is regional. If your user is in Mumbai and you've deployed to iad1, every function call eats a transcontinental round trip.
• Deno Deploy: 35+ regions, automatically routed to the nearest.

For an API-heavy workload, webhook receivers, edge auth checks, A/B test routing, Cloudflare's network density is the differentiator. The function call doesn't need to be in the right country; it needs to be in the right city.

For an SSR workload tied to a database in us-east-1, the network advantage is smaller because every dynamic render is bounded by the DB round trip anyway. The function might as well be where the DB is.

#2TTFB on Warm Requests (2026 Median)

These are warm-path numbers, actual code execution, not just network latency. Vercel's regional model makes itself felt anywhere outside the US for users far from iad1.

#2SSR Throughput: Where Vercel Wins

Here's the wrinkle: when the workload is Next.js server rendering, Vercel Fluid Compute outperforms Workers by 1.2–5×.

This is not a comparison of runtimes; it's a comparison of resource allocations at each platform's default tier:

• Workers (default): shared CPU, 128 MB RAM
• Fluid Compute (default): 2 vCPU, 4 GB RAM

If your render needs React, a few MB of code chunks, a database client, and 100 ms of compute per request, the RAM/CPU headroom matters more than the network. Fluid Compute is faster for that workload because it has more compute to spend, not because the runtime is fundamentally better.

If you're routing webhooks or doing edge auth, you don't need 4 GB of RAM, Workers' density and global distribution win.

Picking based on what you actually do:

#2Resource Constraints

This bites teams who don't read the limits before they ship.

#3Cloudflare Workers

• Memory: 128 MB per request
• CPU time: 10 ms (free), 30 s (paid), wall-clock time can be longer if you're awaiting I/O
• Request body: up to 100 MB
• Subrequests: 50 per request (free), 1,000 (paid)
• Runtime: Web Standards + a growing Node.js compatibility layer. Not 100% Node.js.

#3Vercel Fluid Compute

• Memory: 4 GB on performance tier
• vCPU: 2 on performance tier
• Execution time: 5 minutes (Pro), 15 minutes (Enterprise)
• Runtime: full Node.js, all npm packages work

#3Deno Deploy

• Memory: 512 MB to 2 GB depending on tier
• CPU: 50 ms per request (free), 1 s + (paid)
• Runtime: Deno + npm compatibility via Deno 2.0
• Permissions: explicit, no network, env vars, or filesystem unless granted

The most common failure mode for new Workers users: the 128 MB memory cap. Image processing, large JSON parsing, in-memory caches, all of these can OOM a Worker in production while looking fine in dev. Pre-stream where possible; use Cloudflare's Cache API and KV / R2 / D1 for everything else.

#2Pricing Snapshot (2026)

Cloudflare's "billed on CPU time, not wall time" is significant. If your Worker awaits an external API for 200 ms, you pay for the few ms of actual JavaScript execution, not the full 200 ms. This makes Workers structurally cheaper for I/O-heavy workloads (webhooks, proxies, fan-out).

Vercel charges per request, per bandwidth, per build, and per active user. The per-user pricing is the catch, a small team with high traffic is cheap; a large team with low traffic is expensive.

#2Platform-Specific Strengths

#3Cloudflare Workers, the Edge Operating System

What you get bundled:

• KV, eventually-consistent key-value at the edge
• R2, S3-compatible object storage, zero egress
• D1, SQLite at the edge, replicated globally
• Durable Objects, strongly-consistent, single-threaded actors for coordination
• Queues, at-least-once delivery message queue
• Vectorize, vector database for RAG/AI
• AI Gateway, proxy/caching for LLM calls

This is a coherent stack, not a collection of unrelated products. You can build a full application without leaving Cloudflare. The downside is lock-in: your Durable Objects don't run on Vercel.

#3Vercel, the Next.js Operating System

What you get bundled:

• Tight Next.js integration (preview deploys, ISR, on-demand revalidation)
• Vercel Postgres / KV / Blob (the storage primitives, hosted)
• Vercel AI SDK + AI Gateway
• Image optimisation as a first-class primitive
• Strong CI/CD ergonomics, git push to deploy with previews per branch

Vercel is the smoothest path from "I have a Next.js app" to "it's running globally." The trade-off is cost at scale and platform-coupling to Next.js patterns.

#3Deno Deploy, the Security-First Choice

What you get:

• Explicit permissions, code cannot reach network/env/disk unless granted (this is enforced at the runtime, not config)
• Native TypeScript with no build step
• Deno KV, strongly consistent, low-latency
• Deno.cron, built-in scheduled jobs
• Full Node.js compatibility via Deno 2.0, npm packages mostly work

For teams in regulated industries or teams that have been burned by a transitive npm dependency phoning home, Deno Deploy's permissions model is the strongest defence-in-depth available in the V8 isolate category.

#2The Hybrid Architecture Reality

The most important data point in 2026: 78% of engineering teams run hybrid architectures.

The winning pattern is workload-based placement:

• Edge (Cloudflare Workers): auth, routing, JWT verification, rate limiting, A/B test bucketing, header rewrites, content negotiation, geo-IP redirects
• Regional serverless (Vercel / AWS Lambda): SSR, business logic, transactional writes near the DB
• Containers (ECS / Fly / Render): stateful services, long-lived connections, gRPC servers, background workers
• Serverless cron (Deno.cron / EventBridge): scheduled jobs, retries, cleanup

This split cuts costs 30–48% vs. forcing everything onto one platform, because each layer gets the resource profile it actually needs.

#2A Concrete Selection Decision Tree

1. Is your app Next.js with heavy SSR? → Vercel.
2. Are you serving a global audience and primarily routing or auth? → Cloudflare Workers.
3. Do you need strict security defaults and explicit permissions? → Deno Deploy.
4. Are your users concentrated in one region and your DB lives there too? → Any regional platform is fine; pick on DX.
5. Are you running long-lived workloads (>15 min) or stateful services? → Don't use edge. Use containers (Fly, Render, Railway, ECS).
6. Do you need >4 GB RAM, GPU, or custom OS-level binaries? → Don't use any of these. Use a VM or managed Kubernetes.

#2Frequently Asked Questions

Q: Can I move from Vercel to Cloudflare Workers without rewriting? For pure API routes, usually yes, the Web Standards APIs (Request, Response, Headers) are portable. For Next.js SSR, no, Vercel's Next.js integration is the differentiator.

Q: Does Cloudflare Workers support npm packages? Increasingly yes, the node: built-ins (crypto, buffer, stream, util, path, etc.) work, and many npm packages run unmodified. Native-binding packages (bcrypt C bindings, sharp) do not. Look for pure-JS equivalents or compile to Wasm.

Q: What about WebAssembly on edge platforms? All three platforms support Wasm. Workers and Deno Deploy support WebAssembly.compile directly. Vercel Edge supports it too. Use Wasm for hot paths (image, crypto, parsing) where the JS performance is insufficient.

Q: How do I handle long-running tasks on edge platforms? You don't run them on edge. Push the task to a queue (Cloudflare Queues, AWS SQS, Upstash QStash) and have a container or batch worker process it. Edge is for short, latency-sensitive request handling, not for video transcoding.

Q: What about CORS at the edge? All three platforms let you set CORS headers from a single Worker / function. Centralising CORS in one edge layer is one of the cleanest patterns going, and you can verify the headers work with the CORS Header Checker.

Q: Cron jobs on each platform? Cloudflare: Cron Triggers (built into Workers). Vercel: Vercel Cron Jobs. Deno: native Deno.cron. Generate the schedule expression with the Cron Expression Generator, same syntax across all three.

Q: Do these platforms support WebSockets? Cloudflare Workers with Durable Objects: yes, strong support. Deno Deploy: yes. Vercel: limited, for production WebSockets, most Vercel users front their app with a separate WebSocket server (Pusher, Ably, or a container).

#2Closing

The "which edge platform is best" question has the wrong shape. By 2026 the platforms have converged enough on the runtime layer that the right question is which workload runs where.

Use Workers when latency, density, and I/O economics matter. Use Vercel when you live in Next.js and want the smoothest path from code to global. Use Deno when security defaults and explicit permissions are non-negotiable. And use containers or VMs when none of the three fit, because long-running, stateful, or large-memory workloads still don't belong on the edge.

The teams winning in 2026 aren't standardising on one platform. They're picking the right tool for each layer and accepting that "polyglot infrastructure" is the new normal.

Related: Server-Sent Events vs WebSockets vs Long Polling · Cron Expression Syntax Explained (50 Examples) · How to Test WebSocket Connections, 2026 Guide

Written by Rahul Jalavadiya, founder of AllDevToolsHub. All tools run locally in your browser.

#2Sources / Further reading

• Cloudflare - Workers documentation
• Deno - Deploy documentation
• Vercel - Edge Functions
• WinterCG - Web-interoperable Runtimes specification

#2Try These Tools

• Dns Lookup
• Http Request Builder