cloudflare-os vs E2B
Both are catalogued under Sandboxes & Runtimes. The figures come from the GitHub API; the assessments are ours.
cloudflare-osCloudflare's in-house AI workspace: every app is a per-user Gadget in its own Worker sandboxOfficialApache-2.0
E2BSandboxed cloud runtime for agent-generated codeOfficialApache-2.0At a glance
| At a glance | cloudflare-os | E2B |
|---|---|---|
| License | Apache-2.0 | Apache-2.0 |
| Languages | TypeScript | TypeScript, Go |
| Deployment | Self-hosted / Runs locally | Self-hosted / Managed cloud |
| Maturity | Growing | Growing |
| Stars | 8.3k | 13.4k |
| Star growth over the last 7 days | — | +2 ★ |
| Forks | 913 | 993 |
| Open issues | 83 | 44 |
| Last commit | 15 Aug 2026 | 13 Aug 2026 |
| Activity | Active | Active |
What each one does
cloudflare-os
Cloudflare OS pairs an agent chat with "Gadgets" — small apps the built-in coding agent writes for you, each running as a Dynamic Worker with its internet access disabled, its client confined to a sandboxed iframe that reaches the server only over Cap'n Web via `postMessage()`. External services are reached through Gatekeepers, per-service Workers that wrap an API in Cap'n Web, log every call, and simulate side-effecting actions so the agent keeps queueing work while approvals wait for you to review them in bulk. The commitment to Workers runs deep: every workspace is a Durable Object, every Gadget a Dynamic Worker Facet, and Facets and Dynamic Workers were added to the runtime specifically for this project — so hosting means a Cloudflare account, and the deploy-to-your-own-servers-on-`workerd` path is still marked COMING SOON in the README. The maintainers call the August 2026 v2 rewrite an early access release with many rough edges, and many Gatekeepers need configuration of their own — including OAuth client credentials per service — before GitHub or Google will connect.
Full entry →E2B
Starts an isolated micro-VM in well under a second, which is what makes per-task sandboxing practical rather than theoretical. If an agent executes code it wrote itself, something like this is a requirement, not a nicety. Self-hosting is possible but meaningfully more work than the hosted path.
Full entry →What you can do
cloudflare-os
- Run the whole stack locally first —
pnpm run-localboots the backend, frontend andworkerdtogether at http://localhost:8787 with state kept in a local.wranglerdirectory; for iteration you split it intopnpm dev-serverandpnpm dev-clientand open port 3000. - Ask for an app, not a document — A prompt like "Make a collaborative whiteboard app" produces a Gadget that the built-in coding agent writes, tests and debugs; a request for slides starts from the bundled slides Blueprint instead of from scratch.
- Talk to the app you just built — A Gadget's client and server are required to communicate over Cap'n Web RPC, so the server methods double as the agent's tool surface — the Code Mode harness invokes them directly, with no MCP server to write.
- Queue approvals instead of blocking on them — When an agent takes a side-effecting action, the Gatekeeper simulates the outcome, hands back simulated results if the agent reads them, logs the call, and holds the real action for you to approve or reject in bulk or one-by-one later.
- Connect services one Gatekeeper at a time — Each integration is a separate Worker under
packages/gatekeeper-*—gatekeeper-github,gatekeeper-google,gatekeeper-slack,gatekeeper-notion,gatekeeper-homeassistant,gatekeeper-emailand more, each with setup steps in its own README — and an agent gets none of them until you introduce a specific resource by pasting a link or picking it under "add resource".
E2B
- Run agent-written code in isolation — Sandbox.create() from the e2b Python or JavaScript SDK starts a cloud sandbox, and sandbox.commands.run() executes a shell command inside it and returns stdout.
- Evaluate code and read the result — Installing the Code Interpreter SDK (e2b-code-interpreter or @e2b/code-interpreter) adds run_code() / runCode(), which evaluates a snippet and hands back the value as execution.text.
- Self-host on AWS or GCP — The e2b-dev/infra repository ships a Terraform deployment covering AWS and Google Cloud; Azure and a plain Linux machine are listed as not yet supported.
- Start from a working integration — The e2b-cookbook repository collects end-to-end examples pairing sandboxes with different LLMs and agent frameworks, so the first sandbox does not have to be wired from scratch.