Serverless Edge Functions: Cloudflare Workers vs Vercel Edge vs Deno Deploy

Edge computing has moved from buzzword to production reality. Developers are shipping logic closer to users—not just assets—and the three major platforms for this are Cloudflare Workers, Vercel Edge Functions, and Deno Deploy. Each has a distinct philosophy, runtime model, and pricing structure.

This guide cuts through the marketing. We’ll look at what serverless edge functions actually are, how each platform differs, real performance characteristics, and a decision framework for choosing the right one for your use case.

---

What Are Edge Functions (vs Traditional Serverless)?

Traditional serverless functions (AWS Lambda, Google Cloud Functions) run in a single region by default. When a user in Tokyo hits your Lambda function in us-east-1, that request travels across the world, gets processed, and comes back. Cold starts add latency on top of geographic distance.

Edge functions run on a globally distributed network—the same infrastructure that CDNs use to cache static assets. Instead of routing to a central datacenter, requests hit the nearest point of presence (PoP) to the user. A Tokyo request gets handled in Tokyo.

The tradeoff: edge runtimes are intentionally constrained. You don’t get a full Node.js environment. Most platforms run a V8 isolate (not a full OS container), which means:

• No filesystem access (or read-only at best)
• No native modules compiled for Node.js
• Limited CPU time per request (typically 5–50ms)
• Restricted APIs — no require(), limited node: modules

What you do get: extremely fast cold starts (often sub-1ms), global distribution by default, and a programming model that feels like standard Web APIs (fetch, Request, Response, crypto).

Edge functions are best for:

• Request/response transformations (auth, headers, redirects)
• A/B testing and feature flags at the edge
• Geolocation-based routing or personalization
• API aggregation with low-latency requirements
• Bot detection and rate limiting before traffic hits your origin

They’re a poor fit for:

• Long-running background jobs
• Heavy computation (image processing, ML inference)
• Database-heavy operations that require connection pooling
• Code that depends on Node.js-specific APIs or native modules

---

Cloudflare Workers: Strengths, Limitations, Pricing

Cloudflare Workers is the oldest and most mature edge function platform. Launched in 2017, it runs on Cloudflare’s network of 300+ PoPs globally.

The Runtime Model

Workers runs V8 isolates—not containers, not VMs. Isolates are lightweight JavaScript contexts that share a V8 process. This is why cold starts are effectively zero (< 1ms). The tradeoff is strict isolation: no shared state between requests without using external storage like Workers KV or Durable Objects.

// workers/api-handler.js
export default {
  async fetch(request, env, ctx) {
    const url = new URL(request.url);

    if (url.pathname === '/api/user') {
      const userId = url.searchParams.get('id');

      // Workers KV for low-latency reads
      const userData = await env.USERS_KV.get(userId, 'json');

      if (!userData) {
        return new Response('Not found', { status: 404 });
      }

      return Response.json(userData, {
        headers: { 'Cache-Control': 'private, max-age=60' }
      });
    }

    return new Response('Not found', { status: 404 });
  }
};

Key Strengths

Network reach: 300+ PoPs means coverage in markets where competitors have none—Africa, Southeast Asia, Latin America. If your users are globally distributed, Cloudflare’s footprint is unmatched.

Workers KV: A globally replicated key-value store built for edge. Reads are served from the nearest PoP with near-zero latency. Writes propagate eventually (within seconds). Perfect for configuration, feature flags, and user preferences.

Durable Objects: The killer feature for stateful edge computing. Durable Objects give you strongly consistent, single-threaded coordination—you can build WebSocket servers, game servers, or collaborative tools entirely at the edge without an external database.

Workers AI: Run inference at the edge with built-in GPU access. Llama, Whisper, and other models available without leaving the Workers ecosystem.

Wrangler DX: The CLI tooling is excellent. Local development with wrangler dev mirrors production closely.

Limitations

• CPU time limit: 10ms per request on the free tier, 50ms on paid. For most API transformations this is fine; for anything compute-intensive, it’s not.
• No Node.js compatibility layer (by default): You need to use the nodejs_compat compatibility flag for some Node APIs. Many npm packages that use Node internals won’t work without modification.
• Bundle size limit: 1MB on free, 10MB on paid (compressed). Large dependencies can hit this.
• Debugging: Distributed tracing and debugging is harder than traditional Lambda.

Pricing

• Free: 100,000 requests/day, 10ms CPU per request
• Paid ($5/month): 10 million requests/month included, 50ms CPU, then $0.30 per million
• Workers KV: $0.50/million reads, $5/million writes (free tier: 100k reads/day)
• Durable Objects: $0.15/million requests + storage costs

For high-traffic use cases, Workers is often cheaper than alternatives. The free tier is generous enough for personal projects and testing.

---

Vercel Edge Functions: Next.js Integration, Use Cases

Vercel Edge Functions are tightly integrated with the Vercel deployment platform and particularly optimized for Next.js applications. They run on the same V8 isolate model as Workers but are designed to feel native within the Next.js mental model.

The Runtime Model

Vercel uses the same V8 isolate approach but adds their @vercel/edge SDK and tight integration with Next.js App Router and Pages Router conventions.

// app/api/personalize/route.ts (Next.js App Router)
import { NextRequest, NextResponse } from 'next/server';

export const runtime = 'edge';

export async function GET(request: NextRequest) {
  const country = request.geo?.country ?? 'US';
  const city = request.geo?.city ?? 'Unknown';

  // Fetch from origin with geolocation context
  const content = await getPersonalizedContent(country);

  return NextResponse.json({
    content,
    location: { country, city }
  }, {
    headers: {
      'Cache-Control': 's-maxage=60, stale-while-revalidate=300'
    }
  });
}

async function getPersonalizedContent(country: string) {
  // Example: return different pricing based on region
  const pricing = {
    US: { currency: 'USD', price: 99 },
    GB: { currency: 'GBP', price: 79 },
    DE: { currency: 'EUR', price: 89 },
  };
  return pricing[country] ?? pricing.US;
}

Middleware: The Sweet Spot

Vercel’s killer feature is middleware.ts—a special edge function that runs before every request, with access to the request and the ability to rewrite, redirect, or modify headers before the page renders.

// middleware.ts
import { NextRequest, NextResponse } from 'next/server';

export function middleware(request: NextRequest) {
  const { pathname } = request.nextUrl;

  // A/B testing at the edge
  if (pathname === '/landing') {
    const bucket = Math.random() < 0.5 ? 'a' : 'b';
    const url = request.nextUrl.clone();
    url.pathname = `/landing-${bucket}`;
    return NextResponse.rewrite(url);
  }

  // Auth check without hitting origin
  const token = request.cookies.get('auth-token');
  if (pathname.startsWith('/dashboard') && !token) {
    return NextResponse.redirect(new URL('/login', request.url));
  }

  return NextResponse.next();
}

export const config = {
  matcher: ['/landing', '/dashboard/:path*']
};

This middleware executes at the edge, before any server-side rendering, which means auth redirects and A/B tests add virtually zero latency.

Key Strengths

• Zero-config for Next.js: Add export const runtime = 'edge' to any route and it deploys as an edge function. No separate configuration files.
• Middleware: The most polished implementation of request-level edge logic in any platform.
• TypeScript first: Excellent types and IDE integration out of the box.
• Regional edge: You can specify regions for execution, useful when you need to colocate with a specific database.

Limitations

• Vercel lock-in: Edge Functions are tied to Vercel’s platform. Migrating to another host requires rewriting edge-specific code.
• Network is smaller than Cloudflare: ~100 PoPs vs Cloudflare’s 300+. Not a meaningful difference for most apps, but it matters for global coverage in underserved regions.
• No equivalent to Durable Objects: Vercel doesn’t offer edge-native stateful compute. You need an external database (Upstash, PlanetScale, Neon) for state.
• Pricing: Can get expensive at scale if you’re on a team plan. Edge function execution is included in most plans but has invocation limits.

Pricing

• Hobby (Free): 500,000 edge function invocations/month
• Pro ($20/user/month): 1,000,000 invocations/month included
• Enterprise: Custom pricing with higher limits

For Next.js teams already on Vercel, there’s no migration cost. For teams evaluating platforms, the Vercel ecosystem cost matters.

---

Deno Deploy: Deno Runtime, Fresh Framework

Deno Deploy is the cloud hosting product from the creators of Deno—Ryan Dahl’s second attempt at a JavaScript runtime, designed to fix the mistakes of Node.js. Deno Deploy runs Deno natively at the edge, which means TypeScript, Web APIs, and secure-by-default permissions are first-class citizens.

The Runtime Model

Unlike Workers and Vercel Edge, Deno Deploy runs actual Deno—not a stripped-down V8 isolate with limited APIs. You get:

• Native TypeScript (no compilation step, no ts-node)
• Web-standard APIs as the primary interface
• URL-based imports (import from any URL or from npm: specifier)
• Secure by default: explicit permission grants for network, filesystem, env

// main.ts (Deno Deploy)
import { serve } from "https://deno.land/[email protected]/http/server.ts";

const kv = await Deno.openKv(); // Built-in KV store

serve(async (req: Request) => {
  const url = new URL(req.url);

  if (url.pathname === "/api/visits") {
    const key = ["visits", url.hostname];
    const entry = await kv.get<number>(key);
    const count = (entry.value ?? 0) + 1;
    await kv.set(key, count);

    return Response.json({ visits: count });
  }

  return new Response("Hello from Deno Deploy!", {
    headers: { "content-type": "text/plain" }
  });
});

Fresh Framework

Fresh is Deno Deploy’s native web framework—built by the Deno team as the recommended way to build apps on Deno Deploy. It’s Islands architecture (React/Preact components are selectively hydrated), zero-build-step, and file-based routing.

// routes/[slug].tsx (Fresh)
import { Handlers, PageProps } from "$fresh/server.ts";

interface Post {
  title: string;
  content: string;
}

export const handler: Handlers<Post | null> = {
  async GET(req, ctx) {
    const { slug } = ctx.params;
    const post = await fetchPost(slug); // Runs at the edge
    return ctx.render(post);
  },
};

export default function PostPage({ data }: PageProps<Post | null>) {
  if (!data) return <div>Post not found</div>;

  return (
    <article>
      <h1>{data.title}</h1>
      <div dangerouslySetInnerHTML={{ __html: data.content }} />
    </article>
  );
}

Key Strengths

• Real Deno runtime: More capable than V8-only runtimes. Better TypeScript support, URL imports, and the full Deno standard library.
• Deno KV: A built-in, globally replicated key-value database that works the same locally and in production. No external service needed for simple state.
• npm compatibility: npm: specifiers let you use most npm packages without a separate install step.
• Open source friendly: Deno itself is MIT licensed. You can run your Deno app on your own infrastructure if needed.
• No vendor lock-in at the runtime level: Deno runs anywhere you can install it.

Limitations

• Smaller ecosystem: Compared to Node.js/npm, the Deno ecosystem is smaller. Most packages work via npm: imports, but not all.
• Smaller network: ~35 PoPs vs Cloudflare’s 300+. Meaningful gap for global coverage.
• Fresh is less mature: Great DX, but fewer resources, plugins, and community solutions than Next.js.
• Adoption: Deno Deploy has a smaller user base, which means less Stack Overflow answers and community plugins.

Pricing

• Free: 100,000 requests/day, 10ms CPU
• Pro ($10/month): 5,000,000 requests/month, custom domains, more CPU time
• Business ($20/month): Higher limits, team features

Pricing is competitive with the others for most use cases.

---

Performance Benchmarks: Cold Start, Latency

Cold start times are where all three platforms converge on “negligible” for most workloads. The V8 isolate model means JavaScript contexts start in microseconds, not seconds.

Platform	Cold Start (typical)	P95 Latency (global)	PoPs
Cloudflare Workers	< 1ms	~10ms	300+
Vercel Edge	< 5ms	~15ms	~100
Deno Deploy	< 5ms	~20ms	~35

These numbers are generalizations from public benchmarks and community testing. Actual performance depends on:

• Bundle size (larger = slightly slower initialization)
• Geographic distribution of your users
• Complexity of your edge function logic
• Whether you’re hitting KV/external databases (dominates latency)

For P50 latency in North America and Western Europe, the differences are imperceptible. Cloudflare has a meaningful advantage for users in Africa, Southeast Asia, and South America due to PoP coverage.

For applications where the edge function itself does significant work (parsing, transformation, calling external APIs), the CPU time limits matter more than cold start time.

---

When to Use Each Platform

Choose Cloudflare Workers when:

• Your users are globally distributed, especially in underserved regions
• You need Durable Objects for stateful edge compute (WebSockets, coordination)
• You want the most cost-efficient pricing at high request volumes
• You’re not on Vercel and don’t want the ecosystem dependency
• You need Workers KV for low-latency configuration/feature flags
• You want maximum control over the edge runtime

Choose Vercel Edge Functions when:

• You’re already using Vercel to deploy Next.js
• You want A/B testing and personalization through middleware.ts
• TypeScript-first DX with Next.js is a priority
• You need geolocation-based routing or personalization built into your Next.js app
• Your team values convention over configuration

Choose Deno Deploy when:

• You want to use TypeScript without a build step
• You prefer the Deno runtime’s security model and Web API compatibility
• You’re building a greenfield project and want to avoid Node.js baggage
• You want a simpler mental model with native KV included
• You’re experimenting with Fresh framework for Islands architecture
• You want an open-source runtime that isn’t locked to a cloud vendor

Use None of the Above when:

• Your function runs longer than 50ms of CPU time
• You need native Node.js modules or file system access
• You’re doing heavy computation (ML inference, video encoding)
• You need a persistent database connection (use Lambda + RDS Proxy instead)

---

Migration Considerations

From Lambda/Cloud Functions to Edge

The biggest migration challenge is the runtime constraint. Audit your existing functions for:

1. Node.js-specific APIs: process, fs, path, child_process — none of these work in V8 isolates without polyfills.
2. Native modules: Compiled .node files won’t run. Replace with pure JS alternatives.
3. Long-running operations: Edge functions have strict CPU limits. Anything over 50ms needs to move to a traditional serverless function or background job.
4. Database connections: Most traditional databases (PostgreSQL, MySQL) expect persistent connections. Use HTTP-based APIs (Neon serverless driver, PlanetScale serverless, Upstash Redis) at the edge.

Switching Between Edge Platforms

Each platform has slightly different APIs and conventions. Abstracting behind a thin wrapper helps:

// lib/edge-utils.ts (platform-agnostic helpers)
export function getGeoInfo(request: Request) {
  // Cloudflare Workers
  if ('cf' in request) {
    const cf = (request as any).cf;
    return { country: cf.country, city: cf.city };
  }

  // Vercel Edge / Next.js
  const country = request.headers.get('x-vercel-ip-country');
  const city = request.headers.get('x-vercel-ip-city');
  if (country) return { country, city };

  // Deno Deploy / generic
  const cfCountry = request.headers.get('cf-ipcountry');
  return { country: cfCountry ?? 'unknown', city: null };
}

Testing Locally

All three platforms have local development options:

• Cloudflare: wrangler dev — best local emulation, uses real V8 isolate
• Vercel: vercel dev or next dev — good emulation for middleware/routes
• Deno Deploy: deno run locally — runs the exact same Deno runtime

---

Making the Decision

If you’re deploying on Vercel with Next.js, use Vercel Edge Functions. The zero-config experience and middleware integration are worth more than theoretical performance differences.

If you need maximum global coverage, stateful edge compute, or cost efficiency at scale, use Cloudflare Workers. The ecosystem around Workers (KV, Durable Objects, R2, AI) is the most mature.

If you’re starting fresh, prefer Deno’s runtime model, or want to avoid Node.js complexity, try Deno Deploy. The DX is excellent and the runtime is genuinely good—the main limitation is network coverage.

All three are production-ready. The differences that matter are organizational (what platform is your team already on?) and use-case-specific (do you need Durable Objects? Do you have users in Southeast Asia?).

---

Ready to test edge functions? Check out the DevPlaybook tools collection for live testing environments and developer utilities that run on edge infrastructure.