Overview
Veri Volumes are named persistent storage in your workspace. You create a volume, upload files or whole directories to it, list what it holds, and delete single files or the whole volume when you no longer need them. A training job reads a volume in one of two ways:- One file as a dataset.
datasets.from_volume(volume, path)connects a file inside the volume as a dataset. The file is downloaded to the training machine when the job starts, like an uploaded dataset. This works today for every provider. - The whole volume mounted. A job-level
volumecopies the entire volume to/mnt/<name>on the training machine before training starts, read-only. Custom scripts see it at the same path and inVERI_VOLUME_DIR. This is coming soon: until it is enabled, a job withvolumeset is refused at submit with a message that points atfrom_volume.
When to use a Volume
Pick a Volume when any of the following is true:- You expect to run more than one training job against the same dataset.
- Your dataset is larger than a few GB.
- Your dataset isn’t public and isn’t on Hugging Face.
- A custom script needs more than one input file.
veri datasets upload) or Hugging Face connect (veri datasets connect-hf) paths are simpler.
Billing
Volume storage is measured every hour and billed monthly: 512 GiB per workspace is free, and storage above that is $0.085 per GiB-month, averaged over the month. Copying a volume into a training job is not charged separately; the job pays for its GPU time while the copy runs.Quickstart
1
Create a volume
^[a-zA-Z0-9][a-zA-Z0-9_-]{0,127}$ and is unique within your workspace. Re-running with the same name is idempotent: it returns the existing volume.2
Upload files
upload-dir; up to 8 files transfer concurrently:3
Train on a file in the volume
from_volume checks that the file exists when you connect it (a missing file is a 404, a path with .. is a 400), so a typo fails before a GPU is rented. When the job starts, the training machine downloads that one file and trains on it.Mounting a whole volume
A job-levelvolume (coming soon) copies every file of the volume to /mnt/<name> before training starts:
- Asks the control plane for the volume’s file list, in pages, with a short-lived download link per file. No cloud credentials reach the machine.
- Checks that the volume fits on the local disk. If it would use more than 80% of the free space, the job fails right away with
volume_too_large_for_nodeinstead of filling the disk mid-run. Local disk is about 150 GB on AWS, 200 GB on GCP, 100 GB on Vast and 720 GiB on DigitalOcean. - Downloads the files 16 at a time into
/mnt/<name>, checks every file’s size against the list (a mismatch fails the job withvolume_sync_incomplete), and makes the tree read-only. - For a custom script, bind-mounts
/mnt/<name>into the container read-only and setsVERI_VOLUME_DIR=/mnt/<name>. A managed job whose dataset was connected from the same volume reads the file from the mount.
from_volume) and a job-level volume must name the same volume; naming different ones is refused at submit.
Deletion
--yes, the CLI prompts for the volume name as a confirmation and shows the file count and total bytes that will be deleted. The row is dropped immediately; the stored objects are cleaned up by a background job within a few minutes.
Over the REST API, DELETE /v1/volumes/{name} takes either the volume’s name or the id that POST /v1/volumes returned. The same holds for GET /v1/volumes/{name} and every /v1/volumes/{name}/... route (list files, delete a file, upload URLs).
A volume that a queued or running training job still uses, as its mount or through a dataset connected from the volume, cannot be deleted: the request returns 409 naming those jobs. Wait for them to finish or cancel them first.
There is no time-based garbage collection. Volumes stay until you delete them; the monthly billing meter is what keeps storage bills aligned with what you actually use.
API + CLI references
CLI commands
veri volumes create / upload / list / deleteREST API
/v1/volumes endpoints including multipart upload init.
