Edge Functions Explained

The runtime architectures

Edge function platforms split into three execution models. The model determines cold-start cost, isolation properties, and what code can run.

V8 Isolates (Cloudflare Workers, Vercel Edge, Deno Deploy)

V8 — the JavaScript engine from Chrome — supports running multiple isolated execution contexts within a single process. Each function runs in its own Isolate but shares the V8 runtime. The result: function startup is nearly free (parse JS, create Isolate — under 5 ms). Memory and CPU isolation are JavaScript-level, not OS-level.

Trade-offs:

• Zero cold start.
• Very high density — thousands of functions per machine.
• JavaScript and WebAssembly only. No native code, no filesystem, no arbitrary system calls.
• Security via V8 sandbox — well-understood but not VM-strength.

Container/VM-based (Lambda@Edge, Lambda)

Each invocation runs in its own container or microVM (Firecracker). Strong OS-level isolation. Cold starts of 50-500 ms because containers must boot.

Trade-offs:

• Cold starts are visible in latency.
• Any language with a Linux runtime — Node, Python, Go, Rust, custom containers.
• Full filesystem (read-only on Lambda@Edge), subprocesses, system calls.
• Higher cost per invocation due to container management overhead.

WebAssembly (Fastly Compute@Edge)

WebAssembly module compiled ahead of time and instantiated per request. Cold starts in the low milliseconds range (between V8 Isolates and containers). Language support depends on which languages compile to Wasm: Rust, AssemblyScript, Go, Swift, C, C++.

Trade-offs:

• Very fast cold starts.
• Strong isolation via Wasm sandbox.
• Polyglot, but in practice biased toward Rust.
• WASI (Wasm system interface) provides limited but standard system access.

Platform comparison

Resource limits

Edge platforms enforce tight limits. Common caps in 2026:

The Cloudflare Workers ecosystem

Workers is the most mature and widely-adopted edge function platform. Key features:

• Workers KV. Eventually-consistent global key-value store. Reads in 10-50 ms globally; writes propagate in seconds.
• D1. SQLite at the edge. Strongly consistent within a region; eventual across regions.
• Durable Objects. Strongly-consistent single-instance state. Each object lives in one region (chosen based on first-access location); all reads/writes serialize through it. Pattern: per-user state, real-time collaboration, game session state.
• R2. S3-compatible object storage with zero egress fees.
• Queues, Cron Triggers, Email Workers, AI — many adjacent products.

The pricing: 100K requests/day free, then $0.50/M requests. Plus CPU time charges on the paid plan ($0.02 per million CPU-ms).

The Vercel Edge ecosystem

Vercel's edge runtime is V8 Isolates branded as Edge Functions. Tightly integrated with Next.js and other frontend frameworks:

• Edge Config. Ultra-low-latency reads (sub-15 ms) for config-like data. Limited writes.
• Vercel KV. Redis-compatible at the edge.
• Edge Middleware. Runs before every request in a Next.js app — useful for auth, A/B, redirects.
• Streaming SSR. Render React Server Components with streaming HTML at the edge.

Vercel pricing bundles edge execution into the platform's tiered plan rather than per-invocation billing.

The AWS edge ecosystem

AWS has two distinct edge compute products:

Lambda@Edge

Container-based, full Lambda runtime. Can be triggered at four points: viewer request, viewer response, origin request, origin response. The viewer hooks run at edge POPs; origin hooks run at regional caches. Lambda@Edge supports Node.js and Python.

Trade-offs: cold starts are visible (50-500 ms). Best for tasks that justify the runtime — complex auth, large response transforms, integration with other AWS services.

CloudFront Functions

A lightweight alternative for simple JavaScript transformations. Limited to viewer hooks. Sub-millisecond cold start. ES5.1 subset of JavaScript only — no async/await, no modules, no fetch. Designed for fast simple things: URL rewriting, header manipulation, geo-redirects.

What runs well at the edge

• Authentication and authorization. Validate JWTs, check IP allowlists, terminate mTLS, refuse unauthorized requests before reaching origin.
• A/B testing and feature flags. Route different users to different experiences without changing origin code.
• Request normalization and routing. Rewrite URLs, strip tracking params, normalize headers, route to backends by host or path.
• Geo-personalization. Set currency, language, regional redirects from request country headers.
• Edge SSR. Server-render HTML with streaming, especially for React Server Components and similar streaming frameworks.
• HTML rewriting. Inject analytics tags, modify meta tags, transform responses on the fly (Cloudflare HTMLRewriter is purpose-built for this).
• API gateway. Rate limiting, request validation, response shaping for downstream APIs.
• Lightweight middleware. Logging, metrics emission, tracing for requests that don't otherwise need origin processing.

What runs poorly at the edge

• Heavy ML inference. Even small models exceed CPU budgets. Use dedicated inference endpoints.
• Long-running operations. Anything over 30 seconds. Streaming generation is fine (uses wall-clock time, not CPU time, on most platforms), but pure compute over 30 sec is not.
• Database queries to a single region. The round-trip cost negates the edge benefit. Either replicate the database globally or run logic at origin.
• Image and video processing. CPU- and memory-intensive. Edge platforms have dedicated image-optimization products; use those instead of running your own.
• File uploads beyond a few MB. Many edge platforms cap request body size strictly. For uploads, use direct-to-storage signed URLs.
• Workloads with large native dependencies. Anything requiring a specific binary, native crypto library, or C library that doesn't compile to Wasm.

Cold-start anatomy

For V8 Isolates the cold start is bounded by:

1. Receiving the request at the POP.
2. Looking up which function to invoke (a hashmap lookup).
3. If the Isolate is already warm (recent invocation), execute immediately.
4. If cold, parse the function's JavaScript and instantiate the Isolate (typically 1-3 ms).
5. Execute the handler.

Total cold-start contribution: 0-5 ms. Container-based platforms add 50-500 ms to step 4. The user latency difference is real and visible.

The portability question

Edge function APIs are partially standardized around the Web Platform — Fetch API, Request/Response, Headers, URL, ReadableStream. Code written against these APIs ports reasonably between Cloudflare Workers, Vercel Edge, and Deno Deploy.

Where portability breaks:

• State stores are platform-specific (Workers KV vs Vercel KV vs DynamoDB).
• Bindings and environment access differ.
• Build tooling and deploy mechanisms differ.
• Cron triggers, queues, durable objects are platform-specific abstractions.

For a thin auth/rewriting layer, portability is achievable. For an application that uses edge state and platform features, you commit to a platform.

Frequently Asked Questions

What is a V8 Isolate and why does it matter for edge functions?

A V8 Isolate is a sandboxed JavaScript execution context within a single V8 process. Cloudflare Workers (and most modern edge platforms) run hundreds of customer functions in one V8 process, isolated at the JavaScript level rather than via containers or VMs. This eliminates cold-start costs — starting a new Isolate takes under 5 ms vs. 50-500 ms for a container. The trade-off is that the runtime is JavaScript/WebAssembly only; no native code, no system access.

Which edge function platform has the most POPs?

Cloudflare Workers runs in 300+ POPs across 120+ countries — the largest edge function footprint in 2026. Lambda@Edge runs in 13 regional caches plus 600+ CloudFront edge locations (with smaller compute capability). Vercel Edge runs in 18+ regions. Deno Deploy runs in 35+ regions. The POP count matters when targeting global users, but quality of POP placement matters more than raw count.

Can I use Node.js packages in edge functions?

Partially. Most edge platforms support a subset of Node.js APIs as "Node compatibility mode" but exclude packages that require native modules, filesystem access, or Node-specific runtime features. Cloudflare Workers added node:* import support in 2024 with broad coverage. Vercel Edge and Deno Deploy support web standard APIs natively. Pure-JavaScript packages with no native dependencies usually work; packages that touch the filesystem, run subprocesses, or use Node's net/http internals do not.

What is the typical cold start time for an edge function?

Cloudflare Workers and other V8-Isolate-based platforms have effectively zero cold start — startup is under 5 ms even for cold workers. Lambda@Edge and Lambda are container-based and have 50-500 ms cold starts depending on memory allocation and runtime. Vercel Edge uses V8 Isolates and matches Workers' near-zero cold start. The cold-start gap is the biggest single performance differentiator between edge platforms.

How do I share data between edge function invocations?

Each invocation is stateless by default. For shared data, edge platforms provide eventually-consistent global key-value stores: Cloudflare KV (read in under 50 ms globally), Cloudflare D1 (SQLite at the edge), Cloudflare Durable Objects (strongly consistent state), Vercel KV / Edge Config, AWS DynamoDB Global Tables. Each has different consistency, latency, and pricing trade-offs. For frequently-changing data needing low latency, Durable Objects or DynamoDB Global Tables; for read-heavy data tolerating eventual consistency, KV is cheapest and fastest.