Cloudflare Sandbox SDK vs Runloop Devboxes

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.

Runloop Devboxes

Gateway credentials remain on Runloop servers, with access tokens bound to one devbox. Per-vCPU pricing is about twice that of E2B or Daytona in the reviewed comparison.

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

Runloop Devboxes

1. Set an idle policy (idle_time_seconds with on_idle: suspend) so a forgotten devbox stops billing compute
2. Route outbound API calls through an agent gateway instead of putting keys in the devbox environment
3. Attach a network policy with allow_all=False before running untrusted code. Egress is open by default
4. Restart background services after every resume. Nothing in memory survives
5. Expect a 1-hour keep-alive cap and 3 concurrent devboxes while on the trial