Skip to main content
Volumes provide persistent shared filesystems that can be mounted into machines and managed directly through volume.files.
Volumes require a microVM-runtime deployment with the shared-volume backend and Supabase-backed control-plane state enabled.

Create and mount

Mount paths must be absolute machine paths outside /workspace/.nullspace. Each machine can have up to 8 active volume attachments, and subpath= can mount a volume subdirectory. read_only=True prevents writes through the machine mount while still allowing direct volume.files writes by callers with API access. You can also attach volumes at create time with dictionaries:

Runtime attachments

Attach or detach volumes after a machine is already running:
machine.attach_volume(...) accepts a volume ID, volume name, VolumeMount, or dictionary. If read_only is omitted, the API defaults it to False. List every machine attachment for a volume:
Destroying a machine releases its remaining volume attachments. machine.pause() and machine.hibernate() release live mount leases while stopped, but preserve attachment intent and remount the same volumes on resume. AsyncMachine exposes the same runtime volume methods with await.

Direct volume files

Direct volume file paths are absolute volume-internal paths rooted at /. Relative paths are rejected, .. cannot escape the root, and direct volume operations do not use machine cwd or user semantics. write_files() raises BatchWriteError if any file fails after earlier writes may already have succeeded. Inspect successes and failures before retrying.

Volume lifecycle helpers

Use Volume.from_id(id) when you already have a volume ID, and Volume.from_name(name, create_if_missing=True) when setup scripts should be idempotent. Volume.list(fields=[...]), Volume.get(id, fields=[...]), and Volume.get_by_name(name, fields=[...]) return raw dictionaries containing only the requested metadata fields.

Async API

AsyncVolume.files mirrors the synchronous direct file and transfer API. VolumeInfo.max_size_bytes is the current enforced cap. In the hosted private beta, auto-grow is currently disabled and the default cap is 2 GiB per volume unless an operator has applied a tenant-specific override. Refresh volume metadata after large writes when you need the latest capacity view.

CLI

The CLI commands below cover create-time mounts and direct file operations for teams that prefer shell workflows. Use the Python SDK or HTTP API for runtime attach, detach, health, and remount operations.

Snapshot behavior

Shared volume data is durable storage external to VM memory and mutable rootfs snapshots. Hibernate, resume, and fork perform storage remounting, not memory portability. They do not make live VM memory or mutable rootfs snapshot state portable across incompatible runtime hosts. Concepts: Hibernate, Resume, Fork. API reference: createVolume, listVolumes, listVolumeFiles, and writeVolumeFile.