Skip to main content
Each Sailbox has a writable state disk. Runtime filesystem APIs operate on that writable disk; checkpoints preserve it across pause, sleep, resume, cloned children, and recovery. The examples below assume a running Sailbox sb.

Write files

Upload bytes or strings into the Sailbox filesystem. Paths must be absolute. Missing parent directories are created by default.
Pass a mode to set POSIX permission bits. When omitted, writes default to 0o644.
Disable parent creation if you want writes to fail when parent directories are missing:

Read files

Fetch a regular file back as bytes:
Whole-file reads buffer the full file in memory. For larger files, stream chunks instead:

Work with directories

The fs namespace also covers directory work. mkdir creates a directory and any missing parents, ls lists a directory’s immediate entries as structured records (name, type, size, modified time, mode), exists checks a path, and remove deletes a file or directory tree:
Archives and shell-native workflows still go through exec(). For many small files, create an archive locally, upload it, and unpack it inside the Sailbox:

Persist state with checkpoints

Runtime writes live on the Sailbox state disk. Checkpoint after important writes if you want recovery and future resumes to start from that point:
See Lifecycle for checkpoint, start-from-checkpoint, pause, sleep, and resume behavior.

Runtime files vs image files

Use runtime filesystem APIs for inputs, outputs, logs, generated artifacts, and data that changes per Sailbox. Use Images for packages, source files, and static assets that should be present before the VM boots.