Skip to main content
Runpod offers four kinds of storage that keep your data beyond a single session. They differ in where the data lives, what it survives, and how much they limit where your compute can run. The closer the storage is to your machine, the faster it is and the more it constrains placement. Every Pod and Serverless worker also has a container disk for the operating system and temporary files. The container disk is wiped whenever a Pod stops or restarts, so don’t keep anything on it that you need later. See Pod storage options and Serverless storage.

Storage types at a glance

Volume disk

The volume disk is a disk on the physical machine that runs your Pod, mounted at /workspace by default. Data survives stopping and restarting the Pod, but it’s deleted when you delete the Pod, and it can be lost if the machine fails. Because the data is on one machine, your Pod can only start where that machine has a free GPU. Otherwise you must migrate the Pod, which copies the volume disk to a new machine. Use the volume disk for data you can recreate. For anything you can’t, use a network volume. The volume disk is available on GPU Pods only, and can’t be combined with a network, global, or external volume.

Network volume

A network volume lives in one data center and attaches to your Pod or worker over that data center’s high-speed network. It’s the fastest storage that exists independently of your compute: it survives Pod deletion, and you can attach it to many Pods and endpoints. A high-performance tier offers up to 3x the throughput and 4x the IOPS of the standard tier. The tradeoff is placement. Compute that mounts a network volume must run in the volume’s data center, so you can only choose GPUs that data center has available.

Global volume

A global volume (beta) isn’t tied to a data center, so compute in any supported data center can mount it and the volume doesn’t limit which GPUs you can use. Capacity grows with your data, and you’re billed for storage plus read and write requests. Global volumes are object-backed and eventually consistent, and don’t support file locking, atomic rename, or hard links. They work best for data you write rarely and read often, such as model weights for inference. For frequent writes, use a network volume.

External volume

An external volume connects an S3-compatible bucket you already own, such as Amazon S3 or Backblaze B2, to Runpod. You register the bucket once with an access key, optionally scoped to a key prefix, and then mount it like any other volume. Your data stays in your bucket, so there’s nothing to upload to Runpod first, and compute in any data center can mount it. Performance depends on your storage provider and how far the bucket is from the data center your compute runs in. Your provider bills you for storage and requests as usual.

Choose a storage option

  • Use the volume disk for scratch data on a single Pod that you can afford to lose.
  • Use a network volume when your workload runs in one data center and needs fast, consistent reads and writes, such as training checkpoints or a shared model cache for an endpoint.
  • Use a global volume when you deploy to multiple regions, or want the widest choice of GPUs, and need the same models or datasets everywhere without copying them.
  • Use an external volume when your data already lives in S3-compatible storage and you want to use it on Runpod without moving it.
  • Use the S3-compatible API to upload or download files on a network volume from your local machine or a CI pipeline.

Where volumes mount

Next steps

Network volumes

Create a volume in one data center.

Global volumes

Mount the same data in any data center.

S3-compatible API

Transfer files to a network volume.

Pod storage options

Container disk, volume disk, and resizing.
Last modified on October 30, 2026