An EU E2B alternative: agent sandboxes that stay in the EU

If you're shopping for an E2B alternative, you've probably already decided that running agent-generated code on your own boxes is a bad idea. Good. The next question is the one that sends procurement into a three-week loop: where does that code actually run, and who can be compelled to hand over what it touched?

E2B is a genuinely good product - fast microVM isolation and mature SDKs. We use the same primitives. But it's a US company, and for a lot of EU teams that single fact decides it. This is orkestr vs E2B: where we line up, where we differ, and the one piece of the stack that's never going to be in the EU no matter who you pick.

The short verdict

Pick E2B if you're US-hosted, want US-region latency, and the bigger existing ecosystem. Pick orkestr if you're an EU company that wants the runtime, the snapshots, and the DPA all sitting inside one EU legal entity - on every plan, not just enterprise.

That's it. The rest is detail.

What's actually the same

The products are close. The shape is nearly identical, because this is a problem with a known-good shape:

• A REST API plus Python and JavaScript SDKs.
• create / exec / read+write files / pause / resume / terminate.
• An MCP server you can drop into Claude Code, Cursor, or any MCP client.
• Hardware-isolated VMs, not shared-kernel containers. Each sandbox boots its own kernel and rootfs.

Here's the orkestr Python SDK. If you've written E2B code, this will look familiar on purpose:

from orkestr import Sandbox

with Sandbox.create(template="python-3.12") as sbx:
    sbx.files.write("/workspace/main.py", "print(sum(range(1_000_000)))")
    result = sbx.exec("python /workspace/main.py")
    print(result.stdout)   # 499999500000

So if "same primitives, different jurisdiction" is all you needed to hear, you can start free - no waitlist, no card. If you want the actual differences, keep reading.

The one thing that is not in the EU (and never will be)

An AI agent has two halves: the model that decides what to do, and the sandbox that runs what it decided. Those are different machines, often different companies.

                       ONE AGENT LOOP, TWO DIFFERENT MACHINES

  THE MODEL CALL                                EU · GERMANY & FINLAND
  you pick the provider                         operated by an EU entity, no US parent
  ┌────────────────────────────┐                ┌──────────────────────────────────┐
  │  Anthropic / OpenAI   (US) │  run this code │       orkestr sandbox            │
  │  Mistral              (EU) │  ────────────▶ │  · code execution                │
  │  self-hosted        (yours)│                │  · files in /workspace           │
  │                            │  ◀──────────── │  · pause / resume snapshots      │
  │  crosses the border only   │  stdout·files  │  · env vars · logs               │
  │  if you pick a US model.   │                │                                  │
  │  your DPA, with them.      │                │  none of this leaves the EU      │
  └────────────────────────────┘                └──────────────────────────────────┘

  orkestr runs the SANDBOX, not the model. the code, files and snapshots stay in
  the EU - the reasoning step is the only part you can send elsewhere.

orkestr runs the sandbox. We do not run the model. When your agent's brain decides to pip install pandas and parse this CSV, that decision came from whatever model you pointed it at - and if that's a US model API, the prompt and completion are processed under that provider's terms, not ours. That's your data processor to choose and your DPA to sign.

What orkestr guarantees is everything on the right-hand side: the code that runs, the files it touches, the memory it allocates, the snapshots we take when you pause it. All of that lives on bare-metal hardware in Germany and Finland and never leaves the EU. We can't promise anything about a model we don't host, so we don't. We promise the part we run.

For a lot of teams this is the ideal arrangement - pick a European model like Mistral and the entire loop is in the EU; pick a US model and only the reasoning step crosses the border while all the working data stays home. Either way, the blast radius of "agent ran some code" is EU-contained.

Jurisdiction, not just region

The real difference isn't where the servers sit. It's who controls the company that runs them.

E2B can run in Europe, but look at how you get there. The managed E2B service is operated by FoundryLabs, Inc., a Delaware corporation. To keep your sandbox data in the EU, the documented path is bring-your-own-cloud - you run their stack in your own AWS, GCP, or Azure account or VPC - or you self-host it outright. That's a real option, and for a large team that already lives in one of those clouds, a good one. It's also a project: you're now operating sandbox infrastructure, patching it, and watching it. The click-and-go managed version still runs under a US entity.

And jurisdiction follows the entity, not just the bytes. Under the US CLOUD Act, a US-incorporated provider can be compelled to produce data it controls regardless of where that data physically sits. Post-Schrems II, that control question is exactly what EU data protection authorities care about. A German DPA isn't only asking "where are the bytes" - it's asking "whose lawyer answers the subpoena."

With orkestr, the company that signs your DPA is the company that operates the runtime, and it's an EU entity with no US parent three layers up. EU hosting isn't a tier, and it isn't a bring-your-own-cloud project - it's where everything runs by default, including on the free plan. You don't negotiate or self-host your way to Europe.

Isolation is a tie, and that's the point: both run each sandbox as its own hardware-virtualised microVM on bare metal, so the boundary is the same. Decide on the rows where the columns actually differ.

Data retention: what we keep, and for how long

GDPR isn't only about where data sits - it's about minimisation and deletion. The interesting question for any sandbox provider is what survives after your agent is done. Here's the orkestr answer, concretely:

                          LIFECYCLE, AND WHAT SURVIVES IT

       boot              pause                resume · state restored
  create ──▶ running ──────────▶ paused  ◀──────────────────┐
                │                (snapshot on               │
                │                 EU storage) ──────────────┘
                │ terminate
                ▼
  ┌────────────────────────────────────────────┐
  │  terminated → destroyed                    │
  │  kernel, rootfs, processes, memory - gone  │
  └────────────────────────────────────────────┘

  WHAT'S LEFT AFTERWARD
  ┌─────────────────────────┬─────────────────────────┬─────────────────────────┐
  │ Environment variables   │ Snapshots               │ Terminated sandbox      │
  │ in memory only, never   │ capped per plan,        │ nothing runnable behind │
  │ written to disk. gone   │ deleted on terminate.   │ it - no filesystem, no  │
  │ with the VM.            │ for parking a task.     │ process tree.           │
  └─────────────────────────┴─────────────────────────┴─────────────────────────┘

• Environment variables are held in memory for the life of the sandbox and never written to a persistent store. They die with the VM.
• Snapshots (from pause) are capped per plan, and they're deleted when you terminate the sandbox. They exist to let an agent park mid-task and pick up an hour later - not to accumulate.
• A terminated sandbox leaves nothing runnable behind. The kernel, the filesystem overlay, the process tree - destroyed.
• We keep what we need to run the sandbox, and not more. If a field isn't needed to operate the runtime or bill it, we don't store it.

You still own the data you deliberately persist elsewhere - if your agent writes to a database, that's your store. But the sandbox itself is built to forget.

Performance, briefly

This is where people expect the EU option to apologise, and we don't have to. Cold start is around 150ms; from a warm pool it's under 30ms. That's in the same class as E2B - microVMs are microVMs, and we keep a pool hot so your agent isn't waiting on a boot.

The honest latency caveat is geography, not architecture: if your users and your model API are on the US east coast, a sandbox in Frankfurt adds a transatlantic round trip versus a US-region sandbox. For most agent workloads - where the expensive step is the model call, not the sandbox hop - it disappears into the noise. If you're latency-bound on the sandbox specifically and your traffic is US-centric, that's a fair reason to stay US-hosted.

Network egress is a choice, not a default

One more thing that matters the moment a model is writing the commands. Every orkestr sandbox picks a network mode at creation:

# no egress at all - the safe default for code you haven't read
sbx = Sandbox.create(template="python-3.12", network="off")

# allowlist - package registries and common APIs work, invented domains don't
sbx = Sandbox.create(template="python-3.12", network="restricted")

off means nothing leaves the box. restricted routes through an allowlisting proxy so pip install works but a hallucinated curl evil.example.com doesn't. open is full egress and it's gated behind a verified payment method on purpose. The default is the paranoid one, which is the right default for LLM-generated code.

E2B can lock egress down too, and it's flexible about it: outbound is on by default, and you opt into restriction with allow/deny rules and domain filtering you can even change on a running sandbox. The difference is which way the default points. E2B ships open and you close it; orkestr ships closed and you open it. When the thing writing the commands is an LLM you haven't audited, default-closed is the safer place to start.

When to pick which

Pick E2B if: you're already US-hosted and latency-sensitive on the sandbox itself, you want the bigger existing ecosystem, or you need their specific templates today.

Pick orkestr if: you're an EU company (or sell to one) and "the entity running our agent code is US-incorporated" is a sentence you don't want in a procurement doc - and you want that to be true on the free tier, not just enterprise.

If that's you, you can start free - no waitlist, no credit card. Enable sandboxes from the console in one click, then create your first one from the dashboard or the SDK. For the bigger picture on why we built an EU sandbox for AI agents in the first place, or a plain-language take on what a managed sandbox actually is, those two posts go deeper.

FAQ

Can't I just run E2B in the EU?
You can, by bringing your own cloud or self-hosting - running their stack in your own AWS, GCP, or Azure account so the data stays in your EU infrastructure. But then you operate it. The managed service is run by a US (Delaware) company, and GDPR cares about who controls the data, not just where it sits: a US-incorporated provider can be compelled under the US CLOUD Act regardless of region. orkestr's operating entity is in the EU with no US parent, and EU hosting is the default on every plan.

Does my data leave the EU at all?
The sandbox, its files, its memory, and its snapshots stay in the EU. The one exception is the model call - if your agent uses a US-hosted LLM, the prompt and completion are processed by that provider under your DPA with them. Use an EU model and the whole loop stays in Europe.

Can I use it with Claude Code or Claude's Managed Agents?
Yes. There's an MCP server for Claude Code and Cursor, and the REST API works as a configured sandbox provider for agent frameworks that let you point at one.

What languages are supported?
Python 3.12 and Node 22 templates ship today, plus a bare Python image and a minimal Ubuntu shell. Custom images are on the roadmap.

How fast is it?
Around 150ms cold, under 30ms from a warm pool - the same class as other microVM sandboxes.