What is Edge Runtime?

What is Edge Runtime?

Edge Runtime is a lightweight JavaScript execution environment that runs server-side code at CDN points of presence (PoPs) geographically close to the end user, rather than in a single origin region. Unlike traditional serverless functions that spin up in one or a few data center regions, edge runtimes distribute compute across dozens or hundreds of locations worldwide. Cloudflare Workers (launched 2017) popularized the model, and Vercel introduced its Edge Runtime for Next.js middleware in v12 (October 2021). These environments use a V8 isolate model instead of full Node.js containers, which means cold starts under 5ms but a restricted API surface — no native Node.js modules like fs, net, or child_process.

I've shipped edge runtimes on 50+ projects. They're good for authentication checks, geolocation-based routing, A/B testing, and personalized cache keys where sub-50ms TTFB matters. Not much else.

How it works

Edge runtimes use V8 isolates — the same engine that powers Chrome — rather than full OS-level containers. Each incoming request spins up an isolate (or reuses a warm one) inside a shared process. This is fundamentally different from AWS Lambda's container model.

The execution model is closer to the Web Workers API than to Node.js. You get fetch, Request, Response, URL, TextEncoder, crypto.subtle, and a handful of other Web Platform APIs. You don't get the full Node.js standard library.

Here's what a basic edge function looks like in Next.js (App Router, as of Next.js 15):

// app/api/geo/route.ts
export const runtime = 'edge';

export async function GET(request: Request) {
  const country = request.headers.get('x-vercel-ip-country') || 'US';
  return Response.json({
    message: `Serving from the edge, detected country: ${country}`,
    timestamp: Date.now(),
  });
}

The key line is export const runtime = 'edge'. That single declaration tells the framework to bundle and deploy this route to edge locations instead of a regional Node.js serverless function.

Under the hood, providers like Cloudflare (300+ PoPs), Vercel (via Cloudflare's network), and Deno Deploy (35+ regions) receive the request at the nearest PoP, execute your code there, and return the response — often achieving TTFB under 50ms globally. The trade-off is strict memory limits (typically 128MB), CPU time limits (usually 10-50ms of wall-clock CPU), and no persistent filesystem.

When to use it

Edge Runtime is a precision tool, not a default. Here's when it actually makes sense:

Use it when:

• You need to modify requests/responses before they hit the origin (auth token validation, redirects, header injection)
• Geolocation-based logic like currency/language selection or regional compliance blocking
• A/B test assignment where you need to set cookies before the page renders
• Personalized cache key generation to get the best of CDN caching + personalization
• Lightweight API endpoints that return small JSON payloads from edge-compatible datastores (e.g., Upstash Redis, Turso, Cloudflare D1)

Don't use it when:

• You need native Node.js APIs (file system, TCP sockets, heavy crypto)
• Your function calls a database in a single region anyway — you'll add latency by running compute far from data
• CPU-intensive work like image processing or PDF generation exceeds edge CPU limits
• You're importing large npm packages that aren't edge-compatible

The single-region-database problem is the most common mistake I see. Running code at the edge that then makes a 200ms round-trip to a database in us-east-1 defeats the purpose entirely. You've just added network hops for nothing.

Edge Runtime vs alternatives

My preferred stack: Edge Runtime for middleware and lightweight API routes in Next.js, regional serverless for anything that talks to a database, and long-running servers only when I need WebSockets or heavy background processing.

Real-world example

On a recent e-commerce project built with Next.js 15, I used Vercel Edge Middleware to handle three things before any page rendered: (1) detect the visitor's country via the x-vercel-ip-country header and rewrite to the correct locale, (2) check for an existing A/B test cookie and assign a variant if missing, and (3) validate a JWT session token against Upstash Redis to decide whether to show authenticated or guest pricing.

All three operations completed in under 12ms p95 globally. The same logic running as a regional serverless function in us-east-1 had a p95 of 180ms for users in Asia-Pacific. That latency difference directly improved Largest Contentful Paint by roughly 150ms for international traffic — meaningful for both Core Web Vitals and conversion rates.