Back to Docs

Fork

Rewind returns a machine to a checkpoint. Fork does something different: it spins up a new machine from a checkpoint and leaves the original running as it was.

Base URL: examples use $CLUNDRA_API as a placeholder for your Clundra API host.

How fork works

Fork from a checkpoint creates a brand-new, second machine whose state starts from that checkpoint. The source machine is untouched — it keeps running, keeps its own checkpoints, and is unaffected by anything you do to the fork. You get two independent machines.

curl -X POST $CLUNDRA_API/machines/$ID/fork \
  -H "X-API-Key: gopt_live_..." \
  -H "Content-Type: application/json" \
  -d '{ "checkpointId": "'$CPID'" }'

The response is a new machine object with its own id — that's the fork. In the dashboard, click Fork on any checkpoint.

When to fork

  • Agent experiments. Fork a machine at a known-good checkpoint, let an agent try something destructive on the copy, and throw the fork away if it goes wrong. The original never moved.
  • Known-good dev environments. Set up a machine once — tools installed, dependencies pinned, configured — checkpoint it, and fork a fresh copy each time you start new work. Everyone starts from the same baseline.
  • Parallel what-ifs. Fork the same checkpoint several times to try different approaches side by side, each in its own isolated machine.

Good to know

Fork does not yet store lineage. The fork action works, but Clundra does not currently render a lineage or branch graph showing which machine was forked from which. Track that relationship yourself (for example, in the fork's name or labels) if you need it.
Volumeless only. As with checkpoint and rewind, a machine with a mounted volume cannot be forked.

Related

Fork works on the same checkpoints you create for rewind. New here? Start with the Quickstart.

Need help? [email protected]