Self-Hosted Sandbox for Agent Code That Cannot Leave Your VPC

CreateOS Sandbox runs agent-written code in Firecracker microVMs on machines inside your own VPC. The same API that powers our cloud runs on your infrastructure, snapshots land in your own S3, R2, or MinIO bucket, and the egress rules you set are enforced in the host kernel, outside the guest.

Introduction

Every platform team building with coding agents hits the same wall. The agent needs to write and execute code. Your security team needs that execution contained, inside your boundary, on infrastructure you can point to in an audit. Public sandbox APIs are fast, but they run on someone else's machines, and "trust us" is not a network policy.

So the real question is the one in the title: can untrusted agent code run in a sandbox that lives in our VPC, where it cannot reach anything we have not allowed? With CreateOS Sandbox, the answer is yes. The rest of this post is the mechanism, and the tradeoffs your review should name.

Key Takeaways

Self-host is a deployment mode, not a special order. Bring your own compute runs the same CreateOS Sandbox API on machines inside your VPC, so the workload executes in your boundary.
One kernel per session. Every sandbox is a Firecracker microVM with its own guest kernel, not a container on a shared runtime.
Egress you define, enforced outside the guest. Outbound access is open until you set at least one rule. Once set, everything else is denied, and enforcement sits in the host kernel with eBPF. Inbound is closed by default either way.
State stays in your storage. Pause, resume, and fork write snapshots to your own S3, R2, or MinIO bucket.
Same code either way. The API, CLI, and SDK behave identically whether the sandbox runs in our cloud or on your machines.

Why a Self-Hosted MicroVM Sandbox Fits This Requirement

The requirement has three parts. Each one maps to a specific design decision, not a promise.

Self-hosted. Bring your own compute means CreateOS Sandbox runs on machines you provision inside your VPC. You can go further and self-host the control plane and storage entirely, which is the path built for exactly this case: code that cannot leave the boundary. Your existing tooling keeps working, because the API surface does not change with the hardware.

Agent code. Code an agent wrote is code nobody reviewed line by line. It needs its own machine per session. A Firecracker microVM gives every sandbox its own guest kernel, so a compromised session hits a machine boundary instead of your host.

Cannot leave the VPC. Two controls do this work. Placement is the first: the sandbox runs on your hardware, inside your network. Egress is the second: you set an allowlist per sandbox, and the rules are enforced in the host kernel with eBPF, outside the VM. Code inside cannot rewrite them or route around them. A full guest compromise does not remove them either.

Key Capabilities

Placement and compute. Deployment options are our cloud, your cloud, or your own VPC. In the self-hosted shape, sandboxes run on customer machines through the same API. Shapes scale from a quarter CPU up to 8 CPUs and 16 GB of RAM, with 10 to 60 GB of disk per sandbox.

Egress governance. Set rules four ways: the egress field at sandbox create time, the PUT /v1/sandboxes/{id}/egress endpoint, which applies live with no restart, the SDK's setEgress method, or the CLI's createos sandbox firewall set command. Rules accept hosts, host:port, wildcard subdomains, IPs, and CIDRs. Enforcement is eBPF in the host kernel. The default matters: outbound is open until the first rule exists, so write the allowlist into provisioning, not into a follow-up ticket.

State and networking. Pause writes a snapshot of full guest state and stops compute billing, in about 1.4 seconds. A same-host resume completes in under 0.7 seconds. Fork a paused sandbox to branch agent state for parallel rollouts. Snapshots go to a bucket you own: S3, R2, or MinIO. For multi-agent systems, private overlay networks let sandboxes talk directly with no public exposure, with per-network private DNS and traffic between networks denied by default.

Proof & Evidence

Numbers first. 2.6 million sandboxes have been created since June 2026. CreateOS's own CI has run on sandboxes since July 2026, and the company's GitHub Actions runner and coding-agent plugin exercise the same path you would run. Uptime has held above 99%. The infrastructure underneath is operated by NodeOps, the infrastructure company behind CreateOS, in production since December 2023. Traces and usage dashboards are live today.

Now the young parts, stated plainly. CreateOS Sandbox is a young product. Compliance certifications are on the roadmap for the Sandbox surface, not shipped. If your review requires certification artifacts, name that gap in the evaluation and decide whether kernel-level isolation plus self-host placement covers the interim risk. That tradeoff deserves a decision, not a footnote.

Buyer Considerations

You operate the hosts. Self-host moves the machines into your VPC, and their capacity, patching, and monitoring come with them. Budget the platform-team time.
Egress is not restricted by default. Outbound access stays open until you set a rule. Make the allowlist part of sandbox provisioning from day one.
Certifications are roadmap items on the Sandbox surface. If your gate needs them today, scope the interim controls explicitly.
Billing is per second and egress is $0, so cost tracks usage rather than transfer. Pausing a sandbox stops the meter.

Frequently Asked Questions

Can the sandbox run entirely inside our VPC?

Yes. Bring your own compute runs the same CreateOS Sandbox API on machines you provision inside your own VPC, and you can self-host the control plane and storage entirely. The workload executes in your boundary, under your network policies.

Is outbound traffic blocked by default?

No. Outbound access is open until you set at least one egress rule. Once a rule exists, everything else is denied, and enforcement runs in the host kernel with eBPF, outside the guest. Inbound is closed by default regardless of your egress rules.

Where do snapshots and agent state live?

In a bucket you own. Pause, resume, and fork write memory-plus-disk snapshots to your own S3, R2, or MinIO bucket, so agent state stays inside your storage boundary.

How do we set the egress allowlist?

Four ways: the egress field at sandbox create time, the PUT /v1/sandboxes/{id}/egress endpoint, which applies live with no restart, the SDK's setEgress method, or the CLI's createos sandbox firewall set command. Rules accept hosts, host:port, wildcard subdomains, IPs, and CIDRs.

Conclusion

If the requirement is that agent code cannot leave your VPC, the evaluation is short. Run the sandbox on your machines. Give every session its own kernel. Set the egress allowlist before the first sandbox starts. Keep snapshots in your own bucket. CreateOS Sandbox does all four through one API, and the same code runs self-hosted or in our cloud.

See the Sandbox product page for the self-host topology, the docs for the API and CLI, and sandbox pricing for per-second billing. If you are staging a design-partner conversation, bring your network diagram and your egress policy. We will map both onto the deployment in the first call.

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.