Why Your ComfyUI Custom Nodes Reinstall Every Session (and How to Make It Stop)

Why Your ComfyUI Custom Nodes Reinstall Every Session (and How to Make It Stop)

Open ComfyUI-Manager and there is a button labeled Snapshot. Search GitHub and you will find repos whose entire job is to reinstall a node set with one command. Look at RunComfy's paid tier and the thing you are actually buying is permanent storage so your setup does not reset. Three different groups of people built three different patches for the same wound: on a fresh cloud GPU, your ComfyUI custom nodes reinstall every session, and you pay for it in time on every single boot. I work on the snapshot layer that sits under this, not the workflows on top of it, so I spent a week reading ComfyUI GitHub issues, the Comfy support forum, and provider docs. The same complaint keeps surfacing. You rent a box, re-clone twenty custom node repos, wait for each one to resolve its own dependencies, fix the two that broke, and start working. Kill the box and it is gone. Tomorrow you do it again.

TL;DR: A cloud GPU wipes the ephemeral disk your custom_nodes folder lives on, and each node is a git clone plus its own pip install, so a fresh box rebuilds them from zero. ComfyUI-Manager's snapshot saves a list of repo URLs and commit hashes, not the installed files, so a restore re-clones and re-resolves everything and can break when a dependency no longer lines up. The only thing that brings working nodes back in one step is a snapshot of the whole box at its real paths.

Why do your ComfyUI custom nodes reinstall every session?

Because custom_nodes lives on the container disk, which most GPU marketplaces wipe the moment a pod is terminated, and every custom node is a git repository plus its own Python dependencies. A fresh box starts with an empty folder, so ComfyUI has nothing to load until you re-clone each repo and reinstall each node's packages.

That is the mechanical reason the folder keeps coming back empty. The base ComfyUI install is small and quick. The weight is in the extensions you bolted on: a ControlNet pack, a video node set, an upscaler, a handful of utility nodes, each one a separate repo with its own requirements.txt. None of that is part of the image you booted, so none of it survives the box. The ComfyUI-Manager feature request that first asked for bulk install said the quiet part out loud: reinstalling the setup "is a common thing for people working on cloud hosted GPU's like RunPod."

One reinstall is really a chain of them

Re-cloning the repos is the fast part. The slow, fragile part is that each node pack then resolves and installs its own dependency tree, and those trees do not always agree with each other. The ComfyUI core team has written about this directly:

"Every custom node pack has its own set of dependencies. Unfortunately, sometimes these dependencies conflict which can 'brick' a ComfyUI installation when you install the wrong custom nodes together." Jedrzej Kosinski and Jacob Segal, ComfyUI blog

They also noted that installing every node's requirements in bulk "often resulted in failure with high probability, even with only about 100 custom nodes," which is why ComfyUI-Manager moved to installing packages one at a time. A recent core issue shows what that failure looks like in practice: thirty-plus custom nodes going down at once on a fresh Python 3.12 install because transformers, tensorflow, and protobuf could not agree on a version. So the cost of a cold start is not one download. It is N clones, N dependency resolutions, and the two or three conflicts you have to untangle by hand before the graph will run. Here is how one renter described the recovery on a fresh box:

"The only thing that fixes it currently is manually going one by one through every custom node in comfyui manager and uninstalling and reinstalling them." RunPod user, ComfyUI support forum

What ComfyUI-Manager's snapshot actually saves about your custom nodes

A snapshot feels like the answer, so it is worth being precise about what it holds. A ComfyUI-Manager snapshot records the ComfyUI commit hash, each custom node's git commit or registry version, and a pip freeze of the environment. That is a manifest. It is a list of what you had, not a copy of what you installed. The snapshot documentation is explicit that only git-cloned and registry nodes can be reliably restored, while nodes you dropped in as loose files are "recorded but cannot guarantee exact restoration."

The gap shows up on restore. Because a snapshot is a manifest, restoring it re-clones every repo and re-runs the install, which means you pay the same dependency-resolution tax again and inherit any breakage that has landed upstream since. Worse, the pip side of the snapshot is not fully wired: a Manager issue from July 2025 reports that the pips list a snapshot records is not applied on restore, and the maintainer confirmed "the feature was disabled during one of the past updates." So if a node forgot to declare a dependency in its requirements.txt, the snapshot knew about it from pip freeze but the restore quietly leaves it out. A snapshot is a recipe. It is not the cooked meal, and re-cooking it on a fresh box can still burn.

Why does a node that worked last week break on a fresh install?

Because a workflow only runs if the environment around it stays compatible, and custom nodes drift. If a node is not pinned, a fresh clone pulls the latest commit, and the latest commit may have changed an input name, a dependency, or a behavior your graph relied on.

This is the version-drift trap, and it is nastier on cloud than on a machine you keep. On your own box, an environment that works tends to stay put because you are not rebuilding it. On a rented box you rebuild constantly, so every rebuild is a fresh roll of the dice against whatever changed upstream. As one explainer on why ComfyUI updates break workflows put it, "the real asset is the workflow plus the exact ComfyUI version, the exact custom node versions, and the Python environment that made it work" (popularai.org). Pinning commits in a snapshot manifest gets you the first half of that. It does not get you the resolved, installed Python environment, which is the half that actually takes the time.

Even a network volume does not fully fix it

The obvious move is to put custom_nodes on a persistent network volume so it survives the teardown. That helps with the files, but it does not end the reinstall. A RunPod worker maintainer hit exactly this wall:

"when we do use the custom nodes with a network volume, that they still need to install their dependencies per request. Which is something that is increasing the cold start time. And we can't just add the custom nodes path to the yaml, because if the path doesn't exist, then ComfyUI will not start." worker-comfyui issue #37

The node repos are on the volume, but their installed packages live in the Python environment on the box, which the volume does not hold. So the deps still reinstall on every boot. On top of that, a network volume keeps billing while the GPU is off, usually around $0.10/GB per month, and it is pinned to one datacenter region, so it cannot follow you to a cheaper box on another provider. You have persisted the folder. You have not persisted the working install, and you have chained yourself to one region to get even that.

Where each approach leaves you

The pattern is clear once it is in a table. Each row up captures a little more of your setup, and the reinstall only truly ends at the row that stores the installed state itself, not a description of it.

What you should actually do

Pin your nodes with a Manager snapshot regardless, because a pinned commit is the difference between a rebuild that mostly works and one that surprises you. But treat the snapshot as a manifest, and know that restoring it still costs you the clone and the dependency resolution every time. If your node set is stable, bake it into a custom image so the slow layers are already installed on first boot, and re-bake when you change it.

The deeper fix is to stop rebuilding the custom_nodes install at all. What you want back after a teardown is not a list of repos to reinstall. It is the folder as it was, with every node already cloned at its pinned commit and every dependency already resolved and importable, sitting at the same paths ComfyUI expects. That means capturing the whole box, not a description of it.

This is the exact gap we are building ogre to close, in the open. It is an open-source tool that snapshots a full GPU box, the custom_nodes folder with its resolved dependencies included, and restores it on whatever provider you rent next. We are proving the cross-provider restore in public rather than asking you to take the claim on faith, because a snapshot of a full ComfyUI box only means something if you can watch it come back with every node already imported. If you rebuild the same custom node set every week, that is the loop we are trying to end.

About the author

I am Ansh, and I work on the infrastructure layer at Aquanode, the plumbing under the models rather than the models themselves. I have spent the last stretch deep in how CLI-native GPU renters actually work, reading the ComfyUI issues and the provider support forums where the reinstall tax gets complained about, and building the snapshot layer that would make it go away. I would rather version-control a GPU box than rebuild one by hand.

Sources

• Jedrzej Kosinski and Jacob Segal, "Dependency Resolution and Custom Node Standards". ComfyUI blog
• "Snapshot Management", ComfyUI-Manager. DeepWiki
• "pip packages encoded in snapshot.json are not installed when restoring the snapshot", ComfyUI-Manager issue #2008. GitHub
• "Installing multiple custom nodes", ComfyUI-Manager issue #311. GitHub
• "Massive Node Failures on Python 3.12 (Protobuf vs TensorFlow vs Transformers)", ComfyUI issue #12198. GitHub
• "Custom nodes from the network storage pod aren't found", worker-comfyui issue #37. GitHub
• "Why ComfyUI updates break workflows and how to fix them". popularai.org
• "ComfyUI custom nodes (IMPORT FAILED) after server stop", RunPod. ComfyUI support forum via AnswerOverflow