Answers

All the files are back. Why is ComfyUI still red, and when is a move actually finished?

Count two things separately: the files coming back, each one checked, and the app working on the new machine. A complete set of files with red nodes is not a finished move. It is finished when the same custom nodes load as on the old machine and your workflow produces output again.

Files back and app working are two different results

A move has two separate results, and only the second one means you can work. The first is that every file arrived intact: models, custom nodes, workflows. The second is that the app starts on the new machine, the same custom nodes load, and a workflow runs to output. The first can be complete while the second fails. Folding them into one "it worked" hides exactly the failures you will hit later.

Why ComfyUI can be red with every file in place

Because some of what a working setup needs is not in the files. Three things sit outside them:

• Python packages. They have to be installed for this machine. A copied virtual environment often breaks on a different machine.
• System libraries. For example libGL.so.1. They belong to the operating system, so a custom node can fail to import on a machine that lacks them. See Custom nodes missing or IMPORT FAILED.
• The machine itself. The GPU generation, the driver and the CPU's instruction sets. See Errors after changing GPU.

ComfyUI keeps starting when a custom node fails to load, so the app opening proves little. The cases we hit ourselves, every file verified and the environment still dead, are written up in Every file verified, environment still dead.

How to check a move yourself

1. Start ComfyUI and read the start-up log. No custom node should be marked (IMPORT FAILED). Compare the list of loaded packs with the old machine's.
2. Open a workflow you know worked, with no red nodes and no empty model dropdowns.
3. Queue it and wait for the output file. Loading the graph is not the test. Running it is.
4. For a fine-tuning setup, run a short training and check that it writes a trained file that isn't empty.

Don't expect the new image to match the old one pixel for pixel on a different GPU, even with the same seed. Why it can differ: Same GPU, two images.

What a Renest restore checks and reports

A Renest restore reports the two results separately, step by step, instead of only an exit code:

1. It checks the machine before downloading: GPU generation, driver, CPU, disk space, and the system libraries the working run loaded.
2. It downloads every file and checks each one against its checksum.
3. It installs the exact dependency versions the working run used, for this machine.
4. It starts ComfyUI and reads the start-up log. Any custom node that failed to load because a system library is missing is named, with the library, even though the app itself came up.
5. If the nest records a workflow that produced output, it runs that workflow once and reports whether output came out.

What the closing lines mean, and how to start the app afterwards: After the restore. A line saying the environment rebuilt but the machine isn't identical is a success; see If a restore stops.

What we promise is the first result: your files and dependencies come back, checked. Whether the app works on the new machine is something the restore tests and reports each time, not something we assume.

How we count our own restores

On the Proof page, a restore counts as working only when the restored machine loads the same set of custom nodes the original machine loaded, and the rerun produces output again. For fine-tuning, the output has to be a trained file that isn't empty. Files coming back and the app working are counted separately there, and failures are listed alongside the successes. The current numbers are on that page, not here.

When Renest isn't the answer

• You moved ComfyUI yourself and only need to know whether it's done. The checklist above works without Renest.
• The setup never worked on the old machine. There is nothing to compare against, and Renest only carries a setup that already worked; see When you don't need Renest.