Vercel Sandbox is a clean way to run untrusted code. A Firecracker microVM per sandbox, a Python and a JS SDK, snapshots that persist between runs, and if you already deploy on Vercel it drops straight in. It's a good product.

There's one line in the docs that decides it for a lot of EU teams, and it's easy to skim past: "Currently, Vercel Sandbox is only available in the iad1 region." That's US East, Northern Virginia. Every sandbox you create, every file your agent writes, every snapshot it saves - all of it runs there. There is no EU region to pick.

If you're an EU company shopping for a Vercel Sandbox alternative because of exactly that, this post is the comparison. Where the two line up, where they genuinely differ, and the honest places Vercel wins.

The short verdict

Pick Vercel Sandbox if you already live on Vercel, you want high self-serve concurrency out of the box, and US-region execution is fine for you. Pick orkestr if you're an EU company that needs the agent's code, files, and snapshots to physically stay in Europe - on every plan, by default, without a region you have to go ask for.

The one fact that decides it: where the code physically runs

Most "is it GDPR-friendly" arguments are about control - who can be compelled to hand over data. With Vercel Sandbox you don't even get to the control question, because the location question already answers it. The sandbox provisions in iad1. That's not a default you can override to Frankfurt; it's the only region the service runs in today.

                    WHERE YOUR AGENT'S CODE PHYSICALLY RUNS

  VERCEL SANDBOX                            orkestr
  runs on Vercel infrastructure            EU entity, no US parent
  ┌──────────────────────────────┐         ┌──────────────────────────────┐
  │                              │         │                              │
  │           iad1               │         │        fsn1 + hel1           │
  │   US East · N. Virginia      │         │  Falkenstein & Helsinki (EU) │
  │                              │         │                              │
  │   One region, today.         │         │   EU by default.             │
  │   No EU region to choose.    │         │   Every plan, including free.│
  │                              │         │                              │
  └──────────────────────────────┘         └──────────────────────────────┘

Vercel's own docs are upfront about it: "Sandboxes run on Vercel's secure infrastructure, which maintains SOC 2 Type II certification... For specific data residency requirements, consult your plan details or compliance team." SOC 2 is real and worth having. It isn't EU data residency, and for a sandbox running in Virginia under a US company, no certificate changes where the bytes are.

What's genuinely good about Vercel Sandbox

A few things Vercel does are better than what we do, and you should know them before you choose.

It publishes high self-serve concurrency. Vercel lists up to 2,000 concurrent sandboxes on Pro and 10 on Hobby. orkestr's published plan limits start lower - 1 on Starter, 5 on Pro, 15 on Team - with higher concurrency available on request. If a big self-serve fan-out number is what you're optimising for, Vercel lists it today.

It runs longer. Vercel sandboxes can run up to 45 minutes on Hobby and 5 hours on Pro. That's a real fit for long builds and long agent sessions.

Persistence is automatic. Vercel sandboxes are persistent by default - when one stops, the SDK snapshots the filesystem for you and resumes from it next time. No manual snapshot bookkeeping. It's a nice default.

It can run privileged workloads. Vercel lets you run things like Docker, FUSE filesystems, and VPN clients inside the sandbox. If your agent needs a container runtime inside its throwaway box, that's a capability worth naming.

So this isn't "US thing bad, EU thing good." It's a tradeoff. Vercel trades EU residency for scale and depth of integration. orkestr trades the headline concurrency number for code that never leaves Europe.

Where the two are the same

The boring truth is that most of the surface is shared, because this is a problem with a known-good shape.

• Each sandbox is a hardware-isolated microVM with its own kernel and filesystem - not a shared-kernel container. The isolation boundary is the same class on both.
• Python and JavaScript SDKs, plus a REST API, with the same create / run / read+write files / snapshot / terminate lifecycle.
• Pause and resume. Vercel persists by default; orkestr snapshots on pause() and restores on resume(). Same outcome, an agent can park mid-task.

Here's the orkestr Python SDK. If you've written Vercel Sandbox code, the shape will be familiar:

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

Performance is a wash. Vercel says sandboxes start "in milliseconds" and resume-from-snapshot is faster still. orkestr is around 150ms cold and under 30ms from a warm pool. Both are fast enough that your agent isn't sitting there waiting on a boot. The latency that actually matters is geography: if your users and your model API are on the US east coast, a sandbox in Frankfurt adds a transatlantic hop, and a Virginia sandbox doesn't. That cuts the other way, honestly - it's a fair reason to stay on Vercel if your whole stack is US-centric.

The one piece that is never in the EU, no matter who you pick

An agent is two machines: a model that decides what to do, and a sandbox that runs what it decided. Those are usually different companies. orkestr runs the sandbox. We do not run the model.

So when your agent decides to pip install pandas and parse this file, that decision came from whatever model you pointed it at. If that's a US model API, the prompt and completion are processed under that provider's terms, and that's your data processor to choose and your DPA to sign. What orkestr can promise is the other half: the code that runs, the files it touches, the snapshots it saves. All of that stays on EU hardware. 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 the working data stays home.

This is true of Vercel Sandbox too - it also doesn't run your model. The difference is that with Vercel, both the model call and the sandbox can be on US infrastructure. With orkestr, the sandbox half is settled.

Jurisdiction stacks on top of location

The physical-location problem is the headline, but jurisdiction makes it worse, not better. Vercel Sandbox is operated by Vercel Inc., a US company. Under the US CLOUD Act, a US-incorporated provider can be compelled to produce data it controls, and here the data is also physically in the US. There's no daylight between "where the bytes are" and "whose lawyer answers the subpoena" - they both point at Virginia.

With orkestr, the company that signs your DPA is the company that runs the sandbox, and it's an EU entity with no US parent. EU hosting isn't an enterprise tier or a region you request. It's where everything runs by default, free plan included.

Isolation is a tie, on purpose - both run each sandbox as its own hardware-virtualised microVM. Decide on the rows where the columns actually differ, and for most EU teams the first four rows are the whole decision.

Network egress: opposite defaults

This one matters the moment a model is writing the commands. Both platforms let you control what a sandbox can reach. They just start from opposite ends.

Vercel sandboxes "can make outbound HTTP requests by default" so package installs work, and you lock that down with firewall policies. orkestr starts closed and you open up:

# 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")

                    SAME CONTROLS, OPPOSITE STARTING POINT

  VERCEL SANDBOX                            orkestr
  ┌──────────────┐  add firewall            ┌──────────────┐  opt in
  │     open     │ ──────────────▶ closed   │     off      │ ──────────▶ open
  └──────────────┘                          └──────────────┘

  Internet on by default. You add          Nothing leaves by default. You opt
  rules to restrict what it can reach.     into restricted or open egress.

Neither default is wrong. But when the thing writing the commands is an LLM you haven't audited, default-closed is the safer place to start - a hallucinated curl evil.example.com fails until you decide otherwise.

When you're already on Vercel

There's one more reason Vercel Sandbox is attractive, and it's worth naming: it authenticates through Vercel OIDC tokens tied to your Vercel project. In production on Vercel, that auth is automatic. If your app already lives there, the sandbox is right there with it, no extra account.

That convenience is also the lock-in. The thing that makes Vercel Sandbox effortless if you're on Vercel is the same thing that makes it an odd standalone choice if you're not. orkestr sandboxes are a standalone product with a plain API key - you don't need to host anything else with us to use them.

When to pick which

Pick Vercel Sandbox if: you already deploy on Vercel, you want high self-serve concurrency out of the box, you want 5-hour runtimes or privileged in-sandbox workloads like Docker, and running in US-East is fine for your data.

Pick orkestr if: you're an EU company (or sell to one) and "our agent's code executes in Northern Virginia under a US company" is a sentence you don't want in a procurement doc - and you want EU residency to be the default on the free tier, not a region you have to request.

If that's you, you can start free - no waitlist, no card. Enable sandboxes from the console in one click, then create your first one from the dashboard or the SDK. If you want the longer story, here's why we built an EU sandbox for AI agents and a plain-language take on what a managed sandbox actually is. And if it's US-hosted infrastructure in general that's giving you pause, our Vercel breach checklist is in the same spirit.

FAQ

Can I run Vercel Sandbox in the EU?
Not today. Vercel's docs state sandboxes are "only available in the iad1 region," which is US East (Northern Virginia). There's no EU region to select, and no bring-your-own-cloud path for the sandbox product. If you need EU execution, you need a different provider.

Is Vercel Sandbox GDPR-compliant?
Vercel maintains SOC 2 Type II and can sign a DPA, and plenty of EU companies use Vercel under standard contractual clauses. But the sandbox itself runs in the US under a US entity, which means your agent's code and files are subject to the US CLOUD Act and to a transfer conversation. orkestr removes that conversation by keeping the runtime in the EU under an EU entity.

Is orkestr's isolation weaker than Vercel's?
No. Both run each sandbox as its own hardware-isolated microVM with a dedicated kernel - the boundary that keeps untrusted code from reaching the host or another tenant is the same class on both.

Does my model call stay in the EU?
The sandbox does - its code, files, memory, and snapshots. The model call is separate. If your agent uses a US-hosted LLM, that prompt and completion are processed by the model provider under your DPA with them. Use an EU model and the whole loop stays in Europe. This is true whichever sandbox you pick; neither orkestr nor Vercel runs your model.