Global Volumes aren't "network volumes, but better." Here's what they're for.

When we launched Global Volumes in beta, the idea was simple: store a model once, then deploy your Pod wherever GPUs are free and find the same files at /workspace-global. Your 200GB of checkpoints no longer tie you to one datacenter.

Since then we've seen some pretty common questions arise that are something along the lines of "I can run ComfyUI just fine from my network volume but I'm getting this funky permission error when I try it on a global volume."

The answer is in what’s underneath. Network volumes are a network filesystem. Global Volumes are built on object storage. Both show up as a folder in your Pod, but they behave very differently, and that affects what you should put on them.

The short version: Global Volumes hold the things you store, not the code you run.

Two kinds of storage that look the same

Network volumes: a filesystem that happens to be remote

A network volume acts like a disk. Your Pod can open a file, seek to the middle, change 4 KB, append to a log, take a lock, create a symlink, and list a directory of 40,000 files. All of that is cheap, because the storage sits on a cluster in the same datacenter as your GPU, built for exactly that kind of filesystem traffic. The trade-off is location. A network volume lives in one datacenter, so your Pods have to run there too.

Global Volumes: objects, presented as files

Object storage (the same model behind S3, GCS, and R2) doesn't really have "files" and "directories." It has objects: whole blobs of data saved under a key such as models/checkpoints/flux1-dev.safetensors. You put an object, you get an object, you delete an object. That simple model is what allows object storage to be global, elastic, and durable. Data doesn't have to sit next to one GPU rack.

When you mount a Global Volume at /workspace-global, a filesystem layer turns normal file operations into object operations. That works well for what it was designed for, like reading a large model file or writing a finished output. Operations that are trivial on a real filesystem, such as editing a file in place, renaming, taking locks, following symlinks, or opening thousands of small files, get slow or unreliable. That isn’t a bug; it’s how object storage works.

Why installing ComfyUI (or other similar packages) on a Global Volume hurts

Think about what a ComfyUI install actually is:

• A Python environment with tens of thousands of small .py, .pyc, and .so files. Starting Python and importing torch means stat-ing and opening a huge number of them. On object storage, each one can cost a network round trip.
• Custom nodes cloned with git. A .git directory is thousands of small objects plus lock files, and git expects proper filesystem behavior.
• pip installs that create, rename, and delete files in quick succession, and rely on symlinks and executable permissions.
• Runtime state: logs that grow line by line, config files rewritten in place, caches, and sometimes SQLite databases.

Every item on that list depends on the operations object storage handles poorly. Meanwhile the part of ComfyUI that object storage handles really well, the multi-gigabyte model files, is usually the smallest part of the problem people are fighting.

What belongs on a Global Volume

Good fits are things you write once, read many times, and read whole:

• Model weights: checkpoints, safetensors, GGUF files, LoRAs, VAEs, ControlNets, embeddings
• Datasets: training shards, image sets, tarballs, Parquet files
• Training checkpoints saved at intervals (written once each, read back on resume)
• Generated outputs: images, videos, audio, eval results
• Archives and artifacts you want available in every region

Bad fits are things that execute, change in place, or come in thousands of tiny pieces:

• Application installs (ComfyUI, A1111, etc.)
• Python virtual environments and Conda envs
• Git repositories you work out of
• Databases, lock files, and live logs
• Build caches and node_modules

Keep your code local, and your data global

Run the app close to the GPU, on a network or local volume, and keep the models on the Global Volume. The easiest way is to let a Runpod template handle the ComfyUI install. The things the template doesn’t include, like your models and LoRAs, can live on the Global Volume, where any Pod can reach them. If you want your custom nodes there too, store them as an archive and unpack them onto local storage when the Pod starts.

I used to handle this with a script that pulled all my models from Hugging Face every time I started a new Pod. Now that whole library can stay inside Runpod.

The takeaway

Global Volumes mean your data no longer decides where your GPUs have to be. They accomplish this by being object storage, which is excellent at holding large files you read back whole and poor at acting like a hard drive for running software.

Keep the install local and the models global, and you get GPU availability across every Runpod datacenter without the slow startups.

Questions or edge cases we didn't cover? Ask us on Discord or Reddit, or check the Global Volumes docs.

‍