Every Agent runs its commands inside a sealed sandbox, never on the server itself. Two engines can build that sandbox. Which one you can use depends on one thing: does the server give access to CPU virtualization (KVM)?
The CPU hardware builds the wall. Each Agent gets its own Linux kernel.
/dev/kvm on the serverA Linux kernel written as a normal program catches every request from Agent code.
Same for both: the same signed images, the same /workspace, the same network rules through our egress proxy. Agents cannot tell which engine they run on.
A physical machine. Best speed and the most Agents per server.
The hypervisor passes virtualization into the VM. Works, but it is a VM inside a VM. The cloud or hypervisor admin must enable it.
Most ordinary cloud VMs and managed Kubernetes nodes. Firecracker cannot start here.
| Install type | Bare metal | VM + nested virt | VM, no nested virt |
|---|---|---|---|
| Docker Compose | Firecracker | Firecrackerslower | no local sandboxesRun the sandbox Runner on a separate KVM host |
| Kubernetes (#657) | gVisor | gVisor | gVisorthe main target |
Kubernetes nodes are usually cloud VMs without KVM, and SecondBox supports only its gVisor Runner as a Kubernetes pod. So the Kubernetes install needs no virtualization at all.
“We have an ordinary cloud VM.”
Kubernetes install with gVisor. It runs anywhere.
“We run many Agents.”
Bare metal with Firecracker: the fastest and strongest option.
“We run our own hypervisor.”
Enable nested virtualization to get Firecracker; otherwise use gVisor.