Why EU teams look for an alternative
E2B made sandboxes a standard part of the agent stack, and it is a good product. EU teams usually look elsewhere for one reason: the data. A sandbox is where the agent does its actual work, so it holds the customer files it analyzes, the repositories it edits, the credentials it uses and the outputs it produces. Under GDPR, the sandbox provider is a processor of that data.
- Transfers: sending personal data to a processor outside the EU needs a legal basis under Chapter V of GDPR. The EU-US Data Privacy Framework (2023) currently covers certified US companies, but its two predecessors, Safe Harbor and Privacy Shield, were struck down by the EU Court of Justice in 2015 and 2020.
- Jurisdiction: the US CLOUD Act lets US authorities require US companies to hand over data they control, including data stored in the EU.
- Customers: banks, health providers and public bodies often require EU hosting by an EU company in their contracts, whatever the legal analysis says.
What E2B does well
A fair comparison starts with the strengths. E2B runs sandboxes in Firecracker microVMs, publishes its SDKs and its infrastructure code as open source, and is integrated in many agent frameworks. Its code-interpreter SDK is mature and widely used. If data location is not a constraint for you, it is a solid choice.
Providers change regions, terms and features often. Check each provider's current documentation, DPA and sub-processor list rather than relying on any comparison page, including this one.
A checklist for comparing sandbox providers
| Question | Why it matters |
|---|---|
| Where is the company incorporated? | Decides which laws can compel access to your data. |
| Where do sandboxes and snapshots physically run? | Data residency for files, memory snapshots and logs. |
| Is a DPA included, and who are the sub-processors? | GDPR Article 28 requires a processor contract. |
| What is the isolation boundary? | MicroVMs and gVisor resist kernel escapes better than containers. |
| Can you control egress? | Allowlists and blocked private ranges limit what injected code can reach. |
| What happens while the agent waits? | Pause and resume decide whether you pay for idle time. |
| How is it billed? | Per second or per minute, and whether idle sandboxes count. |
| Can you self-host it? | Regulated buyers often need it on their own servers. |
| SDKs, REST and MCP? | Decides how much glue code your agents need. |
How cpuos answers it
- Company and hosting: an EU company. Sandboxes run on dedicated servers in Germany and Finland. Nothing is copied outside the EU, and a DPA is included.
- Isolation: one Firecracker microVM per sandbox, started through jailer with seccomp and cgroups, on bare-metal hosts that run nothing else. Snapshots are encrypted per workspace.
- Egress: internet on, an allowlist, or off. Private ranges, SMTP and the metadata address are always blocked.
- Billing: per second while running, $0.045 per vCPU-hour and $0.005 per GB-hour. Paused sandboxes only pay $0.10 per GB-month of snapshot storage.
- Self-hosted: the same software can run on your own servers.
- Interfaces: TypeScript and Python SDKs, a REST API and an MCP server.
cpuos is in early access. It does not compete on the number of regions or on GPU sandboxes; it competes on EU hosting, self-hosting and per-second pricing with free pauses.
Moving code over
The concepts map one to one, so a port is mostly renaming. E2B method names below are from its public JavaScript SDK at the time of writing.
| Task | E2B | cpuos |
|---|---|---|
| Create | Sandbox.create() | Sandbox.create({ template }) |
| Run a command | sandbox.commands.run(cmd) | sbx.exec(cmd, { onStdout, timeout }) |
| Write a file | sandbox.files.write(path, data) | sbx.files.write(path, data) |
| Read a file | sandbox.files.read(path) | sbx.files.read(path) |
| Public URL for a port | sandbox.getHost(port) | sbx.url(port) |
| Stop paying while idle | See current docs | sbx.pause() and Sandbox.resume(id) |
import { Sandbox } from "@cpuos/sdk"const sbx = await Sandbox.create({ template: "python", timeout: "15m" })await sbx.files.write("/work/data.csv", csv)const run = await sbx.exec("python /work/report.py", { timeout: "2m" })await sbx.exec("python -m http.server 8000", { background: true })console.log(sbx.url(8000)) // https://8000-<id>.sbx.cpuos.sicpuos is in early access. The SDK calls on this page show the API shape early-access teams build against; names can still change before general availability.
Do not forget the model
Moving the sandbox to the EU solves half the problem. Every prompt, every file excerpt and every tool result also goes to the model. If that is a US API, the agent's data still leaves the EU on each step.
The sibling product, gpuOS, runs open models on your own GPUs behind an OpenAI-compatible API. Its guide on GDPR-compliant LLMs in the EU covers the model side. Together: the model thinks on your GPUs, the agent acts in EU sandboxes.