Answers
Should I use a network volume, my own Docker image, a ComfyUI-Manager snapshot, or something else to keep a working ComfyUI?
Each keeps a different layer. A network volume keeps files in one provider's region; a Docker image freezes the system and Python layers; a ComfyUI-Manager or Desktop snapshot records which versions you had and installs them again; a nest keeps the files themselves plus the exact package versions, and checks them on the new machine. Pick the one that keeps the layer you'd lose.
Is a network volume enough to keep my ComfyUI?
It keeps your files — models, custom node folders, outputs — inside one region of one provider, and that's its right use: the next pod in that region mounts them in place. What it doesn't keep is a working environment on a different machine. Python packages installed into the container are gone when the pod stops, a venv on the volume was built for the machine that made it, and system libraries live in the container image. It also bills while no pod is running, and a pod can only use it where a GPU is free in that region.
Should I build my own Docker image for ComfyUI?
An image freezes the operating system and the Python layer, which makes it the right tool for deployment, serverless endpoints and anything that must start the same way many times. Keep models out of it — a model baked into the image makes it huge and slow to start, so models usually go on a volume. And what's frozen in it was built for the GPUs of its day: a newer GPU generation can need a different torch build than the one inside.
Does a ComfyUI-Manager snapshot restore bring back everything, including pip packages?
No — a snapshot is a record of versions, not a copy. A ComfyUI-Manager snapshot records the ComfyUI commit, each custom node's repository and commit, and a list of pip packages. Restoring it checks out or clones those repositories again and installs packages again from the network; whether the recorded pip list gets applied has depended on the Manager version and how you restore. The ComfyUI desktop app's snapshots record the ComfyUI version, each custom node's version or commit, and the installed Python packages, and restoring installs or adjusts them to match. Neither one carries model files or workflows.
That makes a snapshot the right tool for rolling back an update on the machine you're on, or for getting the same node versions onto a machine that already has your models. It depends on every repository and package still being downloadable.
What does a nest keep that the others don't?
A nest is packed from a run that already worked. It keeps:
- The files themselves — the model files the workflow used and each custom node's source, pinned to its commit — so a restore doesn't depend on a repository or a download link still existing.
- The exact package versions that were installed, reinstalled for the new machine without re-resolving.
- What the machine provided — GPU generation, driver, the system libraries the run loaded.
On restore it checks the machine first and stops before downloading when the GPU generation, driver or CPU can't run the recorded build; it names missing system libraries with the command that installs them. Then it checks every file against its recorded checksum, reinstalls the packages, starts ComfyUI and runs the workflow once, and reports which steps passed. It isn't tied to one provider, the format is open, and restore.sh brings the files and dependencies back without Renest.
What it isn't: a disk image. Packages are installed fresh on the target, so a GPU generation the recorded build doesn't support is refused, not adapted. Our own results, failures included, are on the Proof page.
So which one should I use?
- Same region, same provider, used often — a network volume.
- Deploying, serverless, many identical starts — a Docker image with models on a volume.
- Rolling back node updates on this machine — a Manager or Desktop snapshot.
- Moving a setup that works to another machine, region or provider, models included — a nest.
They combine: you can restore a nest onto a pod that also mounts a volume, and our base image is itself a small Docker image.
When Renest isn't the answer
- Serverless or production deployment — build a Docker image and keep models on a volume; Renest isn't a deployment platform.
- You always rent in the same region — a network volume already keeps your files where the next pod can mount them.
- You only need to undo a bad node update on this machine — use a snapshot.
Related: What a ComfyUI backup has to include · Keep a setup between cloud sessions · Pinned, not latest
These docs describe renest 0.1.15, the latest release.