Skip to main content
This feature is currently in private preview and is not recommended for production use. It requires a feature flag on your workspace: contact us or email support@blaxel.ai to get access. Until then, the archive and unarchive actions are hidden in the Blaxel console, and both API operations answer 403 Forbidden.
Archiving a sandbox stores the filesystem changes it made over its image, then shuts the sandbox down: nothing runs and no memory is kept, and you stop paying for it. The sandbox keeps its name, its configuration, and its preview URLs, so unarchiving gives you the same sandbox back with its files. Archiving is not a snapshot: memory is not preserved. Processes are stored with their configuration and start again with new IDs when the sandbox is unarchived.

Archive a sandbox

The export runs in the background. By default the SDK waits until the sandbox reaches the ARCHIVED status.
Archive a sandbox by name, without retrieving it first:

Unarchive a sandbox

Unarchiving starts the sandbox again from its image and writes the archived filesystem back over it. The sandbox and its terminal answer while the restore runs, and the SDK waits until the sandbox is DEPLOYED again.

Control the wait

An archive and its restore take longer as the filesystem grows. Pass wait: false in TypeScript, or wait=False in Python, to return as soon as the operation is launched, then read the sandbox status yourself. Set maxWait/max_wait and interval, both in milliseconds, to change how long the SDK waits and how often it reads the sandbox.

Statuses

A sandbox keeps a single archive. Archiving a sandbox again replaces the previous archive, and deleting a sandbox deletes its archive, whatever its status.

Sandbox overview

Learn more about sandbox lifecycle and configuration.

Snapshots and forking

Checkpoint a sandbox, memory included, and fork it into a new one.
Last modified on August 26, 2026