Where Did My Files Go? A Straight Guide to Runpod Storage

TL;DR: Runpod has three storage layers with very different lifetimes. The Container Disk is temporary scratch space that's wiped whenever your Pod stops, resets, or is edited,: including your pip/apt installs and HuggingFace cache. The Volume Disk (mounted at /workspace) survives stops but is permanently deleted when a Pod is terminated. A Network Volume exists independently of any Pod and is the only storage that survives termination. Most data loss on Runpod comes from four avoidable mistakes: saving files outside /workspace, terminating a Pod when you meant to stop it, editing a running Pod's configuration, or letting a prepaid balance hit zero. Keep models, datasets, and checkpoints on a Network Volume, back up anything irreplaceable off-platform, and download your outputs before you terminate., Runpod doesn't retain copies of your data, so the only backup is the one you make.

You left a LoRA fine-tune running overnight. This morning, the Pod is gone. Maybe you terminated it to stop the billing, maybe your balance ran dry. Either way, the checkpoints went with it: twelve hours of GPU time, unrecoverable. And no support ticket can bring them back, because for privacy reasons, Runpod doesn’t keep copies of your data. The only backup that exists is the one you made.

This is the most common way people make mistakes on Runpod, and it’s avoidable. It’s also not really your fault. “Stop” and “terminate” sound almost interchangeable, “edit” sounds harmless, and nothing about a local PC prepares you for storage that disappears. On your own machine, files stay where you put them. This blog post aims to teach you how Runpod storage works before it costs you, not after.

The mental model

A Pod is a container, and containers are disposable by design. That’s what makes renting a GPU cheap and fast: the machine can be created, reset, and destroyed in seconds. To make that possible, Runpod provides three storage layers with distinct lifetimes. One lives as long as the running container. One lives as long as the Pod. One lives on its own, independent of any Pod. Every data loss story on this platform comes down to a file sitting on a layer with a shorter lifetime than its owner assumed. Keep that one idea in mind, and the rest of this post is just details.

The three storage types

Container Disk

Container Disk is scratch space attached to the running container. The operating system lives here, your installed packages live here, and anything you save outside /workspace ends up here by default. It survives a plain restart of the container, and that’s it: stopping, resetting, editing, or terminating the Pod all wipe it.

More lives here than you’d guess. Every apt install you run. Anything pip install puts into the system Python. The HuggingFace cache at ~/.cache/huggingface quietly collects gigabytes of model data. Your home directory, /tmp, and custom nodes you cloned into the wrong folder. All of it sits on the Container Disk, and all of it is gone whenever the pod restarts for any reason, whether you click stop or restart or there’s some other technical concern that forces the issue. If you’ve ever come back to a Pod and wondered why you’re reinstalling the same packages for the third day in a row, this is why. Nothing was wrong with your setup. It was just living on the wrong layer.

The size isn’t a platform default either. It’s chosen by whoever made the template, and template creators tend to keep it small, often just 5 GB, which is why so many first sessions end with No space left on device halfway through a model download (unless you use --local-dir which will put it to the directory you specify, rather than the container.) Take that error as a hint: Container Disk is not where your real work should live. Think of it as RAM with a filesystem. Useful while the container runs, gone the moment it isn’t.

Volume Disk

Volume Disk is a persistent storage volume attached to a single Pod and mounted at /workspace. It survives stopping and restarting, so you can shut a Pod down overnight to pause GPU billing and pick up where you left off in the morning. Anything you care about during a session belongs under /workspace.

A warning before you build habits around that path: /workspace is a convention, not a guarantee. Official templates use it, but community templates are free to mount the volume elsewhere or give it less space than you’d expect. Before trusting a new template with real work, check where the volume is actually mounted. Opening the Pod’s edit window shows you the full configuration, and looking is safe: nothing changes unless you press save, and the window warns you before you do. Then confirm it from inside the Pod with df -h, which shows which directories sit on which disk. Thirty seconds of checking beats finding out after an overnight run.

Three more things worth knowing. A Volume Disk can only be increased in size, never decreased, so start modest and grow it as needed. If you encrypt the pod volume, it can’t be changed at all after the pod starts up for the first time. And the big one: a Volume Disk is deleted when its Pod is terminated. It persists across stops, not across the Pod’s death. If the Pod goes, /workspace goes with it.

Network Volume

A Network Volume is persistent storage that exists independently of any Pod. Terminate the Pod, and the volume just sits there, waiting. You can detach it from one Pod and attach it to another. When attached, it replaces the Volume Disk at /workspace, so your workflow doesn’t change, same path, longer lifetime.

There are two constraints. A Network Volume has to be attached when the Pod is created; you can’t add one to an existing Pod later. And a Network Volume lives in a specific datacenter, which means Pods using it can only launch in that region. This is the big tradeoff with network volumes; you have enormous flexibility for simply restarting your work rather than risking it being stuck on a single machine with no GPUs available, but you are limited to the GPUs in that particular data center when you do start back up.

Regardless, this is where your models, datasets, trained checkpoints, and anything else you’d be upset to lose should live.

What survives what

When you’re not sure whether something will survive an action, check the row before you click.

The four ways people actually lose data

None of these are silly mistakes. Each one is a reasonable action on a platform whose defaults don’t match intuition, which is why they keep happening to smart people.

1. Saving outside /workspace

ComfyUI outputs, Kohya checkpoints, and downloaded models. If a tool’s default output directory points somewhere on the container filesystem, everything it writes is on borrowed time. Some templates handle this for you. Many don’t, and a tool you installed yourself certainly won’t.

The fix: make the persistent path a habit. Explicitly point to the output directories, model folders, and download paths at /workspace, and remember the earlier warning: on a community template, first confirm that /workspace is actually where the volume is mounted. Check where a tool writes before the long job, not after. df -h will tell you which mount a directory really lives on.

2. Terminating when you meant to stop

Stopping a Pod shuts it down but keeps its Volume Disk. You stop paying for the GPU and keep paying for storage. Terminating permanently deletes the Pod and its Volume Disk. The two words sound similar, and the two actions could not be more different. Nobody makes this mistake because they’re careless. They make it because the naming is confusing, and the action can’t be undone.

The fix: before you terminate anything, ask yourself whether there’s anything in /workspace you still need. If yes, download it or sync it out first. Termination should be the last step of a session, never a way to pause billing. Pausing is what stop is for.

3. Editing a running Pod

Changing a Pod’s configuration resets it completely and erases everything not stored in /workspace. This one surprises even experienced users, because “edit” sounds like the gentlest word on the page. Under the hood, an edit rebuilds the container, and the Container Disk gets rebuilt with it. Resetting a Pod does the same thing, for the same reason. A plain restart, on the other hand, keeps the Container Disk intact, which is part of why the difference between these actions catches people off guard.

The fix: treat saving an edit as destructive, because it is. Opening the edit window just to look at the configuration is fine; the reset only happens when you save your changes, and Runpod warns you before it does. Before you save, make sure everything you need is under /workspace, and expect to reinstall whatever lived on the Container Disk.

4. Letting your balance hit zero

Runpod is prepaid. If your balance reaches zero, your Pods can be terminated, and as you now know, terminated means the Volume Disk is gone. Data on a Network Volume is more likely to survive a lapse, which is one of the strongest arguments for using one. But an unfunded account is not a safe place for anything.

The fix: turn on Auto-Pay in your billing settings. It’s off by default, so unless you’ve enabled it yourself, you don’t have it. You add a card, set a threshold and a top-up amount, and when your balance nears the threshold, Runpod recharges it from your saved card. If you’d rather not keep a card on file, at least check your balance before starting any long job. A rough sanity check takes ten seconds: hourly rate times hours remaining, compared against what’s in your account. That habit has saved more training runs than anything else on this list.

Making your environment survive a stop

Your files in /workspace persist. Your environment, meaning the packages you installed, mostly don’t, because installs land on the Container Disk by default. This is why the second morning on Runpod so often starts with reinstalling everything from the first morning. The good news is you can fix it once and be done with it.

For Python packages, the answer is a virtual environment that lives on the persistent disk:

cd /workspace
python -m venv venv
source /workspace/venv/bin/activate
pip install -r requirements.txt

Everything pip installs now lands inside /workspace/venv, so it survives stops right alongside your data. After a restart, one line brings the whole setup back:

source /workspace/venv/bin/activate

One caveat: a venv is tied to the Python path it was created with. If you later switch to a template or image that ships a different Python version, the venv can break and need to be recreated. In practice, that means this trick works best when you stick to one template or pair a Network Volume with the same image every time.

The same idea rescues the HuggingFace cache, which otherwise re-downloads your models onto the Container Disk every session:

export HF_HOME=/workspace/huggingface

Set that before running your tools, or configure it as an environment variable on the Pod, and models and tokenizers download once and stay put.

apt packages are the awkward ones. They install into system directories on the Container Disk, and there’s no good way to relocate them. You have two realistic options. The first is a small script in /workspace, such as/workspace/setup.sh, that reinstalls what you need after each startup. It runs in seconds once written, and it doubles as documentation of your own setup.

The second, once your environment settles down, is to build your own Docker image with those packages baked in. This is less intimidating than it sounds. If you always need ffmpeg for video work, the entire Dockerfile is three lines:

FROM <the image your current template uses>
RUN apt-get update && apt-get install -y ffmpeg && \
    rm -rf /var/lib/apt/lists/*

Build it, push it to a registry like Docker Hub, and point a custom template at it. Every fresh container now starts with your packages already installed. Starting FROM the image your current template uses also keeps everything else working as before, including any venv you built in the workspace using that image’s Python.

Choosing your setup

For a one-off experiment, something you’ll generate, download, and never touch again, a plain Pod with a Volume Disk is fine. Work in /workspace, download the results, terminate, done.

For anything you’ll reuse across sessions, such as base models, datasets, LoRAs in progress, or a ComfyUI setup you spent an evening tuning, create a Network Volume and attach it when creating the Pod. Your files persist after termination, and tomorrow you can attach the same volume to a larger GPU without re-downloading 30 GB of models.

There’s one trade-off that matters: a Network Volume pins you to its datacenter. If the GPU you want isn’t available in that region right now, you’ll see “no GPUs available,” which may look like a Runpod outage. It isn’t one. Your volume’s location has narrowed the pool of machines you can rent. So before creating a volume, check which regions reliably stock the GPU types you use and put the volume there. If you ever get truly stuck, you can move your data to a volume in another region, but that’s a chore you’d rather avoid by choosing well up front.

Back it up anyway

None of the above turns Runpod into a backup service, and that’s a deliberate choice, not a gap. Runpod doesn’t keep copies of your data, for the same privacy reasons you’d want it not to: your files are yours, and when you delete something, it’s actually gone, not sitting in a copy somewhere. The flip side of that respect for your data is that backing it up is your job. There’s an old saying that the cloud is just someone else’s computer, and it applies here. A GPU platform is a place to compute, not a place to archive. Anything you’d genuinely miss should also exist somewhere you control.

There are two practical routes. Cloud Sync, available from the Pod page, exports your data to S3, Google Cloud Storage, Azure, or Dropbox. And runpodctl, the command line tool, can move files between your Pod and your local machine.

The cheapest habit of all costs nothing: download your outputs before you terminate. Every time, even when you’re sure there’s nothing important in there. The one time you skip it will be the time a checkpoint you forgot about was sitting in /workspace. The S3-compatible API is a good way to handle this automatically; you can set up scripts to automatically pull outputs locally or wherever else you’d like to save them.

Quick answers to the questions we see every day

“I stopped my Pod, and my files are gone. Can you support restoring them?” If you stop the Pod, anything in /workspace remains when you restart it. What’s missing is whatever lived on the Container Disk, including installed packages. If the Pod was terminated, the Volume Disk is gone, and no, support cannot restore it. For privacy reasons, Runpod doesn’t retain copies of user data, so there is nothing to restore. The only backup is the one you made yourself. We know that’s a hard answer to read after a loss.

“Why can’t I attach a Network Volume to my existing Pod?” Network Volumes can only be attached when a Pod is created. Move your data out of the current Pod using Cloud Sync or runpodctl, create a new Pod with the volume attached, then move the data in.

“Why is my GPU showing unavailable after I made a Network Volume?” The volume is tied to its data center, and that region doesn’t have your GPU available right now. It’s not an outage. You can wait, pick a different GPU type available in that region, or plan to move to a volume in a better-stocked region.

“Do I get charged when my Pod is stopped?” GPU billing stops, storage billing doesn’t. You keep paying for the Volume Disk per GB per month, at a higher rate than while the Pod is running. For exact figures, check the pricing page, since rates change, but in general a network volume’s price will always be equal to or cheaper than on-machine storage.

“Why does pip install say No space left on device?” Your Container Disk is full. The template creator sets its size, and it’s often just 5 GB. Give the Pod a larger Container Disk, and keep large downloads like models in/workspace where there’s room. Use --local-dir when downloading using the Huggingface CLI to keep everything where you specify rather than defaulting to the container.

“Why is everything I installed gone after I start my Pod again?” Because pip and apt install onto the Container Disk unless you tell them otherwise, and the Container Disk resets. Put your Python packages in a venv under /workspace, move the HuggingFace cache there too, and script your apt installs. The section above on making your environment survive walks through all three.

“Can I shrink my Volume Disk to pay less?” No. Volume Disks can be increased but never decreased. If you overshot badly, the way down is to move your data to a new, smaller setup. It is worth noting that due to the price decrease per GB once you hit 1001 in the volume, you may actually pay less total if you increase the size of the volume if you’re sitting in the spot between 700 and 1000 GB.

The rule of thumb

If it took more than ten minutes to make, it should not be living on the Container Disk. And if it would take more than a day to remake, it should not be living only on Runpod.

‍