Disk and storage
Choosing a size at deploy
The Deploy page has a disk slider. It starts at 50 GB and moves in steps of 10 GB, from a minimum of 10 GB up to the maximum the machine you picked can give you. The helper text under the slider names that maximum. Different machines have different ceilings, so changing the offer changes the top of the slider.
Over the API the field is disk_gb on POST /v1/instances, and it accepts 10 to 20,000. A value above the chosen machine's capacity is rejected with 422 DISK_TOO_LARGE, and the error tells you the maximum that machine can give you.
{
"offer_id": "…",
"template_id": "…",
"disk_gb": 200,
"label": "llama-finetune"
}
Size it for the whole job: the image, your dataset, package caches, and every checkpoint you intend to keep at once. Checkpoints are usually what overruns — a run that writes one per epoch and deletes nothing will fill a disk that looked generous.
You cannot resize it afterwards
There is no resize control in the console and no field on any endpoint that changes disk_gb after deploy. A disk is fixed for the life of the instance.
If you sized it too small, the only route to a bigger one is a new instance: copy your data off, destroy the old instance, and deploy again with a larger disk. See Getting data in and out.
The storage rate is charged per GB per hour, so an extra 50 GB is a small, predictable cost. Running out of disk part-way through a training run is not.
What lives where
The disk backs the container's filesystem. There are no host mounts and no attached volumes — everything the container writes lands on the disk you paid for.
| Path | What it holds |
|---|---|
/workspace | your data and code by convention, and JupyterLab's default root |
/root/.ssh/authorized_keys | the public key you attached at deploy, written at every boot |
/var/log/superheat/jupyter.log | the notebook server's output |
/var/log/superheat/onstart.log | the output of the template's onstart script |
The whole filesystem survives a stop and comes back untouched on start. The whole filesystem is deleted by a destroy, /workspace included. Nothing here is backed up.
What you pay, and when
| Instance state | Charge |
|---|---|
running | the GPU rate for the slice, metered per second |
stopped | the storage rate, per GB per hour, for the disk you provisioned |
creating, starting, stopping, destroying | nothing |
destroyed | nothing |
The storage charge is the one people forget. A stopped instance costs money every hour it stays stopped, and a large disk stopped for a month is a real bill for work that is not running. Charges settle about once a minute, so the balance on the billing page stays close to live.
Storage stops being charged the moment the instance is destroyed, because the disk no longer exists. That is the trade: Stop vs destroy walks through which one you want.