Concepts

Pinned, not latest.

For ComfyUI and every custom node that is a git checkout, a nest records the exact commit you packed, never "latest". It also carries each one's source code, and a restore unpacks that stored copy instead of fetching the repository again.

"Latest" breaks a working graph without an error

The custom node you installed in March and the thing called latest in that same repository today are not the same software. They have the same name and URL; that's all the word "latest" promises. The repository kept moving — defaults changed, a sampler got "fixed", a tensor layout was reordered — while your workflow stayed tuned against the March version, because that is the version it was built on.

The cruel part is how this fails. It usually doesn't error. Reinstall the node six months later, load the same workflow, and everything runs — the graph loads, the progress bar moves, an image comes out. It's just not the image. Colours drift, a composition falls apart, a face changes — and your first instinct is that you got a parameter wrong, because nothing on screen says otherwise. This is the quietest death a working graph has: no stack trace, no version warning, just output that stopped being yours.

The manifest records the exact commit, not the repository

So a nest doesn't record "this repository". For every custom node that is a git checkout, it records the commit that was checked out when you packed — the full forty characters, written into the manifest's code-dependency list next to the repository URL. Both are read from the node's own folder at capture time, never from a package name or a tag someone can move.

ComfyUI itself is treated the same way: the application is a code dependency like any other, pinned to the commit of the checkout that was running.

Not every node has git history. Nodes installed from the ComfyUI Registry usually don't. For those, Renest takes the origin from the node's own pyproject.toml. The capture report says plainly that there is no commit to record, and the node's files travel byte-for-byte instead.

The source travels inside the nest

A pinned commit alone quietly assumes the repository will still exist, and still contain that commit, whenever you rebuild. Custom nodes get deleted, transferred, force-pushed and taken private all the time. A pin into a repository that's gone is just a precise description of something you can no longer have.

So the nest carries each node's source code in full, as an archive stored alongside your models. A restore unpacks that archive into place. It doesn't clone the node from its repository, so your ability to rebuild your own work doesn't depend on someone else keeping their repository alive. The archive is fingerprinted like every other file in the nest and verified when it comes back.

Compiled files are left out only when the node can rebuild them

Some nodes compile native extensions (.so files) on install. A binary compiled against one machine's CUDA and CPU is exactly the kind of thing that should be rebuilt on the target, not copied to it. So packing leaves those files, and the node's build/ folder, out of the archive only when the node carries a way to rebuild them: a setup.py, a pyproject.toml with a build system, or a requirements.txt. Packing warns when it does this. The manifest also lists what was left out, so nobody mistakes a trimmed source tree for a complete one. The rebuild itself comes from the node's post-install command, and packing tells you when none is set.

A compiled file with no build recipe stays in the archive as-is. Removing something that can't be regenerated would give you a nest that passes every byte check and then fails the moment the node loads.

None of this asks you to think about versions. You already did the hard part: you got the graph working. Capture just refuses to let "working" mean "working until somebody else's repository moves."