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.
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 WebSocket transport to multiplex all SDK calls over a single persistent connection:
{ "vars": { "SANDBOX_TRANSPORT": "websocket" },}[vars]SANDBOX_TRANSPORT = "websocket"With WebSocket transport enabled:
- The WebSocket upgrade 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 WebSocket transport for high-frequency operations - Enable
SANDBOX_TRANSPORT=websocketto avoid subrequest limits when making many SDK calls per request