> ## Documentation Index
> Fetch the complete documentation index at: https://docs.boxd.sh/llms.txt
> Use this file to discover all available pages before exploring further.
# Fork
> Copy a running machine, memory and disk included, in milliseconds.
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](/use-cases/reproducible-rl-environments).
## Fork a machine
```bash theme={"theme":"github-dark"}
boxd machine fork myapp
```
```
source: fork/myapp
boot: 160ms
Connect:
ssh ssh myapp-fork.boxd
cli boxd machine connect myapp-fork
browser https://myapp-fork.boxd.sh
```
That name has to be free. Forking twice without naming the second one fails with `name 'myapp-fork' is already taken`.
With `--json`:
```json theme={"theme":"github-dark"}
{
"name": "myapp-fork",
"id": "63b8339c-411a-4c29-a0ff-09dd3da35c57",
"url": "myapp-fork.boxd.sh",
"source": "fork/myapp",
"boot": "161ms"
}
```
## 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](/guides/snapshots) instead. To rewind one machine rather than copy it, use a [checkpoint](/guides/checkpoints).
## Forking a shared machine
If you fork a machine [shared with your organization](/guides/share-a-vm), 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.
```bash theme={"theme":"github-dark"}
boxd machine fork staging # private to you, org-billed, logins restored
boxd machine fork staging --shared # keep the fork visible to the whole org
```
Forking a private machine is unchanged. The fork stays private.