Run untrusted code in its own machine.
Run user- or AI-generated code inside a microVM with its own kernel and no network access by default, protected by an encryption key that is destroyed the moment the machine is released. Built for code you have every reason not to trust.
- cold create
- <1s
- cold create
- warm claim
- <200ms
- warm claim
- kernel per exec
- 1
- kernel per exec
- egress
- default-deny
- egress
Regular containers share one kernel.
A standard container runs on the host’s kernel next to everyone else’s. That shared kernel is an escape route you patch forever instead of removing. Running code you didn’t write, from a user or a model, right beside your own workload is a bet that eventually goes wrong.
- Kernel isolation
Shared kernel = shared blast radius
One container escape reaches the host and its neighbours. A microVM has its own kernel, so there is nothing next door to escape into.
- Secret handling
Secrets leak through the filesystem
A token written into the guest is a token the code can read. Injecting it at the edge keeps it out of the guest entirely.
- Data deletion
Deletion you have to trust
Wiping a disk is a step that can fail. Destroying the only key that decrypts it leaves unrecoverable ciphertext, nothing to trust.
A fresh, locked-down machine per run.
Boot in under a second, run the code behind its own kernel, take the result, and leave nothing behind.
- 01
Start with no access
A microVM starts with no outbound network and its own isolated stack. It can reach nothing, not the host, not another customer, not the internet.
- 02
Run the code
Execute the untrusted code against its own kernel. The worst case is a wasted machine, not a compromised host or a leaked secret.
- 03
Take the result
Read stdout, stderr and the exit code, or pull a file off the disk. Outbound access opens only for the specific hosts you allow.
- 04
Leave nothing behind
Releasing the machine destroys the encryption key unique to it. Whatever is left in storage is ciphertext no one can read.
Isolation that doesn’t depend on the guest.
- 01
A kernel per run
Hardware-isolated microVMs, each with its own kernel, not a shared-kernel container.
- 02
No network by default
Outbound access starts at zero; you list the exact hosts the code may reach.
- 03
Secrets stay outside
Credentials are attached at the edge, so a token is never a file the running code can read.
- 04
Per-run keys
Every snapshot is encrypted with a key scoped to that one workload and destroyed on release.
- 05
Millisecond starts
Warm pools claim a sealed machine in under 200ms, so per-request execution stays cheap.
- 06
Per-second billing
A 400ms execution bills 400ms, no minimum, no per-invocation fee.
The products that power it.
Safe execution runs on the same microVM core as the rest of the platform.
1from sandal import Sandbox
2
3# boot a desktop the agent can see
4vm = Sandbox.create(desktop=True)
5vm.screenshot("before.png")
6
7vm.click(x=412, y=280)
8vm.type("hello from the agent")
9vm.key("cmd+s")
10
11# read the screen back
12frame = vm.stream.latest()
13assert frame.contains("Saved")
➜ sandbox sandal desktop --stream
connecting to vm_7c31…
✓ stream open · 60fps · 18ms latency
screenshot → before.png
click(412, 280) · type · cmd+s
✓ saved
➜ sandbox
Run the code you didn’t write.
A sealed microVM per execution, gone on release. Free tier included, no card to start.
