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.Archive a sandbox
The export runs in the background. By default the SDK waits until the sandbox reaches theARCHIVED status.
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 isDEPLOYED again.
Control the wait
An archive and its restore take longer as the filesystem grows. Passwait: 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
Archive to your own storage
Everything above uses storage managed by Blaxel. The sandbox API that produces those archives is also reachable directly, so you can write the same archive to a bucket you own and restore it into a sandbox later. Use it to keep backups outside Blaxel, to copy a filesystem between workspaces or regions, or to keep several archives of the same sandbox. The sandbox never holds your storage credentials. You presign the upload or the download yourself, and hand the sandbox the resulting URL. A presigned URL carries a signature made with your own credentials, granting one request on one object for a limited time — so the sandbox can write or read that single object and nothing else. Call these endpoints on the sandbox’s own URL, available assandbox.metadata.url in the SDKs, with the same authentication as any other sandbox API call.
Archive contents
An archive is an uncompressed tar of everything the sandbox changed on top of the image it booted from, plus a metadata directory:
Deleted paths cannot travel as tar members, so they are listed in the manifest under
deleted and applied by the restore.
manifest.json
/tmp, no runtime directory (/proc, /sys, /dev, /run, /mnt), no host-injected identity (/etc/resolv.conf, /etc/hostname, /etc/hosts, mounted secrets), nothing from the sandbox runtime’s own directories, which the manifest lists alongside the excludes above, and nothing from an attached volume or agent drive, which are separate filesystems with their own lifecycle. It also holds nothing from the image itself, so it is only meaningful on a sandbox created from that same image.
Export to a presigned URL
Presign aPUT on your bucket, then hand the URL to the sandbox. Set async so the call returns immediately: an archive of a large filesystem takes longer than a request can be held open.
Size an archive before presigning
A dry run reads the filesystem and reports the exact byte count the upload will have, along with every path it would carry. Nothing is stopped and nothing is uploaded, so you can run it on a live sandbox.Archives larger than 5 GB
A single presignedPUT accepts 5 GB. Above that, create a multipart upload on your storage, presign one PUT per part along with the completion and abort requests, and pass them to the export. The sandbox uses them in order and completes the upload itself.
abortUrl so a failed export discards the parts it already sent instead of leaving them on your bucket.
Back up to cold storage
Anything you signed can be sent with the upload throughheaders, which is how an archive lands directly in an archival storage class:
"saveProcesses": false. The archive then holds the filesystem alone.
Follow an export
GET /archive/status reports the freeze and the background export:
running, then succeeded once the storage holds the archive, or failed with the reason. A failed export lifts the freeze itself, so the sandbox stays usable. After a successful one, the sandbox is frozen on purpose: delete it, or call POST /archive/resume to serve every route again. Resume does not start the stopped processes again.
Restore an archive into a sandbox
A sandbox restores an archive at boot, before its workload starts. Presign aGET on the archive and set it as BL_ARCHIVE_IMPORT_URL when you create the sandbox, from the same image the archive was taken from.
GET /archive/status to follow it: restore.state goes through downloading, extracting and relaunching, then succeeded, and restore.downloaded against restore.size gives you the progress.
The processes the archive recorded are started again from their command line, with new IDs. Nothing is adopted from the archived sandbox, since its memory and its PIDs are gone.
The archive is applied once. It is recorded on the restored filesystem, so the sandbox API restarting does not undo what the workload has done since, and a sandbox that boots again from the pristine image restores it anew.
What to keep in mind
- A presigned URL is a credential. It is never logged by the sandbox and never appears in an error, and it should have the shortest lifetime that fits your transfer.
- A transfer is bounded to one hour, so presign for at least as long as uploading or downloading your archive takes.
- Restore into a sandbox created from the image the archive was taken from. An archive holds only the difference with that image.
- Archives declare a format version. A sandbox refuses an archive newer than the format it understands, and reads gzip-compressed archives as well as plain ones.
- One export runs at a time per sandbox, dry runs included. A second one is answered
409.
Sandbox overview
Learn more about sandbox lifecycle and configuration.
Snapshots and forking
Checkpoint a sandbox, memory included, and fork it into a new one.
