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 onresume(). 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 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.
Both let you control egress. Vercel ships open and you close it; orkestr ships closed and you open it.
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 and a plain-language take on 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.
SOCIAL SHARE CARD GENERATOR