Answers

Can I move a RunPod network volume to another region or another cloud?

A standard network volume is tied to one region of one provider, so moving it means copying its contents somewhere else. Check your provider's own options first; some offer volumes that aren't tied to one region, or tools to move data between regions. A nest is a separate copy of a working setup that isn't tied to any provider: restore it on any machine you can rent, in any region, and every file is checked on the way in.

It's hard to get the GPU I want in the region my volume is in. Can I make a copy of my network volume?

Yes, but it is a copy, not a move: the volume itself stays where it is. A network volume lives in one data centre, and a pod can only attach volumes from its own data centre. If the GPU you want is in another region, you need the contents in that region. Your options:

• Your provider's own tools. Providers add these over time: volumes that aren't tied to one region, ways to copy or move a volume, file access without a running pod. Check your provider's documentation for what it offers today.
• Copy it yourself through a running pod, as described below.
• Pack the working setup as a nest and restore it in whichever region has the GPU, as described below.

My stopped pod says "Zero GPUs" or "Your Pod's GPUs are no longer available". How do I get my setup onto another machine?

A stopped pod can only restart on the physical machine it was on. If that machine's GPUs have been rented by someone else in the meantime, the pod comes back with no GPU. New pods with the same GPU type may still be available, on other machines. The pod's own disk stays with the old machine, so you need to get your setup onto the new one: start the old pod without a GPU if your provider allows it and copy the files off, or restore from a copy you already keep elsewhere.

This is where a nest helps most. A restore code isn't tied to a machine: if the first box you rent is broken or has no GPU, terminate it and paste the same command on the next one.

How do I copy a network volume to another region or cloud myself?

Attach the volume to a pod (a cheap one is fine; copying needs no GPU) and copy the contents to the destination with a file-transfer tool such as rsync, rclone to an object store, or RunPod's runpodctl. Then attach the new storage to a pod in the region you want.

That copies files. It doesn't copy a working environment: a virtual environment built on the old pods may not work on the new ones, and system libraries were never on the volume. See why ComfyUI still breaks on a new pod when everything is on a network volume. Also check that each large file arrived whole before you delete anything at the source.

I'm being charged for a network volume when I can't use any GPU pods. What can I do?

A network volume is billed for as long as it exists, whether or not a pod is attached. If the region has no GPUs you can use, you are paying for storage you can't use there. To stop that charge you have to delete the volume, so first get what you need out of it: copy it to another region or provider, or pack the setup as a nest. Whether keeping a copy somewhere else costs less depends on how much you store and where; see Pricing for Renest's side and do the sums for your own use.

How do I move a volume setup with Renest?

A nest isn't a copy of the volume. It's a record of one run that worked: the model weights, the custom nodes pinned to their commits, the workflow, the exact Python package versions, and which system libraries the run loaded. It is kept in your Renest drive, independent of any GPU provider.

1. On a pod in the volume's region where the workflow still produces images, install the tool and an access key (see the RunPod guide), export the workflow in API format, and pack:

$ renest pack --dir /workspace --workflow workflow-api.json \
    --out /workspace/nests --dest hosted

2. Rent a machine wherever the GPU is: another RunPod region, or vast.ai. In the web console, open the nest, choose Restore, and paste the command it gives you:

$ renest restore --grant grant.json --dir ./run
$ renest start --dir ./run --listen 0.0.0.0

Before the big download, the restore checks the new machine: it refuses a GPU generation the nest's PyTorch build has no code for, a driver too old for its CUDA build, or a CPU without avx2, and it names any system library the original run loaded that this machine lacks, with the command to install it. Then it downloads every file and checks it against its checksum, installs the locked packages, starts ComfyUI and runs the workflow once. Starting the app is covered in After the restore.

Once the nest is in your drive and you have restored it somewhere else, you can decide whether to keep the volume. That's your call; Renest never touches it. Files coming back checked and the app working are counted separately; our own results are on the Proof page.

When Renest isn't the answer

If your provider's own migration or region-independent volume covers the move, and you never change provider, use that. It keeps everything on the volume as it is, with nothing to pack. Renest is for when you want the setup to go to a different provider, to any region, or to a machine you rent only when you need it.