Answers

What should a ComfyUI backup include — the whole folder, or a frozen requirements.txt?

Four things, and they behave differently: your workflows, model files that exist nowhere else (LoRAs you trained, files taken down from the hub), your custom nodes, and the Python environment those nodes depend on. ComfyUI's own requirements.txt doesn't list what custom nodes installed later, so it isn't a record of your environment. Public checkpoints can be downloaded again; keeping them trades disk for time.

What are the parts of a ComfyUI setup I'd actually lose?

• Workflows — in user/ (saved workflows live under user/default/workflows). Small, and the thing you made.
• Model files — in models/. Some can be downloaded again; some can't: LoRAs you trained, files that were taken down, versions the author replaced.
• Custom nodes — in custom_nodes/. Each one is a repository at some commit; "latest" today is not the version your workflow worked with (see Pinned, not latest).
• The Python environment — the exact versions of torch and every package your nodes pulled in. This is the part that usually breaks a move, and the part a copy of the folders doesn't fix.

Isn't a frozen requirements.txt enough?

ComfyUI's own requirements.txt lists what ComfyUI needs, not what your custom nodes installed afterwards, so it describes a fresh install, not yours. A pip freeze of your environment is closer, but it's an install list, and it can name packages that can't be installed anywhere else — see why pip freeze isn't a backup.

Can I just copy the whole ComfyUI folder?

For the same machine, often yes. For another machine, the folders come across but a virtual environment carries absolute paths and builds made for the machine that created it, and system libraries some nodes load (libGL.so.1 and the like) were never in the folder. That's why a setup on a network volume can still break on a new pod.

Do I have to back up the models too, or can I skip them?

Back up the ones that exist nowhere else. Public checkpoints can be downloaded again, as long as they stay up and the same version stays at that link; whether to keep a copy is a trade between storage and download time. A copy is the only thing that doesn't depend on someone else's server.

What does Renest keep from a ComfyUI setup?

A nest is packed from a workflow that already rendered. It keeps the workflow, the model files that workflow used, each custom node's source pinned to its commit, and the dependency lock with the exact versions installed — plus a record of the machine it ran on, so a later restore can say up front when a machine can't run it.

$ renest pack --dir ./run --workflow workflow-api.json --dry-run
$ renest pack --dir ./run --workflow workflow-api.json --out ./nests --dest hosted

The dry run prints what would be captured and writes nothing. Model files go in as files, so a restore doesn't depend on whether a model is still online. A file you have already stored is stored once, even across several nests — see Whole-file deduplication. Your other saved workflows aren't packed unless the run used them; export those yourself.

Restoring checks every file against its recorded checksum, reinstalls the locked versions, then starts ComfyUI and runs the packed workflow once. The nest's format is open, and restore.sh brings the files and dependencies back without Renest. More in Capture a run.

When Renest isn't the answer

• You only need your workflows — export the JSON, or copy user/default/workflows.
• You want models safe through ComfyUI updates on one machine — keep models outside the install and point at it with extra_model_paths.yaml.
• You're moving a Windows Portable install to another Windows PC — copy the Portable folder.

Related: Volume, image, snapshot or nest · Keep a setup between cloud sessions