# Cloudflare Workers Limits: Memory, CPU Time, and Large File Workarounds

Cloudflare Workers limits restrict execution resources to `128 MB` of memory per isolate and `10 ms` of CPU time on Free plans, with incoming request bodies capped at `100 MB`. Engineering teams overcome these constraints by streaming payloads through TransformStream and offloading heavy document indexing to external intelligent workspaces.

Source: https://fast.io/resources/cloudflare-workers-limits/
Author: [Tom Langridge](https://fast.io/authors/tom-langridge/)
Last reviewed: 2026-10-05

## What Are the Primary Memory and CPU Limits for Cloudflare Workers?

Cloudflare Workers platform limits restrict execution resources to `128 MB` of memory per isolate and 10 to 50 milliseconds of CPU time on standard plans, requiring external services for heavy compute or large file manipulation. Standard Cloudflare Workers isolates enforce a strict `128 MB` memory ceiling and `10 ms` of CPU execution time on the Free plan, with incoming request bodies capped at `100 MB` on Free and Pro accounts according to Cloudflare platform documentation.

The platform isolates execution environments using V8 technology rather than traditional virtual machines or container runtimes like Docker. Virtual machines emulate physical hardware, and containers isolate operating system kernel namespaces, each allocating gigabytes of dedicated memory. By contrast, V8 isolates run thousands of individual JavaScript execution contexts inside a shared multi-tenant host process. This architecture eliminates cold-start penalties, enabling sub-millisecond invocation times across hundreds of edge data centers globally. The tradeoff for this density and speed is a rigid execution boundary.

### Core Platform Limits Across Cloudflare Workers Tiers

The following comparison table summarizes documented platform boundaries across Free, Paid, and Enterprise tiers as of 2026-10-05:

| Feature | Workers Free | Workers Paid | Workers Enterprise | Date Verified | Source |
| --- | --- | --- | --- | --- | --- |
| Memory per Isolate | 128 MB | 128 MB | 128 MB | 2026-10-05 | Cloudflare Docs |
| CPU Time (HTTP Request) | 10 ms | 5 min (default: 30s) | 5 min (customizable) | 2026-10-05 | Cloudflare Docs |
| CPU Time (Cron Trigger) | 10 ms | 30s (<1h) / 15 min (>=1h) | 15 min | 2026-10-05 | Cloudflare Docs |
| Max Request Body Size | 100 MB | 100 MB (Pro) / 200 MB (Business) | Up to 5 GB (self-serve) | 2026-10-05 | Cloudflare Docs |
| Subrequests per Invocation | 50 | 10,000 (up to 10M) | 10,000+ | 2026-10-05 | Cloudflare Docs |
| Simultaneous Open Connections | 6 | 6 | 6 | 2026-10-05 | Cloudflare Docs |
| Worker Script Size (uncompressed) | 64 MiB | 64 MiB | 64 MiB | 2026-10-05 | Cloudflare Docs |
| Worker Startup Time | 1 second | 1 second | 1 second | 2026-10-05 | Cloudflare Docs |
| Daily Request Allowance | 100,000 requests/day | Unlimited | Unlimited | 2026-10-05 | Cloudflare Docs |
| Environment Variables per Worker | 64 (5 KB max each) | 128 (5 KB max each) | 128 (5 KB max each) | 2026-10-05 | Cloudflare Docs |
| Static Asset File Size | 25 MiB | 25 MiB | 25 MiB | 2026-10-05 | Cloudflare Docs |
| Cache API Max Object Size | 512 MB | 512 MB | 512 MB | 2026-10-05 | Cloudflare Docs |

### Why the 128 MB Ceiling Remains Fixed Across All Plans

Understanding the distinction between these plan tiers is necessary for production architecture. While CPU time expands from `10 ms` to 5 minutes when upgrading to Workers Paid, the `128 MB` isolate memory boundary remains fixed across all tiers, including Enterprise contracts. The `128 MB` budget protects the shared host process from out-of-memory crashes. Because a single host process runs many isolates from different accounts, allowing an individual isolate to claim 1 GB or 2 GB of heap memory would destabilize neighboring workloads.

When building edge proxies, AI agent webhooks, or API gateways, developers must treat `128 MB` as an absolute ceiling. Memory-intensive operations such as parsing large document archives, unzipping packages, or running machine learning embeddings cannot run directly inside the isolate. Teams connect Workers to external services such as persistent [intelligent workspaces](/product/workspaces/) to offload storage, file versioning, and document indexing operations.

## Diagnosing Error 1102 and Error 413: Memory Exceeded and Request Ceilings

When an isolate breaches its operational boundaries, Cloudflare terminates execution to preserve host system health. The two most frequent edge errors encountered when handling large payloads or complex agent logic are Error 1102 and Error 413.

### The 128 MB Isolate Memory Allocation and Error 1102

Each isolate can consume up to 128 MB of memory, including the JavaScript heap and WebAssembly allocations. This allocation accounts for three primary categories of data:

* **V8 JavaScript Heap:** All JavaScript objects, variables, strings, closures, and arrays created by user code and third-party modules.
* **WebAssembly Memory Allocations:** Linear memory buffers initialized by WebAssembly modules compiled into the Worker script.
* **Runtime Overhead:** Internal call stacks, metadata tables, and buffer management objects tracked by the edge runtime.

Memory is metered per isolate rather than per invocation. A single isolate handles multiple concurrent requests when traffic arrives in bursts. If four requests run concurrently and each allocates `30 MB` of heap memory, the isolate reaches `120 MB`. When a fifth request attempts an allocation that pushes memory beyond `128 MB`, the runtime terminates the isolate. When a Worker exceeds its memory limit, Cloudflare returns Error 1102 to the client with the message Worker exceeded resource limits.

In dashboard metrics and Logpush analytics, this termination is cataloged as `exceededMemory`. A related runtime error is `Memory limit would be exceeded before EOF`. This error occurs when a script attempts to buffer an incoming response body whose content length exceeds the remaining memory headroom in the isolate.

### Request Body Ceilings and HTTP Error 413

Error 413 (`413 Request entity too large`) differs from Error 1102 because it occurs before Worker code executes. Cloudflare enforces maximum incoming request body sizes based on the zone plan:

* **Free and Pro:** Incoming request bodies are capped at `100 MB`.
* **Business:** Incoming request bodies are capped at `200 MB`.
* **Enterprise:** Allows incoming request bodies up to `5 GB`, configurable self-serve in the Cloudflare dashboard under zone Network settings.

If a client attempts to transmit a `120 MB` payload to an endpoint on a Free or Pro zone, Cloudflare returns HTTP 413 at the ingress proxy layer. The Worker script never receives the event. Resolving 413 errors requires altering upload routing architecture rather than optimizing JavaScript code.

### CPU Time Execution versus Wall-Clock Duration

Developers often confuse CPU time with wall-clock time:

* **CPU Time:** The actual time the physical processor spends executing your code instructions, including loops, regular expressions, JSON parsing, and cryptographic operations.
* **Wall Time:** The total elapsed duration from invocation start to finish, including time spent waiting for network responses, database queries, and external API calls.

Network waiting consumes zero CPU time. When code calls `await fetch("https://example.com/api")`, the isolate suspends execution until packets return over the network. On the Workers Paid plan, you can increase the maximum CPU time from the default 30 seconds to 5 minutes (300,000 ms). HTTP requests have no hard wall-clock duration limit as long as the client remains connected, allowing long-running streams to stay open. Background cleanup work can also run after returning a response using `ctx.waitUntil()`, which allows up to `30 seconds` of extended background execution.

## How to Stream Large File Payloads to Bypass Isolate Memory Limits

The standard approach to handling uploads in traditional server environments is reading the complete body into a buffer with `await request.arrayBuffer()` or `await request.text()`. On Cloudflare Workers, buffering a `50 MB` file requires allocating a `50 MB` buffer, plus internal V8 string or object representations. In an isolate with `128 MB` of total memory, buffering multiple concurrent files triggers immediate heap exhaustion and Error 1102.

### The Web Streams Architecture

To handle files safely at the edge, developers use the Web Streams API (`ReadableStream`, `WritableStream`, and `TransformStream`). Streams break data into small sequential chunks, typically 16 KB to 64 KB each. The isolate processes one chunk at a time, keeping active heap memory under `5 MB` regardless of whether the payload is `10 MB` or `90 MB`.

The following example demonstrates streaming an incoming file upload through a `TransformStream` without buffering the payload into memory:

```javascript
export default {
  async fetch(request, env, ctx) {
    if (request.method !== "POST") {
      return new Response("Method not allowed", { status: 405 });
    }
    // Validate content length header against 100 MB limit
    const contentLength = request.headers.get("content-length");
    if (contentLength && parseInt(contentLength, 10) > 104857600) {
      return new Response("Payload exceeds 100 MB edge limit", { status: 413 });
    }
    // Pipe chunks sequentially through TransformStream
    const { readable, writable } = new TransformStream({
      transform(chunk, controller) {
        controller.enqueue(chunk);
      }
    });
    ctx.waitUntil(request.body.pipeTo(writable));
    // Stream directly to destination storage
    const uploadResponse = await fetch("https://storage.example.com/upload", {
      method: "PUT",
      headers: {
        "Content-Type": request.headers.get("content-type") || "application/octet-stream",
        "Authorization": `Bearer ${env.STORAGE_API_KEY}`
      },
      body: readable
    });
    return new Response(uploadResponse.body, {
      status: uploadResponse.status,
      headers: uploadResponse.headers
    });
  }
};
```

### Direct-to-Storage Architecture for Files Exceeding 100 MB

When files approach or exceed the `100 MB` edge request limit, even streaming through a Worker fails at the zone ingress proxy. The standard architectural solution is pre-signed upload URLs.

In this pattern, the client sends a lightweight JSON request to the Worker containing file metadata, such as the filename, byte size, and MIME type. The Worker verifies user authentication, communicates with the storage backend to generate a time-limited pre-signed upload URL, and returns the URL to the client. The client then uploads the multi-gigabyte file directly to storage. The edge Worker operates purely as an authentication and coordination gate, consuming less than `1 ms` of CPU time and keeping memory consumption negligible.

## Architecting AI Agent Webhooks and MCP Servers Beyond Edge Limits

Deploying Model Context Protocol (MCP) servers and autonomous AI agent webhooks on Cloudflare Workers creates distinct architectural friction. AI agents do not simply pass small JSON payloads; they process documents, parse technical manuals, ingest PDFs, compute text embeddings, and query large corpora.

Running these workloads directly inside an edge Worker quickly fails:

* PDF parsing libraries allocate large font tables and document object models in the V8 heap, rapidly consuming `150 MB` to `300 MB` of RAM.
* In-memory vector search engines require loading dense float32 embedding arrays into memory, exceeding isolate limits within dozens of document vectors.
* Generating embeddings or running large language model evaluation loops locally exceeds the `10 ms` Free CPU limit or exhausts the default `30-second` Paid CPU budget.

### Decoupling Edge Routing from Workspace Intelligence

To build stable AI agent pipelines, teams separate the edge router from the document processing layer. Cloudflare Workers handle incoming webhook requests, validate HMAC signatures, verify API tokens, and route commands. The heavy document operations, such as storage, parsing, vector indexing, and semantic retrieval, run on dedicated persistent infrastructure.

Instead of attempting to store and index documents in edge isolates or complex custom vector databases, developers connect Workers to persistent [intelligent workspaces](/product/workspaces/).

Fast.io hosts a remote Model Context Protocol (MCP) server accessible via Streamable HTTP at `https://mcp.fast.io/mcp/tools`.

When a file arrives, the Worker forwards the document to an org-owned Fast.io workspace. Once Intelligence Mode is enabled, the workspace indexes files automatically for hybrid search, combining full-text search, semantic search, and metadata value filtering. The agent or edge Worker then queries the workspace through the Fast.io MCP server using standard tool calls, retrieving relevant document excerpts with exact citations rather than loading entire files into memory.

For structured document extraction, [Metadata Views](/product/document-data-extraction/) extracts typed attributes, such as dates, invoice totals, party names, and contract terms, across PDFs, images, and spreadsheets without custom OCR scripts or edge memory consumption.

Teams building multi-agent systems also use [storage for agents](/storage-for-agents/) to maintain version history and file ownership handoffs between autonomous agents and human team members. For teams connecting specialized AI tools, [Fast.io AI capabilities](/product/ai/) enable agents to query company knowledge without exceeding edge compute boundaries.

## Best Practices for Managing Cloudflare Workers Subrequests and State

Managing network I/O and resource lifecycles within Cloudflare Workers requires strict adherence to runtime constraints. Subrequest allowances, open connection ceilings, and caching rules dictate how edge services communicate with external infrastructure.

### Managing Subrequest Allowances and Redirect Chains

Every outgoing call made via `fetch()`, KV lookups, R2 storage operations, or Cache API transactions counts as a subrequest. Free accounts allow 50 subrequests per invocation, while Paid accounts provide 10,000 subrequests.

Each redirect followed during a fetch request also consumes an additional subrequest from your quota. If an API redirects through three intermediate URLs, that single operation counts as four subrequests. Developers should handle redirects explicitly or disable automatic redirect following (`redirect: "manual"`) when executing high-volume API integrations.

Within your own Cloudflare account, avoid making public internet `fetch()` calls between Workers on the same zone. Instead, configure Service Bindings, which execute worker-to-worker calls directly in the edge runtime without crossing external network interfaces or consuming HTTP subrequest quotas.

### The Six Simultaneous Open Connections Ceiling

A platform constraint that causes intermittent latency spikes is the six simultaneous open connection ceiling. An invocation can have at most six outgoing connections waiting for response headers concurrently.

A common pitfall is executing `await Promise.all(urls.map(url => fetch(url)))` across 20 endpoints. The runtime opens six connections and queues the remaining 14. If initial connections stall on slow upstreams, queued requests encounter timeouts. Production code must batch concurrent outgoing requests in pools of five or six connections.

### Freeing Unused Response Bodies

When making subrequests to verify status codes or read headers, never leave response bodies unconsumed. If your Worker checks whether an upstream endpoint is healthy, always call `response.body.cancel()`. Failing to cancel unread streams keeps TCP sockets and buffer tracking memory open, contributing to isolate resource exhaustion.

The Cache API supports caching objects up to `512 MB` on Free, Pro, and Business plans, and up to `5 GB` for Enterprise zones. Cache operations share the subrequest quota, with 50 calls on Free and 1,000 on Paid.

Building scalable edge applications on Cloudflare Workers requires embracing the isolate model: stream payloads through `TransformStream`, batch outgoing subrequests within connection limits, and offload document indexing and heavy corpora storage to external intelligent workspaces.

## Frequently asked questions

### What is the memory limit for Cloudflare Workers?

Standard Cloudflare Workers isolates are strictly capped at `128 MB` of memory across all plan tiers, including Free, Paid, and Enterprise. This allocation encompasses the V8 JavaScript heap, WebAssembly linear memory allocations, and internal runtime metadata. Because memory is metered per isolate rather than per invocation, concurrent requests handled by the same isolate share this `128 MB` budget. If an allocation exceeds this threshold, the runtime aborts the isolate and returns Error 1102 (Worker exceeded resource limits) to the client.

### What is the maximum file size you can upload through Cloudflare Workers?

The maximum incoming request body size depends on the Cloudflare zone plan rather than the Workers tier. Cloudflare Free and Pro plans enforce a hard ceiling of `100 MB` per request. Cloudflare Business plans allow up to `200 MB`, and Cloudflare Enterprise plans support request bodies up to `5 GB` via self-serve dashboard configuration. Payloads exceeding these thresholds are blocked at the edge network edge with HTTP status 413 (Request entity too large) before reaching Worker code. To handle larger files, applications must use chunked multipart uploads or generate pre-signed direct upload URLs to external storage.

### How do you bypass Cloudflare Workers memory and CPU limits?

To work around the `128 MB` isolate memory ceiling, avoid buffering payloads in memory using `arrayBuffer()` or `text()`. Stream data chunk-by-chunk using the Web Streams API (ReadableStream, WritableStream, and TransformStream) so memory consumption stays under a few megabytes regardless of payload size. To handle heavy compute, PDF parsing, or AI document indexing that exceeds the `10 ms` Free or 5-minute Paid CPU caps, offload processing to external services or intelligent workspaces via the Model Context Protocol (MCP) rather than executing compute inside the edge isolate.

### What happens when a Cloudflare Worker exceeds its subrequest limit?

Free plan Workers are limited to 50 subrequests per invocation, while Workers Paid accounts receive 10,000 subrequests per request by default. Subrequests include outgoing fetch() calls, KV operations, R2 storage reads and writes, and Cache API calls. Each hop in an HTTP redirect chain also consumes one subrequest. If your Worker exceeds its allocated quota, the runtime throws a JavaScript exception that causes the request to fail unless handled within a try/catch block.

### How does CPU time differ from wall-clock duration in Cloudflare Workers?

CPU time measures only the active clock cycles spent by the host processor executing your JavaScript or WebAssembly instructions, such as executing loops, computing hashes, or parsing JSON. Wall-clock duration measures total elapsed time from the start of an invocation to its completion, including time spent waiting for network I/O, external APIs, or database responses. Network waiting consumes zero CPU time. HTTP-triggered Workers have no hard wall-clock duration limit while the client remains connected, but Free plans enforce a `10 ms` CPU time cap and Paid plans default to `30 seconds` of CPU execution.

## Sources

- [Cloudflare Docs](https://developers.cloudflare.com/workers/platform/limits/): Each isolate can consume up to 128 MB of memory, including the JavaScript heap and WebAssembly allocations
- [Cloudflare Docs](https://developers.cloudflare.com/workers/platform/limits/): On the Workers Paid plan, you can increase the maximum CPU time from the default 30 seconds to 5 minutes (300,000 ms)
- [Cloudflare Docs](https://developers.cloudflare.com/workers/platform/limits/): When a Worker exceeds its memory limit, Cloudflare returns Error 1102 to the client with the message Worker exceeded resource limits

## About Fast.io

Fast.io provides shared workspaces where people and AI agents work on the same files, with built-in semantic search and citation-backed chat over what they hold. Agents reach it through a remote MCP server, a REST API at https://api.fast.io/current/, and a command line client published on npm as @vividengine/fastio-cli. MCP setup is at https://mcp.fast.io/docs: Claude and most MCP clients connect to https://mcp.fast.io/mcp/tools, ChatGPT to https://mcp.fast.io/mcp/operations, and coding agents to https://mcp.fast.io/mcp/code.