Persistent Workspaces
This guide covers patterns for durable state management — long-lived environments, repeatable automation, and template-based workflows.
Create a persistent workspace
Run commands against a workspace
Chaser provisions or reuses a sandbox session automatically:
Files created by one command are available to the next. The workspace disk persists even when no session is running.
Snapshots
Create filesystem-level restore points before risky operations:
Snapshots capture the full workspace disk state. They are not live RAM/process checkpoints.
Templates and cloning
Mark a workspace as a template, then clone it to create independent copies:
Cloning copies workspace metadata and the latest filesystem state. The clone is fully independent — changes to the clone do not affect the source.
Cloning is blocked while the source workspace has an active session.
Workspace naming
Names are unique per account, case-insensitive, max 64 characters.
Import from GitHub
The GitHub repository is cloned into /workspace. The repo selector is persisted on the workspace record so later session boots can re-bootstrap if needed.
Storage
- Each workspace has a baseline disk size of 10 GB
- Per-account total workspace storage is capped at 25 GB (measured as actual on-disk bytes)
- Storage usage is visible in
GET /v1/billing/summary
Related
- Workspaces — API reference for workspace operations
- Interactive Development — using workspaces for development
- CI/CD Integration — workspace-backed CI
