Today we're releasing Tarit, an open-source KVM microVM platform for running AI agents and isolated workloads.
Tarit boots a hardware-virtualized machine with its own guest kernel, runs a task inside it, and tears it down. The workloads we care about create and destroy environments constantly: coding agents, browser workers, parallel evals, and RL environments that reset after every episode.
The repo ships two binaries and a shared protocol crate. vmm is a small Rust
VMM built on rust-vmm, one process per microVM. taritd places and manages
those VMs across a fleet. proto is the Unix-socket wire contract between them,
so the VMM can also run under someone else's control plane.
Why we didn't stop at Firecracker
Firecracker showed that a deliberately small device model on top of KVM gives you
a real VM boundary without the usual VM startup cost. We kept that idea, and
Tarit reuses parts of the rust-vmm ecosystem. What we needed above it was a
ready environment, reachable through one API, anywhere in a cluster.
Firecracker leaves that part to whoever runs it, on purpose. Its snapshot docs require the microVM and its vCPUs to be paused before a snapshot is taken, and state that Firecracker provides no functionality to package or manage snapshots on the host. Placement, warm pools, routing, capacity limits, and failover live in some other service.
We built that other service more than once, and it never worked well as a separate layer. Snapshot behavior, guest readiness, pool replenishment, disk cloning, and scheduling all depend on each other, so tuning one across an API boundary broke assumptions in the next.
So Tarit ships the VMM and the orchestrator together.
It's not a Firecracker-compatible fork. The VMM speaks length-prefixed JSON over a per-VM Unix socket instead of running an HTTP server. The device model is MMIO virtio only, no PCI, no BIOS. Exec and interactive PTY are first-class guest operations over vsock.
Snapshotting a VM that's still running
An agent can spend minutes cloning a repo, installing packages, or building an index. Freezing the guest for the length of a full memory copy stalls it right after that setup work finally paid off.
Tarit's live snapshot uses iterative pre-copy. It copies guest memory while the vCPU keeps executing, tracks the pages dirtied during the copy, and repeats until only a small residual set is left. Then it pauses the vCPU briefly, copies the remaining dirty pages, captures coherent CPU and device state, and resumes the source VM. Not zero downtime, but nearly all the work happens outside the pause window. Live snapshot is currently single-vCPU only.
Full and live snapshots share one format, so either restores the same way. Diff
snapshots carry dirty pages only. Restore can fault guest pages in lazily with
userfaultfd, with an eager fallback on hosts where it isn't available.
The warm pool is the fast path
Cold boot time is not the same as time to an interactive environment. The guest still has to start its init system, bring up the agent, and configure networking before anyone can use it. Doing that 100 times during a burst also steals CPU from the VMs already running work.
Tarit refills a pool with bounded cold boots or with snapshot restores. For a
restore-enabled warm class, taritd cold-boots one golden VM, waits for it to
become ready, snapshots it, and tears down the builder. Replenishment then
restores clones from that snapshot in the background. Guest memory is
copy-on-write and demand-paged; disks are a shared read-only base plus a writable
overlay per clone. A create leases a VM that is already up instead of entering
the boot path.
On a c8i.metal-48xl, a bounded cold-boot pool measured 38 ms p95 sequential and
56 ms p95 across a burst of 100 creates. That's one host and one configuration,
not a headline number. The failure was more instructive: 100 concurrent cold
boots starved live execs and pushed a later staggered run past its 30 s timeout.
Refill is bounded for that reason, and can run in a low-weight cgroup so
rebuilding capacity never outbids an agent doing real work.
One control plane, across many hosts
flowchart TB C["Client
API, CLI, or SSH"] --> N1 C --> N2 C --> N3 subgraph F["Tarit fleet"] N1["taritd node
warm pool + VMs"] N2["taritd node
warm pool + VMs"] N3["taritd node
warm pool + VMs"] end N1 <--> P[("PostgreSQL
membership, ownership, leader lease")] N2 <--> P N3 <--> P N1 -. "forward to owner" .-> N2
Every taritd node accepts public API traffic. PostgreSQL holds fleet membership
and the map from VM ID to owning host. A request that lands on the wrong node is
authenticated and forwarded to the owner. Placement looks at free VM slots,
vCPUs, and memory; a full cluster returns backpressure instead of half-creating a
machine.
Nodes heartbeat every 5 seconds and drop out of placement after roughly 15 seconds without a fresh one. A single node holds a 30 second leader lease for singleton work like autoscaling. If that node dies, a survivor takes the lease with no operator involvement, and losing a non-leader doesn't stop the rest.
This is control-plane failover, not live migration. A VM belongs to the host running its VMM process, and if that host dies its VMs die with it. Survivors keep serving, keep placing new work, and rebuild capacity. Snapshots are node-local by default, so cross-zone recovery means putting them on shared or object storage.
Agents and RL want the same primitive
An agent needs a machine it can break without you trusting the code it wrote to get there. It also needs exec, interactive sessions, network policy, usage accounting, and an audit trail. RL and eval systems arrive at the same place from a different direction: fan out many identical environments, run independent attempts, reset to an exact checkpoint, repeat.
Both reduce to one operation. Prepare an environment once, snapshot it, restore isolated copies into a warm pool, hand them out on demand. The VMM, the snapshot code, the guest channel, the scheduler, the pool manager, and the HA control plane live in one repo because that single operation runs through all of them.
Tarit is on GitHub at github.com/instavm/tarit. You'll need a Linux host with KVM.