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.

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.

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.

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: No `node:`-prefixed imports remain in the bundled output.
• All hashing, signing, and verification use crypto.subtle, not the Node crypto All hashing, signing, and verification use `crypto.subtle`, not the Node `crypto` module.
• Responses larger than a few kilobytes stream via ReadableStream Responses larger than a few kilobytes stream via `ReadableStream` instead of buffering.
• URLPattern `URLPattern` usage is gated behind a feature check where the target platform may lack it.
• Any Node compatibility shim (nodejs_compat, @vercel/edge 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