Vast.ai's own FAQ puts the two outcomes right next to each other: stop an instance and "data persists, storage charges continue"; destroy it and "all data is permanently deleted" (Vast.ai, Instances FAQ). That's a clean rule until you notice what it implies — a stopped instance is still on the meter for its disk, and there is exactly one button between "safe" and "gone." I build the infrastructure layer under rented GPU boxes, and Vast.ai's marketplace model — you're renting a slice of someone else's host, not a slot in a hyperscaler's fleet — makes the storage story different from RunPod's or Lambda's in one specific way worth knowing before you commit a week of work to a box.
TL;DR: Vast.ai's default container disk is deleted the moment you destroy the instance, and it keeps billing at its per-GB rate for as long as the instance exists, running or stopped. Vast.ai also offers Volumes — persistent storage that outlives an instance — but a Volume is tied to the physical host it was created on: it can only attach to instances on that same host and cannot migrate between machines. Storage rates aren't a flat platform number; they're set per host and shown at instance selection.
The two storage types, and the rule that separates them
Vast.ai's storage docs describe two distinct things. Container storage is "the default storage allocated to every instance when it's created" — it lives and dies with that instance. Volumes are separate: "persistent storage that survives instance destruction and can be reattached to new instances" (Vast.ai, Storage Types).
| Property | Container disk | Volume |
|---|---|---|
| Survives a stop? | Yes, data persists | Yes |
| Survives a destroy? | No — permanently deleted | Yes, if the volume itself isn't deleted |
| Billed while stopped? | Yes, storage charges continue | Yes, charged per GB while it exists |
| Attachable to another instance? | No | Yes — but only on the same host |
| Can move to a different physical machine? | No | No |
| Price | Set per host, shown at instance selection | Set per host, shown at instance selection |
The FAQ's phrasing on the destroy case is unambiguous: "all data is permanently deleted" the moment you destroy the instance (Vast.ai, Instances FAQ). There's no grace window documented, and the FAQ's own advice reflects that: "always backup important data to external storage" before you get anywhere near that button.
The part that's easy to miss: a Volume doesn't leave the host either
A Volume looks, at first read, like the fix — it survives destroy, it reattaches to new instances. Read the constraint next to it, and it stops looking like general-purpose persistent storage: a Volume "can only attach to instances on the same host" and "cannot migrate between different physical machines" (Vast.ai, Storage Types).
That's a tighter lock than the datacenter-level pin you'll see on most hyperscaler-style network volumes. On Vast.ai's peer-to-peer marketplace, "the host" isn't a region with hundreds of interchangeable machines behind it — it's one physical box owned by one operator. If that host goes offline, gets pulled from the marketplace, or simply doesn't have the GPU model you want available next time you look, the Volume sitting on it is stuck exactly where it is. You didn't lose your data. You lost the ability to compute against it anywhere else.
This is also why Vast.ai's disk pricing resists a single number the way RunPod's or Paperspace's does: "storage costs vary by host" (Vast.ai, Pricing FAQ), set by whoever owns that machine, and shown to you at instance-selection time rather than published as one platform-wide rate. Budgeting against Vast.ai storage means checking the specific host's number, not a blog post's table.
What actually gets deleted on destroy
Everything that isn't on a Volume: the container disk's contents, which on most setups is the whole working environment — installed packages, your virtualenv, pinned custom-node commits, config, and any model weights or outputs you didn't explicitly write to a mounted Volume path. Vast.ai's disk-size behavior compounds the planning problem: "disk size is permanent and cannot be changed after instance creation" (Vast.ai, Instances FAQ), so under-provisioning means a fresh instance, not a resize.
The auto-teardown case is worth flagging separately, since it fires without you touching the destroy button at all. Vast.ai's rental-types documentation says an interruptible or time-limited rental is torn down automatically once its window closes, and the guidance is blunt: "it is best to assume that your instance will be lost once its lifetime expires" (Vast.ai, Rental Types). If you're on a short-lifetime or interruptible listing, the destroy event can happen on the provider's clock, not yours.
Where this actually leaves you
If you stay on one host and never expect to move, Vast.ai's model is workable: keep a Volume attached, don't write anything you care about outside it, and remember the storage meter runs whether or not the GPU is doing anything. That's the same trade every network-volume design makes — durability in exchange for a standing bill.
The host-lock is the part that's specific to Vast.ai's marketplace shape, and it's the part that bites people who are price-shopping, which is the whole reason most people are on Vast.ai in the first place. A Volume that can't leave its host is not protecting you from the exact failure that sends people to a peer-to-peer marketplace: a host going away, or a better GPU showing up somewhere else. The alternative isn't a bigger or better Volume — it's not depending on the host at all. Pausing a box and resuming it on a different provider, environment intact, works by capturing the whole filesystem rather than attaching to one — the install at its commit, the venv, models at their real paths — and restoring it wherever a GPU is actually available, host or provider changed or not. That's workspace backups on Aquanode: snapshot on a schedule or by hand, restore on demand. If you're weighing what that costs against staying put, the live marketplace and pricing pages are the fastest comparison, and our broader guide to keeping a persistent GPU environment across providers covers the general version of this problem beyond any one vendor.
FAQ
Does Vast.ai charge for storage while an instance is stopped? Yes. Vast.ai's FAQ states data persists and "storage charges continue" while an instance is stopped but not destroyed. The meter only stops when you destroy the instance (and delete any attached Volume).
Can I move a Vast.ai Volume to a different host or provider? No. A Volume "can only attach to instances on the same host" and cannot migrate between physical machines, per Vast.ai's storage docs. Moving the data means copying it out to external storage and reattaching or re-uploading elsewhere.
How much does Vast.ai storage cost per GB? There's no single platform-wide rate — Vast.ai's own FAQ says storage costs vary by host, and the specific rate is shown when you select an instance.
What happens to my data if I destroy an instance without a Volume attached? It's gone. Vast.ai's FAQ is explicit: "all data is permanently deleted" on destroy, with no documented recovery window.
About the author
I'm Ansh Saxena. I work on the infrastructure layer under rented GPU boxes — making a machine's whole state portable, so the specific host or provider you happened to rent from stops being the only place your work exists. I don't have a stake in which marketplace you rent from; I do think Vast.ai's host-level storage lock is underexplained relative to how much it constrains you later.
Sources
- Vast.ai Instances FAQ. Data persists and storage bills while stopped; permanently deleted on destroy; disk size fixed at creation; back up to external storage.
- Vast.ai Storage Types. Container storage is the default, deleted with the instance; Volumes are persistent storage that survives destruction but attach only within the same host and cannot migrate between machines.
- Vast.ai Pricing FAQ. Storage costs vary by host.
- Vast.ai Rental Types. Interruptible/time-limited rentals are automatically stopped once their lifetime expires; assume the instance is lost once that happens.
