Running code you didn't write

A year ago, running code you hadn't read was an edge case. Now it's the main loop. An agent writes a script, and something has to execute it — usually within a second, usually dozens of times an hour, usually on a machine that also has your database credentials on it.

The reflex is a container. Containers are excellent at packaging and scheduling, and they were never designed to be a security boundary against code that is actively trying to get out. Every container on a host shares one kernel. A kernel bug is a host compromise, and the kernel is the largest attack surface you have. That's a reasonable trade for your own code. It is a strange one for code an LLM produced forty milliseconds ago.

A kernel each

Sistemo gives every sandbox its own Firecracker microVM: its own kernel, its own memory, its own virtual disk. An escape has to get through the guest kernel, then through the VMM, and the VMM is not running as root — it's a jailed process under an unprivileged uid in a pivot_root chroot that contains the kernel image and that one VM's disks. Nothing else on the host is reachable from inside it.

The network is closed by default too. A sandbox reaches the internet and nothing else: not other tenants' sandboxes, not the private mesh, not cloud metadata, not the host's own services. That's enforced twice, at layer 2 on the bridge and again in nftables, because one of those failing quietly is exactly the kind of thing you only discover afterwards. There is no SSH daemon in any image — exec and the terminal ride a vsock channel to a small agent baked into the guest, so there is no listening port and no key to leak.

The number that actually matters

Isolation like that has a reputation for being slow, and the reputation is what keeps people on containers. So: a sandbox is ready in about 0.9 seconds, measured end-to-end on a production host — API call to a shell that will answer you. Readiness has a median of 0.685s and, more usefully, no long tail. That is fast enough to sit inside an agent loop rather than around it.

It gets there by cloning a ZFS template rather than building anything, growing the filesystem inside the guest instead of offline on the host, and refusing to call a machine ready until it can actually serve a shell. The last one sounds pedantic and isn't: reporting ready a second early means your first command fails for reasons you cannot see.

Prepaid, because surprise invoices are a product decision

Billing is a wallet, not a subscription. You top it up; usage draws it down per second — €0.035 per vCPU-hour, €0.012 per GiB of RAM-hour, €0.050 per GB-month of storage. A 1 vCPU / 1 GiB sandbox is about €0.047 an hour.

At €0 the machines pause. There is no overage, no credit line, and nothing to reconcile at the end of the month, because your balance is the spend cap. The failure mode of metered billing is a runaway loop and a five-figure invoice, and an agent that writes its own code is exactly the thing that produces one. Capping it by construction seemed better than emailing you an alert.

The hosts are in the EU, and the default resolver is Quad9 — Swiss-operated, and not two American providers seeing every domain your sandboxes look up. If that detail matters to you, you already know why.

Where this actually is

Everything above is built and running. What is not open is the front door: signups are invite-only while we work through the waitlist in batches, and the Python and TypeScript SDKs publish to PyPI and npm when they do. The SDK source is public on GitHub today — about six hundred lines of dependency-free HTTP, which is short enough to read before you hand it an API key. That's rather the point of publishing it.

When you do get in, the whole thing is three lines:

from sistemo import Sandbox

with Sandbox() as sb:
    print(sb.run("python3 -c 'print(2 + 2)'").stdout)

Expect capacity limits and rough edges — that is what a beta is. What you should not expect is a quiet charge for something we called a trial. If something is broken or wrong, or if the isolation model doesn't hold up to how you plan to use it, I'd genuinely like to hear about it: [email protected].

— Davide