Self-host an agent sandbox or use a managed one?

Should you self-host a sandbox or use a managed one?

It depends on where the code must run and who will run the hosts. When the sandbox is a means to your product, Runtime already runs the stack: a Firecracker microVM per sandbox and a host-side egress proxy, at $0.025 per vCPU-hour of measured CPU. Self-host if the code must stay inside your own network or cloud account, needs hardware or a kernel no provider offers, or must keep data in a country other than the US, since Runtime runs in Virginia.

What self-hosting involves

The open-source parts exist: Firecracker, gVisor and Kata Containers. What they leave to you is everything around the virtual machine. Firecracker's own documentation is specific about it.

The work	What Firecracker's documentation says
Hosts with KVM	It "requires read/write access to `/dev/kvm`"; on AWS, "EC2 only supports KVM on `.metal` instance types"
A guest to boot	You provide "an uncompressed Linux kernel binary, and an ext4 file system image"
Confinement	Start it "using the `jailer` binary"; keep the default seccomp filters, "the recommended option for production usage"
Host hardening	Disable SMT "in production scenarios that require tenant separation", disable Kernel Samepage Merging, disable swap
CPU, memory and disk	Cgroup controls for block I/O, memory and CPU, which you configure
Networking	A TAP device per microVM on the host, with routing and NAT you set up
Egress control	"Firecracker does not perform any network traffic filtering... Firewall rules should therefore be implemented on the host"
Floods	Network rate limiters, configured per interface
Logs	The host is responsible for "consuming and storing this data safely"

Then comes the product on top: an API to create, run commands in, pause and delete machines; images; storage; scheduling across hosts; billing per tenant; and patching the host kernel against each new hardware vulnerability. Firecracker tells you to track these in "the very latest Linux kernel documentation".

The part people forget: other people's traffic

Model-written code, or a user's, will eventually try something it should not. On a self-hosted fleet, you answer for it.

Your own network and cloud. A sandbox that can reach private addresses can reach your databases and your cloud's metadata service, which on EC2 is 169.254.169.254 and serves the instance's role credentials.
Abuse from your addresses. Scans, spam and floods leave from your IP addresses, and the complaint goes to your hosting provider. You need to trace each connection to one sandbox and one customer within minutes, and cut it off.
Content you serve. A sandbox's web server reachable at your domain shares that domain's reputation unless it gets a domain of its own.

What Runtime runs for you

Concern	On Runtime
Isolation	A Firecracker microVM with its own Linux kernel and disk, on dedicated servers Runtime operates
Outbound traffic	No network card in the guest; every connection goes through a proxy on the host
Private addresses	Refused, for every sandbox, root included
Your rules per sandbox	Allow and deny lists, extra `host:port` pairs, or no internet, changed at any time
Ports	Telnet, Windows RPC, SMB and IRC never reachable; mail ports closed unless support opens them
Crowding	Per-sandbox limits on connections, bandwidth and bytes a day; disk I/O capped per sandbox
Tracing	Every connection logged with the sandbox, the account and the client's address, no contents
Served content	Previews live under `runtimehost.com`, never under Runtime's own domain
Runaway machines	Time limits and credit are enforced on the host, outside the sandbox
Keys	Secrets the sandbox never holds; the host's proxy adds them to requests to named hosts
Spending	A daily limit per key and `maxTotalCostMicros` per sandbox

Root inside a sandbox cannot change any of it. Network rules, CPU, memory and cost are enforced on the host (security).

The Runtime equivalent

The self-hosted checklist, as create options:

TypeScriptimport { Sandbox } from "withruntime";await using sbx = await Sandbox.create({  network: { internet: true, allow: ["pypi.org", "*.pythonhosted.org"] },  timeoutSeconds: 900, // the host stops it after 15 minutes  onLeaseEnd: "stop",  maxTotalCostMicros: 100_000, // stopped once it has cost $0.10});console.log(await sbx.network.get()); // private and internal addresses are refused on top

Pythonfrom withruntime import Sandboxwith Sandbox.create(    network={"internet": True, "allow": ["pypi.org", "*.pythonhosted.org"]},    timeout_seconds=900,  # the host stops it after 15 minutes    on_lease_end="stop",    max_total_cost_micros=100_000,  # stopped once it has cost $0.10) as sbx:    print(sbx.network.get())  # private and internal addresses are refused on top

What it costs

Self-hosting's bill is the servers you rent, plus the engineering time to build and run everything above. Both depend on your fleet, so this page gives no figure for them. Runtime's bill is per sandbox. A 2 vCPU, 4 GiB sandbox costs $0.03125 an hour while its code waits and $0.08 an hour with both CPUs busy, with no plan fee. 1,000 one-minute runs using 20 CPU-seconds each cost $0.64 (pricing).

Which one fits

Self-host when the code must run inside your own network or cloud account, when you need hardware or a kernel no provider offers, or when you already operate a KVM fleet with people on call for it.
Use a managed sandbox when the sandbox is a means to your product. The isolation, egress control and abuse handling are already built, tested and watched.

Runtime runs in one region, in Virginia. A requirement to keep data in another country points to self-hosting or another provider.

More: what is a microVM?, egress control, Firecracker vs gVisor, Kata Containers vs Firecracker, turn off sandbox internet.

Runtime Cloud

On Runtime, the whole stack already runs: a Firecracker microVM per sandbox, a host-side egress proxy, per-sandbox limits and connection logs. The rates are $0.025 per vCPU-hour of measured CPU and $0.0075 per GiB-hour of memory. Self-hosting buys control of where the machines sit, and the work above comes with it.

Start free, with 100 free hours of a 1 GB machine in the first 30 days and no card:

Terminalnpx withruntime sandboxes run -- uname -r

If a sandbox provider runs your code today, the migration guide moves it to Runtime on a branch.

Sources

Checked 26 October 2026.

Facts on this page were checked on 26 October 2026.