Skip to main content
This feature is currently in private preview and is not recommended for production use.
A snapshot captures the state of a sandbox at a point in time: its filesystem, its running processes, and its memory. Snapshots are workspace resources of their own, so a snapshot stays available after you delete the sandbox it was captured from, and it carries everything needed to create a new sandbox or application from it. Use snapshots to checkpoint a sandbox before a risky change, to keep a warm starting point for new sandboxes, or to keep a template of a fully booted environment long after the sandbox that produced it is gone.

Snapshot identity

A snapshot has a name that is unique in your workspace and that every operation addresses it by. Pick the name at creation time, or let Blaxel generate one: Creating a snapshot with a name that is already taken in the workspace fails with a 409 error. Delete the existing snapshot first, or pick another name.

Create a snapshot

A snapshot always has a source. Pass the name of the object to capture as source, and a name if you want to choose it:
You can also capture a snapshot from the sandbox itself, which is the same operation with the source filled in for you:
source.kind defaults to sandbox, the only kind of object you can capture today.

Retrieve a snapshot

List snapshots

Listing at the workspace level returns every snapshot, including the ones whose source sandbox no longer exists.
The list endpoint is cursor-paginated and supports full-text search on the snapshot name, source name, and status through the q parameter:
Pass meta.nextCursor as cursor on the next request and repeat until meta.hasMore is false. For more information, refer to the API reference documentation. To list only the snapshots captured from one sandbox, list from the sandbox instead:

Fork a snapshot into a new sandbox

A snapshot carries the image, the memory size, the ports, the infrastructure generation, the region, and the volumes of what it captured, so you can fork it into a new sandbox even after its source sandbox is deleted.
Set targetType to application to start an application from the snapshot instead of a sandbox, and pass envs to give the fork a different environment. Both work the same way as when forking a sandbox. When the source sandbox still exists, the fork also inherits what the snapshot does not carry, such as environment variables, lifecycle policies, and network configuration. When the source sandbox is gone, the fork runs with the configuration stored on the snapshot.

Restore a sandbox to a snapshot

Restoring rolls a running sandbox back to a snapshot in place, keeping its name, its URLs, and its previews. Refer to restoring a sandbox for the full behavior.

Delete a snapshot

There is a single snapshot object, so deleting it removes it for the whole workspace. Deleting it from the sandbox it was captured from does the same thing.
Deleting a snapshot is the only thing that removes it. Snapshots have no expiration, and Blaxel never prunes them for you.

Snapshot lifecycle and sandbox deletion

Deleting a sandbox does not delete its snapshots. The snapshots stay in your workspace, keep their names, and stay usable. The only visible change is on the link back to the source, whose deleted field becomes true:
Snapshots keep consuming storage after their source sandbox is deleted, and they count against your workspace snapshot quota. Delete the snapshots you no longer need. Refer to quotas for the limits that apply to your workspace.

Snapshots and forking for sandboxes

Snapshot, restore, and fork from the sandbox side.

Sandbox overview

Learn more about sandbox lifecycle and configuration.
Last modified on September 4, 2026