Skip to main content
A box loses everything on its disk when it is destroyed. A volume does not — mount one into a box and the data outlives it. Use a volume for a dataset or model weights you do not want to fetch again, or for an agent’s working state that has to survive the box that produced it.

When you need a volume

  • An agent whose state must outlive its box. A box on Cloud can stop when it goes idle and be deleted after stopping. Anything the agent wrote to the box’s own disk goes away with it; anything it wrote through a volume mount is still there for the next box.
  • A large dataset or model you do not want to re-download. Fetch it once into a volume, then mount that volume into every box that needs it instead of paying the download on each box.
  • Handing results from one box to the next. One box produces artifacts under the mount path, a later box mounts the same volume and picks them up.

Manage volumes from the SDK

The runtime you build with Boxlite.rest(...) carries a volumes API. volumes is a property, so write rt.volumes — no parentheses — and await the four methods hanging off it. Every method returns VolumeInfo objects, whose fields are read-only: When the backend behind your runtime does not support named volumes, these four calls raise a BoxLite error. Handle it where you call them, as the example below does. This script creates a volume, mounts it at /data, writes a file through the mount, reads it back, and cleans up both the box and the volume in finally:
To work with a volume you already have instead of a fresh one, pass its id straight to BoxOptions(volumes=...), or call await rt.volumes.get("<YOUR_VOLUME_ID>") first to confirm it exists.

Create a volume in the console

The console is the other way to create a volume, and the one to use when you want to see what you own.
  1. Open Volumes in the console and click New Volume.
  2. Fill in Name — the only field. Pick something you will recognize later, such as subtitle-models.
  3. Create it, then give it a few seconds to become ready before you mount it.
The volume now exists independently of any box. You can mount it into a box, destroy that box, and mount it into a different one later. rt.volumes.list() and the Volumes page report the same set of volumes.

Names live in the console, ids come from the SDK

The New Volume dialog takes a Name. create() accepts no arguments, and the id on the returned VolumeInfo is assigned by the server. So a volume you create from code carries no name you chose, and the id is the handle for everything that follows — mounting, get(), and remove(). Create in the console when a human will need to recognize the volume in a list. Create from code when your program keeps the id.

Manage volumes over REST

Reach for REST when you are working outside the Python SDK. Volumes live under the /v1/volumes route, authenticated with Authorization: Bearer <YOUR_API_KEY> like every other route. Create a key on the API Keys page first — see API keys.
Deletion is DELETE /v1/volumes/{volume_id}, which returns 204. Read Deletion is asynchronous before you build on top of it.
Over REST, the operations documented here are listing and deletion. To create a volume, call await rt.volumes.create() or use the console.

Mount a volume into a box

Mounting is configured at creation time through the volumes field on BoxOptions. Each element is a (volume, mount_path) tuple. The first element is the managed volume’s id — the value create() returned, or the id the console shows — not a path on your machine. That is the mental switch to make coming from open source. Two more shapes are specific to Cloud, both visible in the example above: Boxlite.rest(...) needs no path_prefix, and you reclaim the box with await rt.remove(box.id, force=True). For the full BoxOptions parameter table and exec semantics, see the Python SDK reference. For the host-directory mount forms and read-only mounts, see Volumes and mounts.

Data outlives the box

The property that makes a volume worth using: write through the mount in one box, destroy that box, mount the same volume in a different box, and the data reads back. This is verified behaviour on Cloud — the volume is backed by managed storage, not by the box.
Only what you write under the mount path survives. A file written to the box’s own filesystem outside /data goes away with the box.

What is different from open source

Host bind mounts are ignored over REST. In open source, volumes=[("/home/you/data", "/data")] mounts a directory from your machine. On Cloud, a host path in that first position is silently ignored — the box starts, the mount does not happen, and nothing you write is persisted. There is no error to catch. If you are porting code, replace every host path with a managed volume identifier.
For the host-directory mount options, read-only mounts, and copy_in / copy_out, see Volumes and mounts. For the complete side-by-side, see Cloud vs open source.

Deletion is asynchronous

await rt.volumes.remove(volume_id) returns None, and DELETE /v1/volumes/{volume_id} returns 204. Either way that is an acknowledgement, not a completed deletion. Immediately afterwards:
  • A REST read of that volume returns 200 with a state of pending_deletenot a 404.
  • A listing can still include the volume for a short window.
  • Reclamation finishes on the platform’s own cycle.
So do not write code that waits for a 404. Poll the listing with a bounded timeout and treat a volume that has left the listing as done:
Deleting a volume that a running box still has mounted does not corrupt that box. The box stays usable.

Troubleshooting

Next steps

Boxes on Cloud

Images, sizes, and the console lifecycle switches that make a volume necessary.

Cloud vs open source

Every behavioural difference in one table, including mounts.