Volumes provide persistent storage that can be mounted into Porter Sandboxes. Create a volume before launching the sandbox, then pass the volume ID in volume_mounts.
Sandboxes are in a private beta. Please reach out to us at support@porter.run or over Slack if you are interested in joining.
Create and mount a volume
volume_mounts is a dictionary keyed by the absolute mount path inside the sandbox. Each value is a volume ID.
List volumes
list() returns volume handles:
Get a volume by name
Volume names are unique within the cluster. Use get(name) when you know a volume name:
Volume names may contain lowercase letters, numbers, and hyphens, and must start and end with a letter or number. A volume name must be unique within the cluster for the lifetime of the volume. After the volume is deleted, the name can be used again.
Inspect a volume
Browse volume contents
listdir returns the entries directly inside a directory, directories first:
iterdir walks the whole tree instead, descending into every subdirectory:
search walks the tree and returns only the entries whose name contains a substring, optionally rooted at a subdirectory:
Read a file
read_text returns a whole file as a string, and read_file returns raw bytes:
Both accept offset and length to read part of a file:
For files too large to hold in memory, stream pages through the file in chunks (8 MiB by default):
Reading a path that does not exist raises NotFoundError.
Every method here has an async counterpart on AsyncVolume, returned by AsyncPorter:
Access volume data from apps
Volumes live on a shared disk that apps on the same cluster can attach. Attach the disk named sandbox-volumes to a service in your app; it mounts at /data/<app-name>/sandbox-volumes and contains one subdirectory per volume.
Each volume handle exposes a path with the volume’s subdirectory on that disk, so an app reads a volume’s data at /data/<app-name>/sandbox-volumes/<path>:
The disk is a live view: writes a sandbox makes to its mounted volume are visible to apps right away, and new volumes show up as new subdirectories without redeploying the app.
Volume contents are written by sandboxed workloads, which are often running untrusted code. Treat anything your app reads from this disk as untrusted input: hostile file contents, names, or sizes can exploit vulnerabilities in the code that processes them. Porter isolates the sandboxes themselves but does not inspect or sanitize what they write, so validating this data before acting on it is your application’s responsibility.
Delete a volume
Delete volumes by name:
Deleting a volume fails while it is attached to a sandbox. Terminate any attached sandboxes before deleting the volume.
Async usage
Next steps