Bring Your Own Dockerfile: A Sandbox Service Built for Agent Runtimes

CreateOS Sandbox is a sandbox service that runs agent runtimes from your own Dockerfile. Define the environment once, and every session runs it inside a Firecracker microVM with its own guest kernel. Egress rules are enforced on the host, billing is per second, and new accounts start with 500 free credits.

Introduction

An agent runtime is not a demo environment. It is the place your product actually runs: a pinned interpreter, a system library, a headless browser build, a certificate your security team issued. Managed sandboxes answer with fixed templates. When the template lacks what you need, you install it at boot on every session, or you file a ticket and wait for a vendor image.

That definition belongs in a file. A Dockerfile pins the runtime next to the code, in review, in version control. CreateOS Sandbox takes that file and runs it. Bring your own Dockerfile, and every session gets the environment you defined, on its own machine.

Key Takeaways

Your Dockerfile defines the agent runtime. Default templates (Ubuntu 26.04 with Node 22, Bun, Python 3.12, Go 1.26, Rust 1.83) cover the common cases when they fit.
The image controls the inside. The boundary stays a Firecracker microVM with its own guest kernel, not a shared-kernel container.
Egress rules are enforced in the host kernel with eBPF, outside the guest. Outbound is open until you set a rule; once set, everything else is denied.
Pause, resume and fork turn one runtime into many runs. Pause takes about 1.4 s, and same-host resume is under 0.7 s.
Billing is per second with $0 egress, and pausing stops the meter. New accounts start with 500 free credits.

Why a Dockerfile Sandbox Fits Agent Runtimes

Code your agents write is code you cannot fully trust. That fact shapes every requirement below.

First, the environment has to be yours. Agents need internal packages, specific toolchains, browsers, language servers. When the platform owns the image, your product inherits its limits. A Dockerfile moves the definition into your repo, where it is reviewed and versioned like everything else you ship.

Second, the isolation cannot depend on the image. A custom Dockerfile is arbitrary code at build time and mutating code at run time. CreateOS Sandbox runs each session as a Firecracker microVM with its own guest kernel. The boundary is the machine itself, not a container setting someone has to remember.

Third, the network rule has to sit where the code cannot reach it. The egress allowlist is enforced in the host kernel with eBPF, outside the VM. Code inside a custom image cannot rewrite it or route around it. That is the difference between a policy and a suggestion.

Key Capabilities

Inside the machine, your Dockerfile rules. Install the toolchain, pin the versions, bake the certificates. Shapes run from a quarter CPU up to 8 CPUs with 16 GB of memory, and disk goes from 10 to 60 GB, so a heavy runtime fits.

At the boundary, the platform rules. Set the egress allowlist in the egress field at create time, apply it live through PUT /v1/sandboxes/{id}/egress with no restart, call the SDK's setEgress method, or run createos sandbox firewall set from the CLI. Rules take a host, a host:port pair, wildcard subdomains, IPs and CIDRs. Outbound is open until the first rule exists. After that, everything else is denied. Inbound is closed either way.

Around the machine, the runtime tools. Pause writes a snapshot of full guest state and stops the compute meter. Resume restores that exact machine. Fork branches a paused sandbox into parallel runs, so you can try N candidate fixes and keep the winner. Multi-agent systems get private overlay networks with per-network private DNS, so agents find each other by name with no public exposure.

What Is Proven, and What Is Young

The numbers first. 2.6 million sandboxes have been created since June 2026. CreateOS's own CI has run on sandboxes since July 2026. Uptime is 99%+. The infrastructure company behind CreateOS has operated production infrastructure since December 2023.

Now the frame, stated plainly: this is a young product. The Dockerfile path is a shipped capability, not a roadmap item. What is not shipped matters too. Compliance certifications are on the roadmap for the Sandbox surface, and there are no GPU sandboxes. If either is a requirement, plan for it now.

What to Weigh Before You Move Your Runtime

Egress is not restricted by default. Isolation is on by default; the egress allowlist is not. Outbound stays open until you set the first rule. If your threat model assumes deny-by-default networking, set the allowlist at create time and say so in your review.
No GPUs. Runtimes that need GPU inference need a different home.
Certifications are roadmap items on this surface. The trust story here is the machine boundary, the host-enforced egress allowlist, and bring-your-own: your S3, R2 or MinIO bucket, your compute, your VPC.
Fit runs one way. This is for code you cannot fully trust: agent-written, customer-written, dependency-updated. If every line is written and reviewed by your own team, a plain container setup may serve you fine.

Frequently Asked Questions

Can I bring my own Dockerfile to CreateOS Sandbox?

Yes. That is the design: define the agent runtime in your own Dockerfile and every session runs it. Default templates ship for the common cases, Ubuntu 26.04 with Node 22, Bun, Python 3.12, Go 1.26 and Rust 1.83, so you maintain a Dockerfile only when the runtime needs more.

Does a custom image weaken the isolation?

No. The image defines what is inside the machine. The boundary is still a Firecracker microVM with its own guest kernel, and the egress allowlist is enforced in the host kernel with eBPF, outside the guest, where code inside the image cannot touch it.

Is outbound traffic blocked by default?

No. Outbound access is open until you set at least one egress rule; once set, everything else is denied. Inbound is closed by default regardless. Set rules at create time, apply them live through the API, or use the SDK's setEgress method or the CLI.

What does a custom agent runtime cost to run?

Billing is per second, egress is $0, and pausing stops the meter. Shapes run from a quarter CPU up to 8 CPUs with 16 GB of memory and 10 to 60 GB of disk. New accounts start with 500 free credits, and current pricing is at createos.sh/pricing/sandbox.

Conclusion

The runtime your agent runs in is part of your product. Define it in a Dockerfile, keep it in review, and run it on a machine boundary with the network policy enforced where the code cannot reach. CreateOS Sandbox runs that file on Firecracker microVMs, billed by the second, in our cloud or yours.

Start free with 500 credits at createos.sh/products/sandbox, or read the docs first.

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.