RunPod Volume Disk vs Network Volume vs Container Disk: What Each One Actually Keeps

Almost everyone who loses work on RunPod loses it the same way: they knew their data was "on a volume," and it turned out to be on the wrong one. RunPod ships three separate storage types, they are named similarly enough to blur together in the deploy form, and the difference between them only becomes visible at the exact moment it's expensive — when you terminate a pod, when your balance hits zero, or when you try to start the same setup in a different datacenter. I build the infrastructure layer under rented GPU boxes, so I spend a lot of time in provider storage docs. This is the version of RunPod's storage model I wish existed as one page.

TL;DR: Container disk dies when you stop the pod. Volume disk lives at /workspace and survives a stop but is deleted when you terminate. A network volume survives termination entirely, but it pins your pod to one datacenter and keeps billing while the GPU is off. Volume disk costs $0.10/GB/mo running and $0.20/GB/mo idle; network storage is $0.07/GB/mo under 1TB, $0.05 above, $0.14 for the high-performance tier. Pick by which failure you care about: losing the box, or being unable to leave it.

The three types, side by side

RunPod's own storage types page documents them as distinct products with distinct persistence guarantees. Here is the whole model in one table.

All prices are from RunPod's pricing page, which carries an "Updated July 27, 2026" stamp as of this writing. Check it before you budget against it — this is the kind of number vendors move quietly.

The single most important cell in that table is the "survives a terminate" row on volume disk. No.

The mistake that actually costs people work

Volume disk is described in RunPod's docs as "persistent storage that is retained throughout the Pod's lease," and that phrase is doing enormous work. Data in /workspace "survives Pod stops and restarts, but is deleted when the Pod is terminated" (RunPod storage types).

Read that as a lease, not as a disk. The volume disk is persistent relative to the pod, and the pod is the thing that goes away. So the mental model people build — "I put it in /workspace, /workspace is the persistent one, therefore it's safe" — is correct right up until the pod is terminated rather than stopped, at which point it is completely wrong and there is no undo.

The management docs put the boundary in one line: "Terminating permanently deletes all data not stored in a network volume" (manage pods). Not "all data not in /workspace." Not stored in a network volume. That's a much narrower carve-out than most people are running with.

Stopping is the gentler operation and it behaves the way you'd hope: "Stopping a Pod releases the GPU and preserves data in /workspace (volume disk). Container disk data is cleared. You'll still be charged for volume disk storage while stopped." Note the last sentence — and note from the pricing table that the stopped rate is double the running rate, $0.20/GB/mo idle against $0.10/GB/mo running.

That inversion catches people. The intuition is that stopping a pod is the frugal move; for storage specifically, stopping makes the per-GB meter more expensive, not less. You're paying a premium to hold a slot on a specific host.

What a network volume buys, and what it charges you for it

A network volume is the only one of the three that genuinely outlives the pod. RunPod describes it as "permanent storage that exists independently from any Pod," attachable to multiple pods, transferable between machines, retained "even after deleting a Pod" (storage types). It's backed by NVMe with documented "transfer speeds of 200-400 MB/s (up to 10 GB/s peak)" (network volumes).

So it fixes the terminate problem outright. It introduces four constraints in exchange, and only one of them is on the pricing page.

1. It pins your pod to a datacenter. This is the big one. "Attaching a single network volume constrains worker deployments to that volume's datacenter, which may limit GPU availability and reduce failover options." Your storage decision has silently become a compute decision — from now on you can only rent GPUs that exist in that one building.

2. Volumes don't sync to each other. RunPod's suggested fix for the datacenter pin is to attach multiple volumes across datacenters, with the explicit caveat: "You can only select one network volume per datacenter. Data does not sync automatically between volumes. To make the same data available to all workers regardless of datacenter, manually copy data using the S3-compatible API or runpodctl." Multi-datacenter means you now maintain N copies by hand, not that your data follows you.

3. It keeps billing at $0. "When your account balance reaches $0, Pods with an attached network volume are stopped and your data is preserved on the volume. Storage charges continue to accrue while the Pod is stopped, so if your balance stays at $0 and these charges can't be covered, the network volume may eventually be terminated and its data cannot be recovered." The docs deliberately don't commit to a grace period, so don't plan around one — turn on low balance notifications.

4. It can't be encrypted, and it's Secure Cloud only. RunPod supports encrypting a volume disk at rest, but is explicit that "Encryption applies only to volume disk. Container disk and network volumes cannot be encrypted." Separately, "Network volumes are only available for Pods in the Secure Cloud." If your compliance posture requires encryption at rest, the encrypted option is precisely the storage type that dies on terminate.

There's one contradiction in the docs worth knowing about rather than guessing at. The storage-types page lists network volumes as shareable "Yes (across Pods)," while the network-volumes page warns that "Writing to the same volume from multiple workers simultaneously may cause data corruption. Handle concurrent write access in your application logic." Read together, the honest interpretation is: attaching to multiple pods is supported, concurrent writes are your problem to serialize. Treat it as shared-read, coordinated-write, not as a POSIX-safe clustered filesystem.

Sizes, resizing, and the one-way door

Network volumes can be created from 1GB up to 4TB, and "volume size can be increased later but cannot be decreased. For volumes beyond 4 TB, contact support." Volume disk is likewise increase-only.

This matters more than it sounds. A one-off week where you unpack a large dataset permanently raises your storage floor, because there is no path back down other than creating a fresh volume, copying everything across, and deleting the old one. Size for your steady state and stage the spikes somewhere ephemeral.

Getting data out

If you need to move data between datacenters or off RunPod entirely, there are two first-party routes.

The S3-compatible API lets you read and write a network volume without launching a pod at all — useful, because otherwise you're paying for a GPU just to run a copy. It's available in a specific set of datacenters (RunPod lists EU-CZ-1, EU-RO-1, EUR-IS-1, EUR-NO-1, US-CA-2, US-GA-2, US-IL-1, US-KS-2, US-MD-1, US-MO-1, US-MO-2, US-NC-1, US-NC-2, US-NE-1, US-WA-1), and it's a partial S3 implementation: no ACLs, no versioning, no presigned URLs, multipart parts capped at 500MB, and ListObjects degrades on very large volumes.

runpodctl network-volume handles list, get, create, update (expand only), and delete. Notably, there is no cross-datacenter copy or move command — the volume object itself never relocates. "Moving" a volume always means copying its bytes into a new volume somewhere else.

Which one should you actually use

Work backwards from the failure you're most likely to hit.

Short interactive sessions on one provider, cheap to rebuild. Container disk plus volume disk is fine. Stop rather than terminate, accept the $0.20/GB/mo idle rate, and keep anything you'd cry about in a bucket.

Long-running work where the pod might get terminated or reclaimed. You need a network volume. Volume disk will not save you here, and this is the single most common way people lose a training run on RunPod.

Sensitive data at rest. You're in a genuine bind: encryption exists only on the storage type that dies on terminate. Encrypt the volume disk, and handle durability yourself by pushing to encrypted object storage rather than relying on a network volume.

You price-shop GPUs, or you keep hitting capacity limits. A network volume is actively working against you here. It pins you to one datacenter, and RunPod warns that restarting a stopped pod may allocate "zero GPUs if capacity has changed." When the H100s in your pinned region are gone, your storage is exactly what stops you from going where they aren't.

That last case is the one we care about, and it's a design problem rather than a configuration problem. A volume is a block device wired into one datacenter's fabric — no setting makes it portable, because portability was never a property it had. The alternative is to stop treating storage as an attachment and capture the whole box instead: filesystem, environment, installed packages at their versions, model files at their real paths, restored on whatever provider has stock. That's the approach we've written up in detail as a RunPod network volume alternative, and more generally in our guide to keeping a persistent cloud GPU environment across providers. If you're comparing what you'd pay elsewhere first, the live marketplace and our pricing page are the fastest read.

FAQ

What's the difference between volume disk and network volume in one sentence? Volume disk is local storage that lives as long as the pod does and is deleted when you terminate it; a network volume is independent storage that survives termination but pins your pod to one datacenter.

Does /workspace survive termination? No. /workspace on a volume disk survives stops and restarts only. On terminate it's deleted. If a network volume is attached, it replaces the volume disk at /workspace and does survive.

Why is my storage bill higher when the pod is stopped? Because volume disk is billed at $0.20/GB/mo idle versus $0.10/GB/mo running. Stopping saves you the GPU cost, not the storage cost — it raises the storage rate.

Can a network volume move to a different datacenter or provider? No. There's no move operation. You copy the contents out via the S3-compatible API or runpodctl and into a new volume elsewhere. Between providers, not even that — you need a neutral copy of both the data and the environment.

Can two pods use the same network volume at once? You can attach one to multiple pods, but RunPod warns that simultaneous writes from multiple workers may corrupt data and tells you to handle concurrency yourself. Safe for shared reads, risky for uncoordinated writes.

Do I lose my network volume if I run out of credit? Not immediately. The pod stops and the data is preserved, but storage charges keep accruing, and if the balance stays at zero the volume may eventually be terminated with no recovery. RunPod doesn't publish a grace period, so enable low balance notifications.

The thing worth remembering

RunPod's three storage types are really three different answers to "what are you willing to lose." Container disk assumes you'll lose everything and don't care. Volume disk assumes you'll lose the pod but not on purpose. A network volume assumes you'll lose the pod and keeps going — but quietly takes your ability to leave the building as payment.

None of the three is wrong. What's wrong is picking one from the deploy form without knowing which of those three bets you just made, which is how a /workspace full of checkpoints disappears on a terminate that seemed routine.

About the author

I'm Ansh Saxena. I work on the infrastructure layer under rented GPU boxes, mostly on the unglamorous problem of making a machine's whole state portable, so the box you happen to be renting stops being the only copy of your week's work. I don't have a stake in which storage type you pick on RunPod — I do think the docs bury the one sentence that decides it.

Sources

• RunPod storage types. Container disk cleared on stop; volume disk at /workspace retained through the pod's lease and deleted on terminate; network volumes independent and shareable; encryption applies only to volume disk.
• RunPod network volumes. NVMe at 200-400 MB/s, up to 10 GB/s peak; datacenter constraint on deployments; no automatic sync between volumes; zero-balance accrual and eventual termination; size increase-only, 4TB ceiling before contacting support; Secure Cloud only.
• RunPod manage pods. Stop preserves /workspace and clears container disk, storage still billed; terminate permanently deletes all data not on a network volume; restart may allocate zero GPUs if capacity changed.
• RunPod pricing, updated July 27, 2026. Container disk $0.10/GB/mo; volume disk $0.10/GB/mo running and $0.20/GB/mo idle; network storage $0.07/GB/mo under 1TB, $0.05/GB/mo above, high-performance tier $0.14/GB/mo.
• RunPod S3-compatible API. Supported datacenter list and documented limitations.
• runpodctl network-volume reference. List, get, create, expand, delete; no cross-datacenter transfer command.