Skip to main content
A fork is a second machine that continues from exactly where the first one is. The disk, the memory, and every running process come across, and the copy carries on from that moment with its own name, URL, and ports. This is fundamentally different from snapshots, since there is no need to write state to disk first. You create a new machine through copy on write in milliseconds. This opens up interesting use cases, for example reproducible RL environments.

One command, and the copy is up in milliseconds.

​
Fork a machine

That name has to be free. Forking twice without naming the second one fails with name 'myapp-fork' is already taken. With --json:

​
Running processes come with it

This is the part that separates a fork from booting a plain new machine. A server listening on the source is already listening on the fork, at the fork’s own URL, without anything starting up. The processes are the same processes on a different machine. Fork a machine running a web server and you will find it under the same PID, with the same start time, and the machine’s uptime carries on from the source rather than resetting to zero. So a fork skips whatever the source already did. This means that dependencies are already installed, a database is warm and a dev server has finished compiling. There is nothing to rerun. You can fork a machine in any state, and what carries over follows from what the source has to give. A running source pauses for a fraction of a second to hand its live memory to the copy, then carries on. A hibernated source stays hibernated while the copy wakes from the frozen state. A stopped source stays stopped and the copy boots fresh from the disk, since a stopped machine has only its disk left to copy. The fork itself always comes up running.

​
After the fork

The two machines are independent from the moment of the fork. Writes on one do not reach the other. The fork gets its own 100 GB disk, copy-on-write against the source, so it uses close to no extra storage until it starts to differ.

​
What to use it for

  • Try something risky. Fork, break the fork, delete it. The original never moved.
  • Run several attempts at once. Fork three times from the same state and compare the results.
  • Reproduce a bug. Fork the machine that is misbehaving and dig around in the copy.
  • Hand someone a copy. Give a reviewer or an agent its own machine that already runs your app.
For a copy you want to keep and create machines from later, use a snapshot instead. To rewind one machine rather than copy it, use a checkpoint.

​
Forking a shared machine

If you fork a machine shared with your organization, the fork is private to you by default. The org keeps paying, only you can reach the copy, and your agent logins for Claude Code, Codex, and OpenCode work in it again straight away.
Forking a private machine is unchanged. The fork stays private.