Velo Workspaces
Clone is the "how," not a "what"
Cloning, mechanically, is an APFS copy-on-write operation — clonefile() under the hood, near-instant because it doesn't copy data until something diverges. Velo uses it for two different purposes: creating a new workspace's disk from a sealed base image, and copying a workspace's current disk and state into a restore point. Same underlying mechanism, two different jobs. Asking "should I clone or use a base image" is really asking two separate questions at once — see base images as versioned infrastructure for the full mechanics.
Base image: a sealed, reusable starting point
A base image is a deliberately frozen, immutable template — configured once, then cloned from repeatedly to create new workspaces that all start identical. It doesn't track lineage between versions, doesn't change once sealed, and exists specifically to be the known-good thing everything else starts from. Covered in full in base images as versioned infrastructure.
Snapshot (restore point): a way back to one workspace's past state
A restore point copies an existing workspace's current disk (and saved VM state, if hibernated) so you can return to exactly that moment later. It's tied to one specific workspace's history, not a template for creating new ones — verified against the app's own source in disposable VM vs. snapshot.
Disposable workspace: no state preserved at all, by design
Closing one deletes the whole bundle — no clone, no snapshot, nothing kept. The next workspace clones fresh from a base image, not from the one that was just destroyed. This is the opposite instinct from both of the above: disposability is built around discarding on purpose, not preserving.
Side by side
| Base image | Snapshot | Disposable workspace | |
|---|---|---|---|
| What it is | A sealed template | A copy of one workspace's past state | A workspace with no state kept after use |
| Uses cloning? | Is cloned from | Created and restored via cloning | Not involved at all |
| Tied to one workspace? | No — a shared starting point for many | Yes — one specific workspace's history | N/A — nothing persists to be tied to |
| Answers | "What should every new workspace start from?" | "Can I get back to where this workspace was?" | "Can I guarantee nothing carries over?" |
Picking the right one
Want every new workspace to start from the same known-good setup? Base image. Want to rewind one specific workspace you're actively working in? Snapshot. Want a guarantee that nothing from this run persists at all? Disposable workspace, with no snapshot in the picture. Building a workflow around one workspace per Git branch uses all three at once: a shared base image every branch clones from, snapshots as optional checkpoints inside a long-running branch, and disposal when the branch itself is done.
Related reading: base images as versioned infrastructure, disposable VM vs. snapshot, and what a disposable development environment actually is. Cloning being nearly free on disk is also exactly why running several workspaces at once costs a lot less storage than it looks like — see how many VMs you can realistically run at once. Or download Velo Workspaces and try it yourself.