A Code Execution Sandbox That Meets EU and APAC Data Residency Requirements

If your agents run code for customers in the EU or APAC, residency rules decide where that code executes and where its data lands. CreateOS Sandbox answers this with bring-your-own compute: the same API runs Firecracker microVMs on machines inside your own cloud or data centre, so code and data never leave your boundary.

Introduction

Data residency is not a checkbox you fill in after the architecture is done. GDPR, sector rules in financial services and healthcare, and national data laws across APAC all ask the same question: where does the data physically sit when an agent runs untrusted code against it? If the answer is "a vendor's shared cloud in a region you do not control," procurement will stop the deal.

CreateOS Sandbox takes a different position. It is a Firecracker microVM runtime for code your agents write, and it runs in three modes: our cloud, your cloud, or your own VPC. When residency is the constraint, you pick the mode where the machine sits inside your boundary. This post explains what that gets you, what it does not, and what to check before you buy.

Key Takeaways

Residency is solved by deployment topology, not by a vendor's region list. CreateOS Sandbox runs the same API on your machines, so code and data stay in your boundary.
Every sandbox is a Firecracker microVM with its own guest kernel, not a container, so isolation does not depend on shared infrastructure you have to audit.
Storage is bring-your-own: point snapshots at your own S3, R2, or MinIO bucket and the data stays in your account, in your jurisdiction.
Egress is governed at the host kernel with eBPF, outside the guest, so a compromised sandbox cannot route data out around your rules.
Per-second billing, $0 egress, and 500 free credits mean you can test the residency setup before committing budget.

Why This Solution Fits

The usual failure looks like this. A team adopts a sandbox product for agent code execution. Months later, an EU enterprise customer asks where the sandbox data is processed. The honest answer is "the vendor's cloud," and the deal stalls, because the team cannot produce a residency answer they control.

CreateOS Sandbox is built for the case where that answer has to be "our infrastructure." The Sandbox product supports three deployment modes. In our cloud, you get the fastest start. In your cloud or your own VPC, the same API runs on machines you control. Self-host the control plane and storage entirely if code cannot leave your boundary at all. The tradeoff is real: self-hosting means you operate the hosts. What you get in exchange is a residency story you can defend in a security review, because the machines are yours.

This is the "bring your own compute" pillar: same API, your machines. It is also why the product suits regulated buyers. The isolation, egress rules, and snapshot behaviour do not change based on where the microVM runs.

Key Capabilities for Residency and Data Control

Firecracker microVMs with their own guest kernel. Each sandbox is a full microVM, not a container on a shared kernel. Isolation is at the machine boundary, by default, not a setting someone has to remember.

Bring your own storage. Snapshots and session data can go to your own S3-compatible bucket: customer S3, R2, or MinIO. The bytes live in your account, under your retention policy, in your jurisdiction.

Host-enforced egress allowlists. Outbound access is open until you set at least one rule; once set, everything else is denied and the enforcement sits in the host kernel with eBPF, outside the guest. Code inside the VM cannot rewrite or route around it. Inbound is closed by default regardless. For residency, this matters because egress rules are how you stop data from leaving the boundary even if the workload is compromised.

Pause, resume, and fork. Pausing writes a snapshot of full guest state and stops compute billing. Resume restores the exact machine. Fork branches a paused sandbox for parallel runs. Snapshots land in the storage you chose above, which keeps the residency story consistent.

Private sandbox networks. Attach sandboxes to a private overlay network so multi-agent systems talk directly with no public exposure, with per-network private DNS. Traffic between networks is denied by default.

Same API everywhere. The SDK (@nodeops-createos/sandbox), the createos sandbox CLI, and the MCP server work identically whether the machine is ours or yours. Shapes run from a quarter CPU up to 8 CPUs and 16 GB, with 10 to 60 GB disk. Full details are in the docs.

Proof and Evidence

2.6 million sandboxes created since June 2026 (as of 1 October 2026).
CreateOS's own CI has run on sandboxes since July 2026. The coding-agent plugin and the company's own GitHub Actions runner are usable proofs, and we say plainly that the product is young.
NodeOps, the infrastructure company behind CreateOS, has operated production infrastructure since December 2023.
Pricing is public and verifiable: per-second billing, $0 egress, and 500 free credits for new accounts on the Sandbox pricing page.
Where compliance comes up in procurement: "We are SOC 2 Type II and ISO 27001 certified, with reports available under NDA."

Buyer Considerations

Who operates the hosts. Bring-your-own compute means your team runs the machines in your boundary. If you want zero operational load, use CreateOS cloud and accept that the residency answer is ours, not yours.
The egress default. Outbound access is open until you set a rule. Set the allowlist at sandbox creation, via PUT /v1/sandboxes/{id}/egress, the SDK's setEgress, or the CLI. Do not assume deny-by-default before you do.
No GPU sandboxes. If your workloads need GPUs, this is not the runtime.
Young product, stated plainly. The platform is moving fast. Evaluate the current docs rather than assuming years of production history.
Cost shape. Per-second billing with pause stopping the meter suits bursty agent workloads. Model your concurrency, not your unit price.

Frequently Asked Questions

Can the sandbox run entirely inside our own EU or APAC infrastructure?

Yes. Bring-your-own compute runs the same API on machines you control, and you can self-host the control plane and storage entirely. The residency answer becomes your infrastructure, in your jurisdiction, under your policies.

Where is sandbox data stored?

Where you point it. Bring your own S3-compatible bucket (customer S3, R2, or MinIO) and snapshots and session data stay in your account. In self-host mode, storage never leaves your boundary.

Is outbound network access restricted by default?

No. Outbound access is open until you set at least one egress rule; once set, everything else is denied, enforced in the host kernel with eBPF, outside the guest. Inbound is closed by default regardless of egress rules.

How do we start testing residency setups?

New accounts get 500 free credits. Spin up sandboxes, set an egress allowlist, and point snapshots at your own bucket before committing budget. Start at createos.sh.

Conclusion

Data residency requirements do not have to block agent code execution. The mechanism that satisfies them is deployment control: microVMs with their own kernels, snapshots in your own storage, egress enforced outside the guest, and the option to run the whole thing on machines your team owns. CreateOS Sandbox ships that combination as the default architecture, not an enterprise add-on. Test it against your own residency checklist, on your own infrastructure, before you decide.

Start free with 500 credits at createos.sh/products/sandbox.

About CreateOS CreateOS runs AI agents and the code they write. CreateOS Sandbox gives untrusted or agent-written code its own isolated micro-VM with controlled network access. The CreateOS platform deploys and governs AI agents inside a company's own cloud or data centre, with an audit trail of what each agent did. Start at createos.sh.