Snapshot types
Disk is the default. Full adds memory and execution state; there is no memory-only snapshot.Disk snapshots
Use disk snapshots for installed dependencies, prepared workspaces, and saved files. Cloud requires a stopped persistent source. See guest flushing for how microsandbox handles pending writes.1
Prepare
Start a
python:3.12 sandbox named baseline using the create guide, then install a dependency:2
Capture
Save the prepared state as
ready:3
Restore
Restore into
worker. Its disk writes are independent of the source.group:member selectors, such as baseline:ready. For cloud, pass the snapshot object or reference; it has no client-local path.
Full snapshots
Capture a running workload to resume its processes and memory later. A running source briefly pauses during capture, then resumes; an already-paused source stays paused. On Windows, full snapshots now preserve all tracked hardlink names for bind mounts. Runtimes that support this format can still restore the previous Windows filesystem format. Older runtimes cannot restore snapshots written with the new bind-mount format; use the updated runtime when restoring them. This does not change disk-only snapshot compatibility.1
Capture
Start with a running or paused sandbox named
worker:2
Restore
Resume in a new sandbox. The image’s startup command does not run again.
- Compatibility: Use a compatible runtime and guest kernel. CPU and memory settings, including maximums, must match the capture.
- Connections: Reconnect clients and application connections. Microsandbox does not capture host-side connections or transfers, and does not replay buffered process output.
- Mounts: Owned volumes are private to each child. Host bindings need explicit authorization; see mount behavior.
Capture or restore fails
Capture or restore fails
If capture saves an artifact but cannot recover the source, inspect the artifact reported in the error before retrying. A packaging failure may leave only a runtime checkpoint.If restore leaves an incomplete child, remove it and restore again; the snapshot remains reusable. Older development full snapshots may need recapture or disk-only restore.
Share memory
Full restores normally copy memory. Enable copy-on-write (CoW) to share unchanged pages between children while keeping writes private:Older restore option names
Older restore option names
The old
forked options still enable copy-on-write memory during restore. Use these names in new code:The MCP
sandbox_restore tool retains its forked input for the same memory option.Restore disk only
Boot a fresh VM from a full snapshot’s saved disk without resuming its processes. You can choose different CPU and memory settings.Keep the guest clock
By default (sync), the sandbox’s date and time follow the host. The host updates the clock at boot, about once a minute, and when a full snapshot restores or a paused sandbox resumes.
With off, the host stops updating the clock after boot. Full restores continue from the snapshot’s saved time. The clock keeps running, making this useful for tests that need a repeatable starting time.
sync to use host time or off to continue from the saved time:
- Scope:
offprevents host clock updates. Programs inside the sandbox with permission to set the time can still change it. - Drift: With
off, the guest clock is not corrected after the host sleeps or its clock changes. - Monotonic clock: Continues from the snapshot in both modes.
- Forks: Forks inherit this setting.
- Compatibility: Older runtimes reject
off. Older SDKs and CLIs reject full snapshots saved withoff, including exported archives. Cloud also rejectsoff. - Downgrades: Older SDKs and CLIs require a database downgrade to reopen this installation. Downgrading is blocked while any sandbox’s saved or active settings use
off.
Guest flushing
Guest flushing writes pending filesystem changes from memory to disk. It works the same way in the CLI and all SDKs, for snapshots, forking, and pausing. The defaultauto policy flushes running disk snapshots. Full snapshots and forks keep those changes in memory instead. Choose required if you plan to restore a full snapshot’s disks without its memory:
Advanced flush behavior
Advanced flush behavior
- Paused sandboxes: Pause with
requiredbefore taking a disk snapshot. Capture fails if the needed flush was not done before pausing; it never resumes the sandbox to flush. - Stopped or crashed sandboxes:
autoandskipcapture the saved disk state.requiredfails because no guest is running. - Storage: Flushing covers the root and captured block disks, including owned disks. It does not make tmpfs persistent. Host storage synchronization and snapshot durability remain enforced with every policy.
- Compatibility: Older runtimes may reject the policy; restart the sandbox with an updated runtime. Cloud supports only
auto.
Forking
Create a child directly from a running or paused sandbox, without saving a reusable snapshot. Forking preserves disk and execution state. Memory sharing is built in; each child’s writes stay private. To start from a saved snapshot, use restore. The formerbranch SDK methods remain deprecated aliases for fork.
Create several children
Create several children
Capture once for several children:Each child gets its own result; a failed child does not remove successful siblings. Validation or capture errors fail the call. Deleting the source or a sibling does not invalidate other children.
Mount behavior
Owned directory snapshots cannot move between Unix and Windows. Owned disks do not have this restriction.
External mounts
Snapshots do not include host-mounted files. Supply their host paths when restoring. Owned volumes restore automatically. Full restore requires every captured external filesystem and additional disk to be available. For either a disk or full snapshot, mount a host directory like this:Advanced restore options
Advanced restore options
- Reuse source bindings: Restore on the same host using the source’s validated mounts. Missing dependencies still cause restore to fail.
- Select a captured disk: Restore a private copy of a named disk volume. External disk images are not converted to owned volumes.
- Allow missing resources: Continue without an external filesystem or additional disk. Root and owned storage must still be complete. Access to missing resources fails and may disrupt applications or make filesystems read-only.
Validate mounts
Full restore and forking validate captured filesystem identities. Strict is the default; relaxed mode accepts supported differences and reports warnings:Open files and cached data
Open files and cached data
Full snapshots retain clean cache pages, so reads may return captured bytes before reaching the host. Strict validation checks identity at restore time; it does not lock files against later edits.External files deleted while still open, and special files, can prevent capture. Owned directories support deleted open regular files. Restore warnings identify inaccessible or changed objects; see your SDK reference for details.
Manage snapshots
These operations apply to disk and full snapshots. Cloud supports basic disk snapshot management; groups, archives, verification, and disk maintenance below are local-only.Restore progress
Track local disk or full restore through image preparation, memory preparation, and activation. Wait for the final result before using the sandbox:Stop or Destroy when needed. Cancel the context to cancel the operation.
Some stages have no percentage. Memory preparation has no fixed timeout; activation has a separate timeout. Set an overall deadline or use SDK cancellation when needed.
Manage saved snapshots
List snapshots, inspect one, or remove it:Snapshot groups
A group keeps related snapshots together. Restore an earlier snapshot and save new changes to explore a different path while keeping the original snapshots. Choose the original group when capturing to keep the new snapshots in that group; otherwise, the group defaults to the restored sandbox’s name. Since v0.7, installed snapshot members are immutable. Creating another snapshot cannot overwrite an existing member. In SDK calls, omitforce or set it to false (False in Python): enabling it fails even when the requested name does not exist. Use a unique or generated member name for each capture. To reuse a name, explicitly remove the existing member first; removal still checks for dependent snapshots.
See the v0.6 snapshot upgrade example.
Locally, group selects its head; group:member selects an exact snapshot:
Import into a group
Import into a group
Imports without a group create a new one. Select an imported head explicitly when needed:Identical members can be reused; conflicting IDs or names fail. Publication never overwrites an existing member. Inspect the group before retrying an interrupted import.
Move snapshots
Archives let you move local disk or full snapshots between machines.Export and restore
Copy either snapshot type to another machine as a.msb archive. Include the image for offline restore:
.tar and .tar.zst archives also work. Full compatibility and owned-directory platform restrictions still apply.
Import archives
Load a base and dependent archives together; order does not matter:Export changes
Export only disk layers and full-snapshot RAM objects not supplied by an exact base:Other export options
Other export options
The last-layers option exports only the newest root layers, keeping owned disks and required RAM complete. Do not combine it with since-base export, or use either with parent-chain or whole-group export.After compaction, export a new standalone baseline. Independent stopped captures can also get new layer identities despite identical bytes; use a standalone export when the base no longer matches.
Capture to an archive
Capture directly to an archive without installing a snapshot locally. Disk is the default; add the full option for execution state:Compact disks
Merge sealed disk layers in a running or fully stopped local sandbox. This affects disk storage, including disks in full snapshots, not memory. Preview before applying:Verify integrity
Disk content hashing is opt-in. Record hashes during capture, then verify when receiving or checking a snapshot:Full snapshots and forks
Full snapshots and forks
Troubleshooting
Reference
See each SDK reference for setup, imports, optional controls, and result fields.- SDKs: TypeScript, Rust, Python, and Go.
- CLI: Run
msb snap --helpormsb snap restore --helpfor all options.