Copy a machine that's still running.
A fork takes memory and disk together, so the copy comes up exactly where the original was — processes running, database up, caches warm. It takes <200ms, and the original never pauses.
- Running processes and open connections
- Databases, mid-transaction and all
- Whatever an agent had half-finished
Three ways to keep a machine's state.
They sound alike and they are not. One makes a new machine, one makes a starting point for many, and one is an undo button for the machine you already have.
All three capture memory and disk. What differs is where the copy lives and what you can do with it afterwards.
Copies memory and disk in place and becomes its own machine, with its own name, URL and SSH port. The parent never stops and never notices.
Memory and disk saved under a name and replicated across the cluster, so any number of new machines can come up from it later in the same warm state.
Held on that machine's own worker and restored in place, so the machine reboots into exactly the state you saved. It belongs to the machine and is deleted with it.
Set it up once. Never again.
The setup afternoon happens one time, on one machine, and every machine after it starts from where that one finished.
- 01
Set one machine up properly
Install the toolchain, clone the repo, seed the database, get the app running. Once — this is the last time anyone does it.
boxd m new base - 02
Save it as a snapshot
Memory and disk, under a name. Replicated, so it is available wherever the next machine gets placed.
boxd snapshots save base golden - 03
Start everything from it
Every machine after this one begins warm instead of repeating the setup. Fork a running one when you want a copy of right now rather than of the baseline.
boxd m new dev-2 --from-snapshot golden
What gets cheap when copies are free.
Two approaches at once
Fork mid-feature, try the other idea in the copy, keep whichever worked and destroy the other machine.
A machine per agent
Hand each agent its own copy of a working environment. Ten agents, ten machines, one setup.
Coding agents03A preview per branch
Forks inherit what the parent published, so the copy is live at its own address the moment it exists.
Domains & URLsAn undo before the risky bit
Checkpoint before a migration or an unattended run, and roll the machine back in place if it goes wrong.
Two panes. Left: a dev server running in machine `alice` with its log tailing. Right: `boxd machine fork alice alice-2`, then curl against the fork's URL returning 200 — with no boot in between. Let the real elapsed time show; the speed is the claim.
Cloning a disk isn't cloning a machine.
Copy a container image and you are back at a cold start: boot, install, migrate, warm up, and only then are you where you were. The state that mattered — what was in memory — never made the trip.
A fork resumes instead of starting, which is why forking something halfway through a job is a reasonable thing to do.
boxd machine fork alice alice-2Copy-on-write, and what it costs.
A fork starts out sharing every disk block with its parent and only pays for what it changes. That is what makes a machine per branch, per agent or per experiment a reasonable default rather than a budget conversation.
It is also why the honest answer to "how many forks can I have" is a question about how much they diverge, not about how many there are.
Who ends up using it.
- Developers
- Branching code is free and branching your environment is not — until the environment forks too. This is what makes trying the second approach cost nothing but the decision.
- Teams
- One person gets the stack working and saves a snapshot. Everybody else starts there, on the same versions, without a setup script anybody has to maintain.
- Agents
- An agent can fork its own machine before doing something destructive, and roll back if it was wrong. The verbs are the same ones you would type.
About forking
Memory and disk together. The copy resumes rather than boots, so processes that were running are still running, a database still has its buffer pool, and a model that was loaded is still loaded. That is why it is measured in milliseconds rather than minutes.
No. The parent keeps serving throughout and is untouched afterwards. Forking a machine that is in the middle of a job is a reasonable thing to do.
Only what it changes. Disk is copy-on-write, so a fork starts out sharing every block with its parent and diverges from there — ten forks of a 100 GB machine are nowhere near a terabyte.
Use a fork when you want a copy of a machine as it is right now. Use a snapshot when you want a starting point you will use repeatedly: it is replicated across the cluster and any number of machines can be created from it later.
That is what a checkpoint is for. Save one before something risky, and restoring it reboots that same machine into the saved memory and disk. Checkpoints live on the machine's own worker and are deleted with it, so use a snapshot for anything you want to keep.
Forking is what makes a dev workspace disposable and a coding agent cheap to be wrong. Every fork is driven from the same CLI, so an agent forks its own machine the way you would.