# My network volume has my custom nodes and models. Why does ComfyUI still break on a new pod?

> Because a volume keeps files, not a working environment. A custom node needs three things to load: its folder, the Python packages it installed, and the system libraries those packages link against. The folder survives on the volume; a virtual environment built on one machine often fails on the next, and system libraries live in the container image, not on the volume.

Canonical page: https://renest.ai/answers-network-volume-breaks-on-new-pod.html

<h2 id="red">Whenever I start a new pod and attach my volume, custom nodes throw red errors. Why?</h2>

<p>Because one of the three things a node needs is missing on the new pod, even though its
folder is right there on the volume:</p>

<ul>
<li><strong>The node's folder</strong> in <code>custom_nodes</code>. This one is on the
volume, so it survives.</li>
<li><strong>The Python packages it installed.</strong> If they went into the system Python
on the container disk, they were erased with the old pod. If they are in a virtual
environment on the volume, they may not work on the new pod (see <a href="#venv">below</a>).</li>
<li><strong>The system libraries those packages load</strong>, such as
<code>libGL.so.1</code>. These come from the container image. A volume never holds them.</li>
</ul>

<p>A red node in the graph is ComfyUI saying the node's class isn't registered, and the
reason is in the startup log, not in the graph.</p>

<h2 id="import-failed">ComfyUI custom nodes say IMPORT FAILED after a server stop. What's missing?</h2>

<p>Read the lines right after <code>IMPORT FAILED</code> (or <code>Cannot import … module
for custom node</code>) in ComfyUI's startup log. They name the cause:</p>

<ul>
<li><code>ModuleNotFoundError: No module named …</code> means a Python package is missing.
Install the node's requirements into the Python that runs ComfyUI.</li>
<li><code>… cannot open shared object file</code> means a system library is missing. Installing
the node again won't fix it; install the library with the system package manager (for
example <code>apt-get install</code>), or use an image that already has it.</li>
</ul>

<p>The <a href="answers-nodes-missing-after-move.html">nodes missing or import failed</a>
page goes through the common cases.</p>

<h2 id="venv">Should I just keep the venv on /workspace?</h2>

<p>It helps when the next pod is close to the last one: same image, same Python, a similar
GPU. A virtual environment is built for one machine. It points at the Python it was created
with, by path, and the PyTorch inside it was built for a particular CUDA version and range
of GPU generations. Attach the same volume to a pod with a different image or a newer GPU and
that environment can fail to start, or start and then fail with errors such as
<code>no kernel image is available for execution on the device</code>; see
<a href="answers-errors-after-gpu-change.html">errors after changing GPU</a>. It also does
nothing for system libraries.</p>

<h2 id="pip">Why do I have to pip install the same things again on every new pod?</h2>

<p>Because the packages lived on a disk that didn't come with you. Reinstalling from each
node's <code>requirements.txt</code> works, but it installs whatever versions are newest
today, which may not be the versions your workflow last worked with. To get the same
environment back, you need the exact versions that worked, written down when they worked;
<a href="answers-pip-freeze-is-not-a-backup.html">why pip freeze isn't a backup</a> covers
where a plain freeze falls short.</p>

<h2 id="nest">What does a nest bring back that the volume doesn't?</h2>

<p>A nest is packed from a run that worked. It records:</p>

<ul>
<li>the files: model weights, the custom nodes' source pinned to their commits, the
workflow, each with a recorded checksum;</li>
<li>the exact Python package versions that run used, as a lock that can be installed again
on another machine;</li>
<li>which system libraries the run actually loaded.</li>
</ul>

<p>On restore, the packages are installed again from that lock for the new machine, instead
of copying an environment built for the old one. Before the big download starts, the restore
names any of the recorded system libraries this machine lacks, with the command to install
them. That is a warning; the restore carries on. After it starts ComfyUI, it reads the log
and names any custom node that failed to load because a system library is missing.</p>

<p>The same check refuses a machine before the download when the GPU generation is one the
nest's PyTorch build has no code for, when the driver is too old for the nest's CUDA build,
or when the CPU lacks avx2. Renest does not swap in a different PyTorch for a new GPU: to run
on a newer generation, get the setup working there once and pack again.</p>

<h2 id="steps">How do I move a volume setup into a nest?</h2>

<p>On a pod where the workflow still produces images, install the tool and an access key
(see the <a href="docs-guide-runpod.html">RunPod guide</a>), export the workflow in API
format, and pack:</p>

<pre>$ renest pack --dir /workspace --workflow workflow-api.json &#92;
    --out /workspace/nests --dest hosted</pre>

<p>On the next pod, open the nest in the web console, choose <strong>Restore</strong>, and
paste the command it gives you. It writes the restore code to <code>grant.json</code>:</p>

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

<p>The restore downloads every file and checks it, installs the locked packages, starts
ComfyUI and runs the workflow once, then reports which steps passed. Files coming back
checked and ComfyUI working are counted separately; see the <a href="proof.html">Proof
page</a> for our own results. Why the two differ is told in
<a href="verified-files-not-a-working-environment.html">Every file verified, environment
still dead</a>. If a step stops, see <a href="docs-troubleshooting.html#libs">Troubleshooting</a>.</p>

<h2 id="not-renest">When Renest isn't the answer</h2>

<p>If every new pod uses the same image and the same GPU type, and the venv on your volume
keeps working, you don't need to change anything. If only one or two system libraries are
missing, adding them to your own image or to the pod's start command is the smaller fix.
If you need a fixed environment for serverless or production deployment, build a Docker
image. See <a href="answers-volume-image-snapshot-compared.html">volume, image, snapshot or
nest</a> for what each one keeps.</p>