Supported Web APIs in Edge Runtimes

This guide is part of Edge Runtime Fundamentals & Platform Constraints.

Edge runtimes deliberately restrict the API surface to WHATWG-compliant browser primitives. The rationale is portability and determinism: by running on a curated subset of the same APIs browsers expose, isolates can be pre-compiled, snapshotted, and deployed globally without OS-level dependencies. What you gain in cold-start speed and geographic distribution, you pay for in API surface reduction. Because each platform builds its V8 isolate on a different base — V8 directly for Cloudflare and Vercel, Deno for Netlify — the available surface diverges in ways that break code which passes locally but fails in production.

This guide maps what is and is not available across the three major edge platforms, with accurate constraint figures as of mid-2026.

Universal API Surface

All major edge runtimes (Cloudflare Workers, Vercel Edge Middleware, Netlify Edge Functions) support:

Absent everywhere: fs, net, tls, child_process, path, os, http (Node.js module), Buffer (Node.js), process.exit, synchronous I/O, raw TCP sockets, WebAssembly compilation at request time (pre-compiled WASM modules can be instantiated).

Provider-Specific Constraints

Runtime Constraint Thresholds

Provider Callouts

Cloudflare Workers: Zero Node.js globals by default. Enable nodejs_compat in wrangler.toml to access Buffer, process, stream, and a subset of crypto. Database drivers must use HTTP-based or native bindings (D1, Hyperdrive). The Cache API (caches.default) is fully functional. URLPattern is supported.

Vercel Edge Middleware: Runs inside the Next.js edge runtime. cookies() and headers() helper functions from next/headers are available only in Server Components and Route Handlers, not in middleware.ts. In middleware.ts use req.cookies and direct header manipulation. The runtime exposes path and url from Node.js as partial shims; avoid fs and net even if they appear resolvable locally.

Netlify Edge Functions: Deno-based runtime. Imports use URL-style or npm: specifiers. The context.next() and context.rewrite() methods are Netlify-specific extensions. Automatic redirect handling in fetch is enabled by default. The Deno standard library is accessible but adds to bundle size.

How the Runtime Decides What Exists

The useful mental model is that an edge runtime is not Node with modules removed. It is a fresh global scope assembled from a fixed list of constructors and then frozen into a snapshot that gets cloned per request. Nothing resolves an identifier by walking a filesystem at request time, so there is no lazy loading and no module cache to patch after the fact. Either a global was installed when the isolate was built, or it does not exist at all. That is why the failure mode is an abrupt ReferenceError: Buffer is not defined, or a module-resolution error thrown during script evaluation before your handler ever runs, rather than a graceful undefined you could feature-detect around at leisure.

Two knobs move that boundary, and both are set outside your application code. On Cloudflare, compatibility_date and compatibility_flags in wrangler.toml select which snapshot your script runs against; adding nodejs_compat installs a curated subset of node: modules into the global scope before the snapshot is taken. On Vercel, the shim layer is fixed per runtime version and cannot be extended from your project — the surface you get is whatever the deployment ships with. Netlify resolves node: specifiers through Deno’s own compatibility layer, which is why an import that throws on Workers can succeed there unchanged, and why “it works on Netlify” is not evidence that a dependency is edge-safe.

The awkward part is that none of this is visible to your bundler. esbuild and webpack resolve node:crypto happily, and depending on platform and conditions settings they may substitute a browser shim, drop the import entirely, or inline a polyfill that silently produces wrong output — a randomBytes shim backed by Math.random() is the classic example, and it produces predictable “random” tokens with no error anywhere. The build stays green, the upload succeeds, and the first production request is where the gap surfaces.

The most reliable probe is a typeof check executed inside the deployed isolate — not in your editor, and not in local dev. A throwaway diagnostic route that returns typeof URLPattern, typeof Buffer, typeof process, and the runtime’s navigator.userAgent for the exact deployment you are debugging settles compatibility arguments in seconds, and it is the only answer that accounts for your compatibility date, your flags, and your bundler’s substitutions at the same time.

Streaming Responses Without Buffering

import { NextResponse } from 'next/server';

export async function GET(request: Request) {
  const externalRes = await fetch('https://api.example.com/data-stream');

  if (!externalRes.ok || !externalRes.body) {
    return new Response('Upstream failed', { status: 502 });
  }

  // Stream body directly; inject cache headers
  const headers = new Headers(externalRes.headers);
  headers.set('Cache-Control', 'public, max-age=300, stale-while-revalidate=600');
  headers.delete('Content-Length'); // Required when streaming

  return new Response(externalRes.body, {
    status: externalRes.status,
    headers,
  });
}

Never buffer an entire response body into memory when you can stream it. Buffering a 50 MB response on a platform with a 128 MB memory cap will trigger an OOM kill.

Cryptographic Operations

The Node.js crypto module is absent. Use crypto.subtle for all signing, verification, and hashing operations:

async function verifyPayloadSignature(
  payload: ArrayBuffer,
  signature: Uint8Array,
  key: CryptoKey
): Promise<boolean> {
  try {
    return await crypto.subtle.verify(
      { name: 'HMAC', hash: { name: 'SHA-256' } },
      key,
      signature,
      payload
    );
  } catch (err) {
    // Fail closed: abort on any verification error
    throw new Error('Signature verification failed', { cause: err });
  }
}

Import CryptoKey objects via crypto.subtle.importKey; do not pass raw strings as secrets. Use crypto.subtle.digest for hashing and crypto.subtle.sign/verify for HMAC and RSA operations.

Worked Example: Porting a Signed Webhook Handler

A webhook receiver is the densest concentration of Node-only APIs in a typical codebase, which makes it the clearest port to walk through. The Node version usually reaches for four things the edge does not have: crypto.createHmac to recompute the signature, Buffer.from(sig, 'hex') to decode the header, crypto.timingSafeEqual for the comparison, and often fs.readFileSync or process.env loaded from a .env file to obtain the shared secret. Every one of them has an edge-native counterpart, and the result is shorter than the original.

// Edge-native webhook verification — no node: imports
const HEX = /^[0-9a-f]+$/i;

function hexToBytes(hex: string): Uint8Array {
  if (hex.length % 2 !== 0 || !HEX.test(hex)) throw new Error('malformed signature');
  const out = new Uint8Array(hex.length / 2);
  for (let i = 0; i < out.length; i++) {
    out[i] = parseInt(hex.substr(i * 2, 2), 16);
  }
  return out;
}

export async function handleWebhook(req: Request, secret: string): Promise<Response> {
  const header = req.headers.get('x-signature');
  if (!header) return new Response('missing signature', { status: 401 });

  // Read the body exactly once, as bytes — not text, to avoid re-encoding drift
  const body = await req.arrayBuffer();

  const key = await crypto.subtle.importKey(
    'raw',
    new TextEncoder().encode(secret),
    { name: 'HMAC', hash: 'SHA-256' },
    false,          // non-extractable: the key cannot be read back out
    ['verify']
  );

  let ok = false;
  try {
    ok = await crypto.subtle.verify('HMAC', key, hexToBytes(header), body);
  } catch {
    ok = false;    // malformed hex is an invalid signature, not a 500
  }

  if (!ok) return new Response('invalid signature', { status: 401 });
  return new Response(null, { status: 202 });
}

Three details in that port are easy to get wrong. First, the body must be read as an ArrayBuffer, not with .text() — decoding to a JS string and re-encoding it changes the bytes whenever the payload contains characters outside the ASCII range or a lone surrogate, and the HMAC then fails for a subset of legitimate requests that is maddening to reproduce. Second, crypto.subtle.verify already compares in constant time, so timingSafeEqual has no replacement because it has no job; if you ever do need to compare two digests yourself, XOR-accumulate across the full length and check the accumulator once rather than returning early on the first mismatched byte. Third, importKey is not free — it costs real CPU on every invocation, and on Cloudflare that lands inside the synchronous CPU budget. Hoist it to module scope keyed by secret only if the secret is genuinely static for the isolate’s lifetime, and remember that module scope is shared across requests in the same isolate, so never cache anything request-specific alongside it.

The secret itself arrives through a platform binding — env.WEBHOOK_SECRET on Cloudflare, process.env.WEBHOOK_SECRET inlined at build time on Vercel — and never from disk. This is one of the places where the missing filesystem is a feature: there is no code path that can accidentally read a secret out of a bundled file that shipped to a PoP.

Structured Logging & Correlation IDs

Edge environments typically strip stack traces. Use structured JSON with a correlation ID generated at request entry:

export async function middleware(request: Request) {
  const correlationId = crypto.randomUUID();
  const start = performance.now();

  try {
    const response = await handleRequest(request);
    console.log(JSON.stringify({
      level: 'info',
      correlationId,
      path: new URL(request.url).pathname,
      latencyMs: (performance.now() - start).toFixed(2),
      status: response.status,
    }));
    return response;
  } catch (err) {
    console.error(JSON.stringify({
      level: 'error',
      correlationId,
      message: err instanceof Error ? err.message : 'unknown',
    }));
    return new Response('Service Unavailable', { status: 503 });
  }
}

CI Compatibility Testing

Run a matrix against all target runtimes as part of CI. The most practical check is a static bundle audit that flags node: prefixed imports and globals (process, Buffer, require) that edge runtimes do not expose:

# Audit bundle for edge-incompatible imports
npx esbuild src/edge-handler.ts --bundle --analyze --outfile=/dev/null 2>&1 | grep -E "(node:|Buffer|process\.env)"

For per-provider deployment configuration and polyfill management, see Polyfill Strategies for Node.js APIs at the Edge and Managing Cold Starts in Serverless Environments.

Edge Cases That Only Surface in Production

A handler can use nothing but supported APIs and still misbehave, because several of those APIs behave differently inside an isolate than they do in a browser or in Node. These are the ones that reach production most often.

The clock does not advance during synchronous work. Cloudflare Workers hold Date.now() — and the coarsened performance.now() — steady until the isolate performs I/O, as a timing side-channel mitigation. A loop that measures its own duration reports 0. The structured-logging example above works only because the measurement spans an await on a real network call; a purely computational span will always read zero, and CPU time has to come from platform observability rather than from inside the handler.

Work you do not await is cancelled. Returning a Response ends the request. A fetch to an analytics endpoint fired without await, or a setTimeout scheduled just before the return, is discarded when the invocation completes — usually silently, which is why “our edge logs only capture some events” is such a common report. Every platform exposes the same escape hatch under a different name: ctx.waitUntil() on Cloudflare, event.waitUntil() on Vercel, context.waitUntil() on Netlify. The promise you hand it keeps the invocation alive after the response has been flushed to the client.

Request and response bodies are single-use. await req.text() consumes the stream; passing that same req to fetch afterwards throws. Call req.clone() before reading if the handler both inspects and forwards a body, and be aware that cloning forces the runtime to buffer whatever the slower consumer has not read yet, which puts the memory cap back in play for large uploads.

atob and btoa operate on binary strings, not bytes. Round-tripping UTF-8 through them corrupts any payload containing non-ASCII characters. Decode with atob into a Uint8Array by char code, then hand that array to TextDecoder; going straight from atob to a string is the source of most mangled JWT payload claims at the edge.

Response headers from fetch may be immutable. Mutating response.headers directly on an upstream response throws in several runtimes. Re-wrap instead — new Response(res.body, res) gives you a mutable Headers instance over the same stream, which is exactly what the streaming example above relies on.

Subrequest budgets are finite. Each invocation is allowed a bounded number of outbound fetch calls (50 on Cloudflare’s free plan, 1000 on paid), and a fan-out loop over an array of IDs will exhaust that budget long before it exhausts the wall clock. Batch upstream reads, or move the fan-out to a serverless function where the limits are different.

Auditing API Compatibility Before Deploy

Run this workflow to confirm a handler stays inside the supported surface before it ships:

1. Inventory the dependency tree. Resolve every transitive import and flag any package that pulls in node:-prefixed modules or references process, Buffer, or require.
2. Map each flagged API to a Web equivalent. Replace crypto.createHash with crypto.subtle.digest, Buffer with Uint8Array + TextEncoder, and node-fetch with native fetch.
3. Run a static bundle audit in CI. Use esbuild --analyze and grep for incompatible tokens so the build fails fast rather than at the first production request.
4. Validate streaming paths. For any response over a few kilobytes, confirm the body is piped through ReadableStream rather than buffered into memory.

# Audit bundle for edge-incompatible imports
npx esbuild src/edge-handler.ts --bundle --analyze --outfile=/dev/null 2>&1 | grep -E "(node:|Buffer|process\.env)"

Runtime Compatibility Checklist

• No node:-prefixed imports remain in the bundled output.
• All hashing, signing, and verification use crypto.subtle, not the Node crypto module.
• Responses larger than a few kilobytes stream via ReadableStream instead of buffering.
• URLPattern usage is gated behind a feature check where the target platform may lack it.
• Any Node compatibility shim (nodejs_compat, @vercel/edge) is explicitly enabled in config.
• A CI bundle audit fails the build on disallowed globals.

Frequently Asked Questions

Conclusion

The API surface restriction is the defining constraint of edge runtimes. Before writing any edge function, audit your dependency tree for Node.js built-ins, identify which operations require WebCrypto equivalents, and validate streaming compatibility for any payload above a few kilobytes. The payoff—sub-10 ms isolate initialization and global PoP distribution—is only realized when the code respects the boundaries the platform was built around.

Related

• Edge Runtime Fundamentals & Platform Constraints
• Vercel Edge Runtime vs Cloudflare Workers
• Polyfill strategies for Node.js APIs at the edge
• Memory and CPU limits across edge providers
• When to use edge vs serverless functions for API calls