> ## 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. # Snapshots > Save a machine's memory and disk as a named image, then spin up fast copies from it. A snapshot is a named, saved copy of a machine's full state -- **memory and disk** -- captured while it keeps running. Unlike a [fork](/how-it-works/fork), a snapshot is durable and outlives the machine it came from. You save it once and create as many fresh machines from it as you like, each booting straight into the captured state. ## Usage ```bash theme={"theme":"github-dark"} boxd snapshots save myapp my-workspace # save memory + disk as a named snapshot (machine keeps running) boxd snapshots list # name, version, status, size, used (alias: ls) boxd snapshots remove my-workspace -y # delete a snapshot (alias: rm) boxd snap save myapp my-workspace # `snap` is the short alias ``` Saving doesn't interrupt the machine -- it stays `running` while the snapshot is captured in the background. The source machine must be `running` or `hibernated`. Create a new machine from a snapshot with `--from-snapshot`: ```bash theme={"theme":"github-dark"} boxd machine new fresh --from-snapshot my-workspace # restores memory + disk into a brand-new machine boxd new fresh --from-snapshot my-workspace # top-level shortcut ``` The new machine gets its own name, HTTPS domain, and SSH port, and comes up running exactly where the snapshot was taken -- same processes, same open files, same data. Inside a machine, the SDK exposes the same group: `boxd snap save` defaults to the current machine when you omit the name. See the [in-VM CLI](/reference/internal-cli). ## Snapshot vs fork Both copy a machine's full state. The difference is durability and reach. | | **Snapshot** | **Fork** | | ----------------- | --------------------------------------- | ------------------------------------ | | What it produces | A saved, named **image** | A running **machine** | | Persists | Yes -- survives destroying the machine | No -- it's just another machine | | Make copies later | Any time, `--from-snapshot` | Only at fork time | | Best for | A reusable base you return to for weeks | An instant, throwaway copy right now | Reach for a **fork** when you want a warm copy *now* and don't need it to persist. Reach for a **snapshot** when you want a golden image you can re-materialize repeatedly, long after the original is gone. ## Versioning Re-saving under a name you've used before doesn't error -- it captures a **new version** of the same snapshot, and the latest version is what `--from-snapshot` restores. Older versions stay put until you remove the snapshot. ```bash theme={"theme":"github-dark"} boxd snapshots save myapp my-workspace # version 1 # ... more setup inside myapp ... boxd snapshots save myapp my-workspace # version 2 (latest wins) ``` This makes a snapshot a moving "known-good" marker: keep re-saving the same name as your golden machine evolves, and every new machine starts from the freshest capture. ## Ownership and sharing Snapshots are **owned by the organization** the source machine is billed to, never by an individual, and they never cross an org boundary. Visibility follows the source machine: * A snapshot of a **shared** org machine is visible to every member of the org. * A snapshot of a **private** machine is visible only to the person who captured it. A machine created from a snapshot is born **private to whoever restored it**, in the snapshot's org, drawing that org's quota. So a teammate can take a shared golden snapshot and spin up their own private copy to work in, without touching the shared original -- the same pattern as [forking a shared machine](/organizations/share-a-vm). A snapshot restore rebuilds the machine from the captured state, so it can't take on **extra disks** at creation time. `boxd machine new --from-snapshot ... --volume ...` is refused -- create the machine from the snapshot first, then attach the disk. ## How it works 1. **Capture.** boxd records the machine's memory and disk at that moment. The machine keeps running the whole time -- there's no pause you'd notice. 2. **Store.** The snapshot is kept durably and independently of the machine, so it's still there after you destroy the original. It's ready to restore from within moments of saving. 3. **Restore.** `--from-snapshot` creates a new machine that wakes straight into the captured memory and disk -- no boot, no re-init, no app startup. It comes up exactly where the snapshot was taken. Because a new machine wakes into the saved state instead of booting from scratch, creating copies from a snapshot is fast, and stays fast even when you fan out many at once. This is a different thing from the internal memory captures that power [suspend & resume](/how-it-works/suspend-resume). Those are transient, and boxd manages them for you to freeze and wake a single machine. A **snapshot** here is an explicit, named image you save and manage yourself. ## What this enables * **Golden images that persist.** Build a machine once -- clone, install, configure, run -- snapshot it, and re-materialize it for weeks. Destroy the original; the snapshot lives on. * **Fast fan-out.** Spin up dozens of identical machines from one snapshot, each booting into the captured state in a fraction of a cold boot. * **Shared team baselines.** Capture a shared org machine as a snapshot; every member can stamp out their own private copy to work in. * **Point-in-time recovery.** Keep re-saving a known-good snapshot as your environment evolves, and roll a new machine back to any saved state. ## Reference `snapshots save`, `list`, `remove`, and `new --from-snapshot`. Instant, in-place copies of a running machine. Per-machine save points you roll back to in place. How sharing and org ownership work.