Answers

Why do my ComfyUI custom nodes say IMPORT FAILED after a restart or a move?

A node folder being there doesn't mean the node loads. IMPORT FAILED means the node's code ran and something it needs was missing: a Python package, or a system library such as libGL.so.1 that lives on the machine, not in the folder. Installing the node again won't fix it; installing what the error names will.

"IMPORT FAILED": the folder is there, the node didn't load

IMPORT FAILED means ComfyUI found the node's folder, ran its code, and the code stopped with an error. A node that was never downloaded doesn't say this. It simply isn't listed. ComfyUI carries on starting without the node, so the app opens normally and the node only shows up red when a workflow uses it.

Three things have to be present for a custom node to load, and copying or cloning the folder brings back only the first:

• the node's folder in custom_nodes;
• the Python packages it installed, inside the Python that runs ComfyUI;
• the system libraries those packages load, which belong to the operating system.

Find the line in the start-up log that says why

The reason is in ComfyUI's start-up log, a few lines above the import timing list where the node is marked (IMPORT FAILED). Look for Cannot import … module for custom node and the traceback right after it. In ComfyUI-Manager you can also filter the custom node list by Import Failed. The last line of the traceback falls into one of two kinds:

• ModuleNotFoundError: No module named '…': a Python package is missing.
• …: cannot open shared object file: No such file or directory, for example ImportError: libGL.so.1: cannot open shared object file: a system library is missing.

Any other error is usually a bug in the node itself, or a version clash with another node. Check the node's issue tracker with the exact line.

"No module named …": install the package into ComfyUI's own Python

Install the node's requirements with the Python that starts ComfyUI, not whichever pip is first on your path. On Linux with a virtual environment:

$ /path/to/venv/bin/python -m pip install -r custom_nodes/<node>/requirements.txt

On Windows Portable, from the ComfyUI_windows_portable folder:

$ python_embeded\python.exe -s -m pip install -r ComfyUI\custom_nodes\<node>\requirements.txt

Then restart ComfyUI. If the package installs and the node still fails, read the new last line. One fix often reveals the next missing piece.

"libGL.so.1" or "libMagickWand": install the system library, not the node

A missing .so file is part of the operating system, so reinstalling the node or its Python packages won't bring it back. Slim container images used on cloud GPUs often leave these out. Install the package that provides it. On Debian or Ubuntu images:

$ apt-get update && apt-get install -y libgl1
$ apt-get install -y libmagickwand-dev

libgl1 provides libGL.so.1, which OpenCV loads. On older Ubuntu releases the package is called libgl1-mesa-glx. ImageMagick-based nodes need libMagickWand. If OpenCV is the only thing asking for libGL, replacing opencv-python with opencv-python-headless also works, but other nodes may install the full version again.

Nodes are red again after every pod restart

On RunPod and similar services, anything outside the persistent volume is reset when the pod stops. The volume is usually mounted at /workspace. That reset takes with it every system library you installed with apt-get, and any Python packages that were installed outside the volume. The node folders survive on the volume, so the next start shows the folders and fails to import them. That is why ComfyUI-Manager asks you to install the same nodes again after each restart.

Ways to make it stick:

• Use a container image that already contains the system libraries your nodes need. Whatever is in the image is there again after every stop.
• Keep ComfyUI's Python environment on the volume, so its packages survive too. It still breaks if the next pod uses a different image or GPU generation.
• Or reinstall the missing pieces from a start-up script each time the pod starts. Some people keep the library files on the volume and link them back in at start-up; that works, but it breaks quietly when the image changes.

Why a volume keeps the files and still loses the working setup is covered in Network volume, new pod, still broken.

ComfyUI-Manager says the node is installed, and it's still red

ComfyUI-Manager can show a node as installed because its folder is there. That says nothing about whether it imports. Check the start-up log as above. If it shows IMPORT FAILED, the fix is the missing package or library, and pressing Install again won't change it. Two other causes:

• The packages went into a different Python, for example a system Python or another conda environment, so ComfyUI never sees them.
• The node loads, but the workflow asks for a node type the installed version no longer has. That is a version problem, covered in Red nodes and empty model lists.

What Renest does about missing packages and libraries

A nest is packed from a run where the nodes loaded, and it handles each of the three layers in the only way that layer can travel:

• Node folders: carried as files, at the commit that ran (why pinned, not latest). Every file is checked against its checksum when it comes back.
• Python packages: the exact versions that resolved, installed again for the new machine. Before the model files download, the restore asks whether that list can be installed on this machine. If the answer is a clear no, it stops there.
• System libraries: no nest can carry them, since they belong to the operating system. The nest records which ones the working run actually loaded. Before the download, the restore names any that this machine lacks, with the command to install them. It warns rather than refuses.

After it starts ComfyUI, the restore reads the start-up log. It names any custom node that failed to import because a system library is missing, even though the app itself came up. Fixes for those messages are in If a restore stops. The Renest base image already includes the system libraries image and fine-tuning workflows commonly load.

What it doesn't do: a node that fails on a plain Python error, a bug in the node itself, is not flagged as a missing library, because it isn't one. And a restore doesn't run again by itself each time a pod restarts.

When Renest isn't the answer

• The node never loaded on any machine. Renest only carries a setup that already worked. Fix the first install using the steps above.
• You restart the same pod with the same image and only need a few libraries back. A custom image or a start-up script is simpler.
• The error is in the node's own code. Report it to the node's author.

Related: Errors after changing GPU · When is a moved setup actually working?