Sandboxes

Note

This page documents Sandbox SDK 0.x for existing applications. For new applications, refer to Sandboxes. To move an existing application to @cloudflare/sandbox 1.0, refer to Migrate from Sandbox SDK 0.x.

Sandbox SDK pricing is determined by the underlying Containers platform it's built on.

Containers Pricing

Refer to Containers pricing for complete details on:

• vCPU, memory, and disk usage rates
• Network egress pricing
• Instance types and their costs

Related Pricing

When using Sandbox, you'll also be billed for:

• Workers - Handles incoming requests to your sandbox
• Durable Objects - Powers each sandbox instance
• Workers Logs - Optional observability (if enabled)

Note

This page documents Sandbox SDK 0.x for existing applications. For new applications, refer to Sandboxes. To move an existing application to @cloudflare/sandbox 1.0, refer to Migrate from Sandbox SDK 0.x.

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.

Container limits

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

Workers and Durable Objects 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.

Subrequest limits

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

Avoid subrequest limits with RPC transport

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.

Best practices

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