← Sandbox / sandbox / platform

Limits

Since the Sandbox SDK is built on top of the Containers platform, it shares the same underlying platform characteristics. Refer to these pages to understand how pricing and limits work for your sandbox deployments.

Sandbox also inherits current Containers lifecycle, placement, and routing behavior. For more detail, refer to Lifecycle of a Container and Scaling and Routing.

Refer to Containers limits for complete details on:

• Memory, vCPU, and disk limits for concurrent container instances
• Instance types and their resource allocations
• Image size and storage limits

When using the Sandbox SDK from Workers or Durable Objects, you are subject to Workers subrequest limits. By default, the SDK uses HTTP transport where each operation (exec(), readFile(), writeFile(), etc.) counts as one subrequest.

• Workers Free: 50 subrequests per request
• Workers Paid: 1,000 subrequests per request

Enable RPC transport to multiplex all SDK calls over a single persistent connection:

{
	"vars": {
		"SANDBOX_TRANSPORT": "rpc"
	},
}

[vars]
SANDBOX_TRANSPORT = "rpc"

With RPC transport enabled:

• The persistent connection counts as one subrequest
• All subsequent SDK operations use the existing connection (no additional subrequests)
• Ideal for workflows with many SDK operations per request

See Transport modes for a complete guide.

To work within these limits:

• Right-size your instances - Choose the appropriate instance type based on your workload requirements
• Clean up unused sandboxes - Terminate sandbox sessions when they are no longer needed to free up resources
• Optimize images - Keep your custom Dockerfiles lean to reduce image size
• Use RPC transport for high-frequency operations - Enable SANDBOX_TRANSPORT=rpc to avoid subrequest limits when making many SDK calls per request