Sandboxes

Code from a user, a model or a pull request you haven't read belongs somewhere it can do no harm. A box is that place: a Firecracker microVM with its own kernel, so the code runs behind a hardware boundary, not a shared kernel like a container's. Nothing on the host is visible from inside, and boxes cannot reach each other unless you link them.

Run it and throw it awayCopy Anchor Link

kvbox new sb --size xs
cat untrusted.sh | kvbox exec sb --timeout 30 --json -- 'cat > /tmp/run.sh && bash /tmp/run.sh'
kvbox rm sb -y

exec hands back the command's exit code; with --json you get {"output": "...", "exit_code": N}. --timeout kills the command after that many seconds and exits 124. Stdin flows through, so code and data go in without touching your own files (Connect and exec).

Start every run cleanCopy Anchor Link

Booting is a few seconds; a clone of a snapshot is well under one. Set a box up once, with the runtimes and libraries the code may need, snapshot it, and start each run from it:

kvbox new sandbox --size xs                     # install what the code may need, then:
kvbox snapshots new sandbox sandbox-ready

kvbox new --from sandbox-ready run-17 --json
cat untrusted.sh | kvbox exec run-17 --timeout 30 --json -- bash
kvbox rm run-17 -y

Whatever one run did, the next starts from the same untouched state.

Things to knowCopy Anchor Link

• A box reaches the internet, and every box gets its owner's variables. Make sandbox boxes in an org that has no secrets, so untrusted code finds none to send out.
• Size the box for the job: xs is 1 vCPU and 2 GB of RAM, so a runaway program fills its own box and nothing else.
• Don't publish ports or claim an address on a sandbox unless you mean to expose what runs in it.