Cloudflare Sandbox SDK vs Deno Sandbox

Cloudflare Sandbox SDK

Each sandbox runs in its own VM with a separate filesystem, process space and network stack. No hosted API. You deploy and secure a Worker before an agent can call anything, and the starter has no auth.

Deno Sandbox

Secrets stay outside the microVM and are substituted only on outbound requests to approved hosts, and an allowlist limits egress. The service is still in beta, sandboxes need the $20 Pro plan, lifetime is capped at 30 minutes, and no sandbox operation appears in the published OpenAPI document.

Cloudflare Sandbox SDK

1. Derive the sandbox ID from the authenticated user, as the docs advise. IDs aren't secrets
2. Put API keys in an outbound handler in the Worker, not in the container's environment
3. Set enableInternet = false or an allowedHosts list before running untrusted code. Internet access is on by default
4. Check that a restored backup has every directory you expect. Backups of 10 MB or more have open bugs
5. Start new projects on 1.0. The 0.x library only gets fixes until 31 December 2026

Deno Sandbox

1. Set DENO_DEPLOY_TOKEN to an organisation token (prefix ddo_) from Settings in console.deno.com. The organisation must be on Pro or above
2. Pass allowNet on every Sandbox.create(). The Security page says outbound access is unrestricted when it is omitted
3. Pass credentials through secrets with a hosts list, not env, so code in the VM sees only a placeholder
4. The default timeout ends the VM when the client disconnects. Pass a duration such as "10m" and reconnect with Sandbox.connect({ id }), up to 30 minutes
5. Create volumes in ord and start the sandbox in ord. A volume mounts only in its own region
6. exposeHttp URLs are public with no authentication. Treat the random subdomain as a secret