Limits

Durable Objects are a special kind of Worker, so Workers limits also apply. Limits that depend on your Workers plan are identified on that page. This page also covers Durable Object storage, CPU, and outbound HTTP request body size limits.

For Durable Object classes with SQLite storage these SQL limits apply:

Cloudflare limits each HTTP request body a Durable Object sends to an external service with fetch() to 100 MiB by default. Requests exceeding this limit can fail with 413 Payload Too Large.

This limit applies to each request body, including encoding and multipart form fields. It does not limit the total size of a file uploaded through separate requests. The destination service can impose additional limits.

The Maximum Upload Size setting for your application's custom domain does not control this limit. A larger upload accepted by your domain can still be rejected when your Container or Durable Object sends it to another service.

For larger uploads, use the destination's multipart or resumable upload API. Keep each request body below the limit. If you already use multipart uploads, reduce the part size. Streaming, HTTP chunked transfer encoding, and multipart/form-data do not bypass the limit on a single request body.

To request a higher outbound limit, contact your account team or Cloudflare Support. Specify that the request concerns outbound HTTP uploads from Containers or Durable Objects. Increases are subject to review.

Include the following information:

• The account ID and Worker name for the affected workload.
• The Container instance ID or Durable Object namespace and ID.
• The destination hostname.
• The failing request body size in bytes and the requested limit.
• The failure timestamp, relevant error logs, and a minimal reproduction.

Durable Objects can scale horizontally across many Durable Objects. Each individual Object is inherently single-threaded.

• An individual Object has a soft limit of 1,000 requests per second. You can have an unlimited number of individual objects per namespace.
• A simple storage get() on a small value that directly returns the response may realize a higher request throughput compared to a Durable Object that (for example) serializes and/or deserializes large JSON values.
• Similarly, a Durable Object that performs multiple list() operations may be more limited in terms of request throughput.

A Durable Object that receives too many requests will, after attempting to queue them, return an overloaded error to the caller.

Durable Objects are designed such that the number of individual objects in the system do not need to be limited, and can scale horizontally.

• You can create and run as many separate Durable Objects as you want within a given Durable Object namespace.
• There are no limits for storage per account when using SQLite-backed Durable Objects on a Workers Paid plan.
• Each SQLite-backed Durable Object has a storage limit of 10 GB on a Workers Paid plan.
• Refer to Durable Object limits for more information.

Durable Objects are Worker scripts, and have the same per invocation CPU limits as any Workers do. Note that CPU time is active processing time: not time spent waiting on network requests, storage calls, or other general I/O, which don't count towards your CPU time or Durable Objects compute consumption.

By default, the maximum CPU time per Durable Objects invocation (HTTP request, WebSocket message, or Alarm) is set to 30 seconds, but can be increased for all Durable Objects associated with a Durable Object definition by setting limits.cpu_ms in your Wrangler configuration:

{
	// ...rest of your configuration...
	"limits": {
		"cpu_ms": 300000, // 300,000 milliseconds = 5 minutes
	},
	// ...rest of your configuration...
}

[limits]
cpu_ms = 300_000

When a SQLite-backed Durable Object reaches its maximum storage limit (10 GB on Workers Paid, or 1 GB on the Free plan), write operations (such as INSERT, UPDATE, or calls to the put() and sql.exec() storage APIs) will fail with the following error:

database or disk is full: SQLITE_FULL

Read operations (such as SELECT queries, get(), and list() calls) will continue to work, and DELETE operations will also succeed so that you can remove data to free up space.

To handle this error in your Durable Object, catch the exception thrown by the storage API:

try {
	this.ctx.storage.sql.exec(
		"INSERT INTO my_table (key, value) VALUES (?, ?)",
		key,
		value,
	);
} catch (e) {
	if (e.message.includes("SQLITE_FULL")) {
		// Storage limit reached — reads and deletes still work
		// Consider deleting old data or returning a meaningful error to the caller
	}
	throw e;
}

Wall time (also called wall-clock time) is the total elapsed time from the start to end of an invocation, including time spent waiting on network requests, I/O, and other asynchronous operations. This is distinct from CPU time, which only measures time the CPU spends actively executing your code.

The following table summarizes the wall time limits for different types of Worker invocations across the developer platform: