How Zeish works

The control plane, the data plane, and why sandboxes are cheap to clone but hard to escape.

Zeish splits every sandbox into two planes with different trust levels. The control plane owns organizations, sandboxes, snapshots, and permissions, and is what your API key talks to. It records desired state, then drives the underlying MicroVM through an asynchronous lifecycle — creates typically return a pending sandbox immediately, and you poll (or watch events) until it reaches running.

The data plane is the sandbox itself: a MicroVM with its own kernel, not a shared-kernel container. Firecracker is the default, fully verified runtime for every sandbox; Cloud Hypervisor is a second runtime driver rolling out node by node behind the same lifecycle API, for workloads that need capabilities Firecracker doesn't expose. Whichever runtime backs a sandbox, it boots from a minimal guest image whose init process brings up networking, starts your workload, and supervises a small in-guest agent that exposes exec, filesystem, and terminal access. That agent only accepts short-lived, sandbox-scoped credentials minted by the control plane — your organization API key never talks to the sandbox directly.

Snapshots and cloning share the same mechanism: a snapshot freezes a sandbox's memory and disk state so a new sandbox can restore from it in a fraction of the time a cold boot takes, instead of repeating dependency installs and setup scripts on every run. This is what makes fan-out (evals, retries, parallel agent branches) cheap — every branch clones from one prepared checkpoint rather than re-provisioning from scratch.