Every compute primitive you’ve ever used runs on a single timeline. Boot, execute, terminate. You make a decision, you commit to it, and if it’s wrong you start over. That was never an architectural choice. It was an implementation limit. Forking a machine was too slow to be useful as a primitive, so we all built systems that pretend the option doesn’t exist. Snapshots as a rare operation. Checkpoints as a batch job. State as a thing you tear down rather than branch. Vers removes the implementation limit. Branching a running VM takes 258µs — memory, processes, sockets, and all. Once branching is that cheap, you stop designing around its absence. You start designing around its presence.Documentation Index
Fetch the complete documentation index at: https://docs.vers.sh/llms.txt
Use this file to discover all available pages before exploring further.
A different primitive
Think about whatfork() did for Unix. Before it, programs had to serialize, write state to disk, and relaunch to do anything that looked like multitasking. After it, forking was something you did in a tight loop, and a whole class of software — shells, web servers, init systems — became natural to build.
Vers is that primitive for whole machines. Four calls:
vers run | Boot a root VM |
vers branch | Fork a live VM in 258µs |
vers commit | Freeze any state as an immutable, content-addressable snapshot |
vers run-commit | Restore any snapshot, anywhere, forever |
What becomes possible
When forking is free, the shape of the software you can build changes:- Agent swarms. Fork one golden VM into a thousand, let agents explore in parallel, keep the winners. See agent swarms.
- CI preview environments. Branch a known-good state at HEAD, boot a preview for every PR in microseconds, tear them down on merge. Zero state drift.
- Rollback as a one-liner. Commit before every risky change. If the change is wrong,
vers run-commitand you’re back — with memory, running processes, and sockets intact. - Durable long-running LLM tasks. Checkpoint at every tool call; if something crashes you resume from the last known-good state instead of re-running an expensive chain.
- Stateful end-to-end testing. Set up a complex state once, branch to exercise every permutation from that state in parallel.
What you use today, and why Vers is different
Most compute platforms are single-timeline by design. They’re excellent at what they do. The distinction isn’t “better” or “worse” — it’s primitive vs. derived. Vers is the primitive; single-timeline tools give you fragments of branching by rebuilding state from scratch.Sandbox platforms (E2B, Modal, Daytona)
Sandbox platforms boot a fresh VM, run something, throw it away. They’re great for stateless isolation — function execution, tool use, ephemeral evaluation. What they can’t do is fork a running state tree.| Vers | Ephemeral sandboxes | |
|---|---|---|
| Primitive | branchable live VM | single-shot sandbox |
| Fork a running process tree | vers branch (258µs) | re-run init (seconds+) |
| State after shutdown | committed + restorable | gone |
| Rollback after a change | vers run-commit <id> | re-seed from scratch |
| Parallel exploration from one state | N branches of the same live machine | N independent setups |
| Memory + sockets carry forward | yes | no |
Running a hypervisor yourself
You can absolutely run your own microVM hypervisor. The hypervisors are great — they’re the thing Vers runs on. What they don’t give you is a tree.| Vers | Raw hypervisor | |
|---|---|---|
| Microsecond branch | yes | you build it |
| Content-addressable commits | yes | you build it |
| VM tree / parent tracking | yes | you build it |
| REST + CLI + SDK | yes | you build it |
| Orgs, projects, API keys | yes | you build it |
| Managed node pool | yes | you run it |
Container orchestration (Docker, Kubernetes, ECS, Nomad)
Schedulers are about spreading stateless load across many machines. Vers is about branching state across a tree. These compose cleanly: a Vers VM is a stateful worker a scheduler can run, and a scheduler’s preview-environment system can be backed byvers branch for instant, stateful previews.
Put differently: containers were the right answer for the problem “how do we pack stateless services densely.” Vers is an answer to the problem “how do we make state a first-class, branchable value.” Both are true. The two primitives aren’t rivals — they’re different axes of the same system.
Sub-millisecond is the thing
We’ll keep coming back to this number because it’s the axis everything else rotates around:| Branch p50 | 258.3 µs |
| Branch p99 | 329.2 µs |
| End-to-end fork | < 1 ms |
The argument
Compute has been single-timeline since we invented it. Every generation of infrastructure — mainframes, VMs, containers, serverless — carries that assumption forward: one state, one path, commit to the branch or start over. That assumption was correct when branching was slow. It isn’t anymore. We think the next shape of compute is a tree: live machines you can branch, states you can commit, histories you can walk. Sub-millisecond branching is what makes the shape practical, and the rest of the system — commits, tree semantics, hypervisor-agnostic isolation — is what makes it dependable enough to build on. If that’s the world you want to build in, welcome.Quickstart
Your first VM and your first branch — about 10 minutes.
Architecture
How the tree, branching, and commits actually work.
Agent swarms tutorial
Fork one golden VM into parallel agents. Full-stack app in ~60 seconds.
Core concepts
Projects, VMs, HEAD, branches, commits.