Memory and CPU Limits Across Edge Providers

Edge runtimes impose hard resource boundaries enforced at the JavaScript engine level, not the OS level. Exceeding memory causes an immediate OOM kill. Exceeding the CPU budget (where one exists) triggers a hard timeout error. Neither condition produces a graceful error page—the platform returns a 502 or 503 to the client. Understanding exactly where each provider draws those lines is a prerequisite for capacity planning.

This guide is part of Edge Runtime Fundamentals & Platform Constraints. It maps the two ceilings every edge workload must respect — resident memory and synchronous CPU time — across all three major providers.

Provider Limits

Cloudflare Workers

• Memory: 128 MB per isolate (hard cap)
• CPU: 10 ms synchronous CPU per request on the free tier; 30 s by default on the Workers Paid plan, configurable up to 5 minutes. I/O wait (outbound fetch, KV reads, DO calls) does not consume this budget.
• Wall-clock: 30 s
• Bundle size: 1 MB uncompressed script

The CPU budget is the defining constraint. A synchronous SHA-256 hash of a 10 MB buffer, or a regex evaluated against a large string, can exhaust 10 ms without any network I/O. Exceeding the CPU quota returns a Worker threw exception error (Cloudflare error code 1101). For the diagnostic and remediation workflow specific to this failure, see avoiding CPU time-limit errors in Cloudflare Workers.

Vercel Edge Middleware

• Memory: 128 MB per invocation (hard cap)
• CPU: No separate CPU time budget; wall-clock limit applies
• Wall-clock: 1000 ms for middleware.ts
• Bundle size: 1 MB uncompressed

Vercel does not enforce a separate synchronous CPU limit. The 1000 ms wall-clock includes all computation and I/O. This is more permissive than Cloudflare for CPU-bound operations but less permissive for long-running I/O chains.

Netlify Edge Functions

• Memory: 512 MB per invocation
• CPU: No separate CPU budget
• Wall-clock: 50 s
• Bundle size: 20 MB

Netlify’s Deno-based runtime is the most permissive in terms of memory and execution time, making it a reasonable choice for transformation-heavy middleware that cannot be offloaded to origin. For a focused breakdown of the 128 MB versus 512 MB difference and the distinct OOM signatures, see comparing memory limits: Netlify vs Vercel Edge.

Summary Table

Streaming to Avoid OOM

Buffering large payloads is the most common cause of OOM kills on 128 MB platforms. Use TransformStream to process data in chunks and flush immediately:

export async function edgeHandler(request: Request): Promise<Response> {
  const startTime = performance.now();

  const response = await fetch('https://api.origin/data');
  if (!response.ok || !response.body) {
    return new Response('Upstream failed', { status: 502 });
  }

  // Reject payloads that would exceed safe memory headroom
  const contentLength = response.headers.get('content-length');
  if (contentLength && parseInt(contentLength, 10) > 80 * 1024 * 1024) {
    return new Response('Payload exceeds edge memory budget', { status: 413 });
  }

  // Stream without buffering; enforce a wall-clock guard per chunk
  const transformStream = new TransformStream({
    transform(chunk, controller) {
      if (performance.now() - startTime > 900) {
        // Approaching wall-clock limit; abort the stream
        controller.error(new Error('Execution budget approaching limit'));
        return;
      }
      controller.enqueue(chunk);
    },
  });

  return new Response(response.body.pipeThrough(transformStream), {
    headers: response.headers,
  });
}

Lazy Module Loading

Static top-level imports parse and compile at isolate initialization time. Deferred import() avoids this overhead for code paths that are rarely hit:

type HeavyProcessor = { process: (data: ArrayBuffer) => Promise<Uint8Array> };

let processorInstance: HeavyProcessor | null = null;
let initPromise: Promise<HeavyProcessor> | null = null;

export async function getProcessor(): Promise<HeavyProcessor> {
  if (processorInstance) return processorInstance;

  if (!initPromise) {
    initPromise = (async () => {
      try {
        const { HeavyProcessor } = await import('./heavy-processor');
        processorInstance = new HeavyProcessor();
        return processorInstance;
      } catch (error) {
        initPromise = null; // Allow retry on transient failures
        throw error;
      }
    })();
  }

  return initPromise;
}

For the relationship between module size and cold-start latency, see Managing Cold Starts in Serverless Environments.

Observability

Platform-native CPU time headers are not consistently available. Use performance.now() to instrument critical paths:

const start = performance.now();
const result = await heavyOperation();
const elapsed = performance.now() - start;

if (elapsed > 20) {
  console.warn(JSON.stringify({
    level: 'warn',
    message: 'Heavy operation approaching CPU budget',
    elapsedMs: elapsed.toFixed(2),
  }));
}

For local load testing that simulates production memory caps:

# Cap Node.js heap to simulate 128 MB edge limit
node --max-old-space-size=128 dist/server.js

Workload Decision Matrix

When average CPU time on Cloudflare exceeds 25 ms, or sustained memory usage exceeds 80 MB on any 128 MB platform, route to a regional serverless function. The hybrid model—edge for routing and stateless transforms, serverless for compute—preserves low latency for user-facing requests while handling heavy operations in an elastic environment.

Common Pitfalls

Resource-Boundary Checklist

Validate each ceiling before promoting middleware to production:

1. Confirm the memory headroom

Subtract runtime and framework overhead (roughly 20–40 MB) from the cap and verify peak heap stays below it under load.

2. Stream anything large

Replace synchronous buffering with TransformStream, and reject payloads above a safe content-length threshold with a 413.

3. Budget synchronous CPU

On Cloudflare, keep per-request synchronous work under the active CPU budget; move hashing and heavy parsing off the hot path.

4. Defer cold modules

Load rarely-hit code with dynamic import() so it never inflates initialization heap or parse time.

• Peak heap measured under load below the provider cap minus overhead
• Large payloads streamed, not buffered, with a 413 Large payloads streamed, not buffered, with a `413` guard
• Synchronous CPU per request within the platform budget
• Heavy modules deferred behind dynamic Heavy modules deferred behind dynamic `import()`
• Local runs capped with --max-old-space-size Local runs capped with `--max-old-space-size` to mirror the edge limit

Frequently Asked Questions

Conclusion

Edge memory and CPU limits are not soft suggestions—they are hard enforcement points that kill your request. Cloudflare’s 10 ms free-tier CPU budget is among the strictest constraints in the industry; Netlify’s 512 MB memory and 50 s wall-clock are the most permissive. Design middleware that stays well below these ceilings: stream large payloads, defer heavy modules, and route CPU-intensive work to serverless functions. For platform-specific comparison of memory allocation strategies see Comparing Memory Limits: Netlify vs Vercel Edge.

Related

• Comparing memory limits: Netlify vs Vercel Edge
• Avoiding CPU time-limit errors in Cloudflare Workers
• Managing cold starts in serverless environments
• Edge bundle optimization techniques
• Supported Web APIs in edge runtimes