Borealis Docs

Environment snapshots

Snapshots capture supported filesystem state. Workspace files and running process memory are separate concerns.

What a snapshot contains

An environment snapshot preserves the container root filesystem and, when configured, one supported managed state volume explicitly marked as snapshot eligible.

It is not an archive of arbitrary mounts. Files under /workspace use the separate workspace transfer flow. Process memory, live connections, and running executions are not captured.

Before snapshotting stateful software, stop writes or use that software’s own backup procedure. A filesystem capture does not by itself guarantee an application-consistent database backup.

Request a snapshot

borealis snapshot create SANDBOX_ID

Keep the returned request ID and snapshot ID. Snapshot creation is an asynchronous operation; acceptance is not completion.

borealis snapshot operation get SANDBOX_ID REQUEST_ID --json

Poll until the operation succeeds or fails. If the response is lost, reuse the original request’s idempotency key and inspect its operation instead of creating an unrelated new request.

Restore into a new sandbox

After the snapshot operation succeeds, create a sandbox using its sourceSnapshotId. Review the image, startup settings, resources, and placement for the restored environment.

The new sandbox has its own identity and lifecycle. Import the workspace separately if the workload also depends on files from /workspace. Restart required services and check their health before sending work.

Understand portability

Moving environment state to another host depends on durable snapshot artifacts and compatible, eligible host capacity. It is not live migration and does not promise uninterrupted execution.

Keep the source until you have checked the restored environment. Deleting a snapshot is destructive; review your recovery needs before removing it.