CapabilitiesSnapshots and forks
Pick an older snapshot
Restore any earlier snapshot, not only the latest one.
Who offers it
Part of Snapshots, forks and templates, which explains why it matters.
Fully: Blaxel, Daytona, E2B, InstaBox, Lizard, Modal, Morph, Runtime, Sprites, Tensorlake and Vercel Sandbox. With a catch: Agent 37, Boat, Cloudflare Sandbox and Sandboxer. Not at all: boxd.
- BlaxelYes
Snapshots are named and kept after the source is deleted.
docs-confirmed “A snapshot outlives the sandbox it was captured from: it stays usable, and forkable, after that sandbox is deleted.” Source
- DaytonaYes
Any number of sandboxes can start from the same snapshot.
docs-confirmed “any number of new sandboxes can start from the same snapshot” Source
- E2BYes
Snapshots can be listed, filtered by sandbox, and started again.
docs-confirmed “You can list all snapshots. The method returns a paginator for iterating through results.” Source
- InstaBoxYes
Any saved snapshot can be restored, and deleting a machine keeps its snapshots.
docs-confirmed “Deleting a machine keeps its snapshots; deleting a snapshot does not affect machines made from it.” Source
- LizardYes
Restore any snapshot you kept, into a new sandbox.
docs-confirmed “Each restore starts a new sandbox in the snapshot’s region” Source
- ModalYes
Snapshots are images with their own IDs and an optional TTL.
docs-confirmed “You can configure a custom TTL when creating a snapshot, or opt out of expiry entirely to retain snapshots indefinitely.” Source
- MorphYes
Any snapshot can be started again; snapshots do not change.
docs-confirmed “Snapshots are immutable point-in-time copies of both memory and disk state.” Source
- RuntimeYes
Each snapshot has its own id and can be started again later.
docs-confirmed “Each sandbox created from it boots fresh, without the saved processes.” Source
Checkpoints are numbered and can be listed and restored.
docs-confirmed “IDs are sequential (`v0`, `v1`, `v2`, and so on).” Source
- TensorlakeYes
A snapshot survives the source sandbox and can be restored much later.
docs-confirmed “once a snapshot reaches `completed`, the artifact persists after the source sandbox is terminated” Source
You choose how many to keep, and how long each lasts.
docs-confirmed “`keepLastSnapshots`: Keep only the N (1–10) most recent snapshots” Source
The catch: You can pick one of seven nightly copies, but you cannot save a snapshot of your own and return to it later.
An on-demand backup replaces the previous on-demand slot.
docs-confirmed “You can also take a backup on demand, into a separate slot that only your next on-demand backup replaces.” Source
- BoatWith a catch
The catch: You cannot roll a machine back to an older point; an older saved copy can only start a new machine.
docs-confirmed “Resume and fork always use the newest snapshot. **You cannot resume or fork an older snapshot.** There is no point-in-time restore.” Source
The catch: You have to store each snapshot’s ID yourself, and every snapshot is deleted 30 days after it was made or last used.
docs-confirmed “A snapshot expires 30 days after it is created or last restored.” Source
- SandboxerWith a catch
The catch: The automatic copies keep only the latest two; anything older you have to save yourself under a name.
docs-confirmed “each sandbox keeps its latest two” Source
- boxdNo
Saving again replaces the version, and older versions are cleaned up.
docs-confirmed “Saving over a name you already used captures a new version that replaces the previous one, and `--from-snapshot` always uses the latest.” Source
Related
Need several capabilities at once? Add more in the capability finder. Something wrong here? Use the report link at the bottom of the page.