Daytona vs Deno Sandbox

Daytona

API keys with per-action scopes, so an agent can create sandboxes without being able to delete them. The container class shares the host kernel. Only the VM classes get their own.

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.

Daytona

1. Pick a Linux VM class for untrusted code or when memory must survive a pause. Container sandboxes stop and archive instead
2. Set autoStopInterval yourself. The 15-minute idle default can stop a sandbox while the agent is still thinking
3. Give the agent a key without delete:sandboxes if it shouldn't destroy work
4. Read Retry-After-{throttler} on a 429 before retrying sandbox creation
5. Check the organisation's tier before relying on outbound calls from inside the sandbox

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