Reference

Nest this run.

The Renest panel is a ComfyUI sidebar tab that packs the workflow on your canvas into a nest on this machine's disk. It previews what will go in, then packs and checks every file. It talks only to a local renest serve process on 127.0.0.1:7799, using a token kept in a 0600 file on the same machine, and it uploads nothing.

The panel is a thin front end; the renest engine does the packing

The panel adds a Renest tab to the ComfyUI sidebar. It has two halves: a small piece of Python that runs inside ComfyUI, and browser code that draws the tab. Neither half packs anything itself. Packing is done by the renest command-line tool, running as a local service (renest serve) on the same machine. The panel reaches it over plain HTTP on the loopback address, and that HTTP interface is the only connection between the two.

The panel follows ComfyUI's licence (GPL-3.0-or-later). The engine is a separate program that is source-available, not open source. The process boundary between them is also the licence boundary.

You install two things: the panel inside ComfyUI, and the engine once per machine

The panel. In ComfyUI-Manager, search for "Renest", install it and restart ComfyUI. Or clone it by hand:

$ cd ComfyUI/custom_nodes
$ git clone https://github.com/renest-ai/comfyui-renest

It needs a ComfyUI frontend that has the sidebar extension API. It adds no nodes to the node list, and it has no Python dependencies of its own.

The engine. In any terminal on the same machine:

$ uv tool install --upgrade renest
$ export PATH="$HOME/.local/bin:$PATH"
$ renest serve

Install it with uv rather than pip inside ComfyUI's own environment: pip install renest would add packages to the very environment you are about to capture. The engine needs Python 3.11 or newer, but that Python does not have to be the one running ComfyUI. On the Windows portable build, use a normal Python install, not the embedded one. No uv yet? See the quick start.

renest serve listens on 127.0.0.1:7799 by default. --port (or RENEST_SERVE_PORT) changes the port, but the panel always connects to 7799, so leave it at the default when you use the panel.

If the engine is not running, the tab says so and shows these two commands with a Copy button and a Check again button. Nothing else needs configuring.

On a rented machine, open ComfyUI through an SSH tunnel so the panel can reach the engine

The panel's browser code connects to http://127.0.0.1:7799. That address is resolved by your browser, which means it points at the computer the browser runs on, not at the pod. The engine also accepts browser requests only from loopback pages (127.0.0.1 or localhost). So if you open ComfyUI through a provider's web address, the tab can't reach the engine and says it isn't running, even when it is.

Forward both ports over SSH, then open ComfyUI locally. Start from the SSH command your provider shows for the machine and add the two -L options:

$ ssh -N -L 8188:127.0.0.1:8188 -L 7799:127.0.0.1:7799 <user>@<machine-address> -p <ssh-port>
# then browse to http://127.0.0.1:8188/

If you can't tunnel, pack from the pod's terminal instead. renest pack does the same capture without the panel (see the RunPod and vast.ai guides).

The button previews first, then packs, then checks every file

When a run finishes successfully, the panel shows a notice telling you to nest it from the Renest tab. Pressing Nest this run works through these steps:

1. Reads the canvas. The panel turns the workflow currently on the canvas into ComfyUI's API format. An empty canvas stops here, with a note saying there is nothing to nest yet.
2. Asks for a preview. It sends that workflow to the engine together with three facts only code inside ComfyUI can know: the data folder, the folder ComfyUI's own program lives in, and the Python interpreter running it. The engine does a dry run and writes nothing.
3. Shows "What goes in the nest". This lists counts and sizes for Models, ComfyUI itself, Custom nodes and Dependency locks, followed by an Estimated size and Saved on this machine to with the exact folder. Anything the engine could not capture appears under Worth reading before you save. One example is a custom node dropped in as a plain unzip, with no origin to record. Read that box: a list that looks complete but isn't is the one that costs you later.
4. Packs when you confirm. Give it a name (the default is the folder name and today's date) and press Confirm & nest. The engine queues a job. The panel checks on it once a second and shows the stage, a progress bar and plain-language log lines. Cancel stops the job.
5. Finishes on "Nested & verified". That line appears only after the engine has written the nest and checked every file against its recorded checksum. The folder path is shown under it. If packing fails, the panel shows Packing failed and the engine's own explanation.

Packing from the panel always records a direct download address for packages that are pinned to a vendor-only build (such as a CUDA-specific torch). A machine that just ran a workflow has network access, and a nest sealed from the panel should never be one that can't be put back elsewhere.

The panel keeps a small run record so packing can use facts from the live run

Some facts about a run exist only while ComfyUI is running. So the panel's Python half watches the status messages ComfyUI already sends to the browser. It changes nothing about them. Whenever a prompt ends (finished, failed or interrupted), it writes one file beside ComfyUI's program folder:

<ComfyUI program folder>/.renest/native-libs.json

It records:

• Which node pack each loaded node type came from, as ComfyUI itself reports it. Without this, packing would have to search custom node folders for class names as text, which misses packs that build node names at start-up.
• The most video memory the run was seen using, sampled at most every couple of seconds while a prompt runs, along with the sampling interval. This is kept only when the run finished successfully. A run that stopped on its first node would otherwise leave a figure far below what the workflow really needs.
• When the record was written, and which Python wrote it.

The engine reads this file when it packs, both for the preview and for the real pack. The node owners decide which custom nodes go in. The video memory figure goes into the nest, where the pre-flight check on another machine can compare it against that machine's card. A nest with no figure says nobody measured, and the check reports exactly that instead of passing.

The operating-system libraries a run loaded are read by the engine from the running ComfyUI process, not from this file. If ComfyUI is already closed when you pack, the engine can only use what the installed packages declare. Packing tells you so, and the fix is to start ComfyUI and pack again.

The nest is written beside your ComfyUI folder, in renest-nests

<the folder holding your ComfyUI>/renest-nests/
├─ nests/<nest-id>/manifest.json
└─ blobs/…

That folder sits next to your ComfyUI install, so it is on whichever disk you already chose for it and your models. On a rented machine, check which of its disks keep their contents when you stop it before you rely on the nest staying there. Two cases land elsewhere, in your per-user data folder (on Linux, normally ~/.local/share/renest):

• ComfyUI sits at the root of the filesystem (such as /ComfyUI): the nest goes to renest-nests inside that data folder, ~/.local/share/renest/renest-nests on Linux.
• The chosen folder isn't writable: the nest goes to nests inside that data folder, ~/.local/share/renest/nests on Linux.

The preview shows the real path either way.

The panel never uploads. To put the nest back on another machine, bring the folder along and run renest restore --manifest <folder>/nests/<nest-id>/manifest.json --dir ./run. To keep a copy on your Renest drive, pack from the terminal with --dest hosted (see the platform guides).

A local token, stored in a 0600 file, is the only secret between the panel and the engine

Every engine endpoint except its health check needs a token. This is how that token moves:

1. The engine creates it. The first time renest serve starts, it generates a random token and writes it with owner-only permissions (0600):
   • Linux: ~/.config/renest/serve.token
   • macOS: ~/Library/Application Support/renest/serve.token
   • Windows: AppData\Local\renest\renest\serve.token under your home folder
   If you choose another location with --token-file or RENEST_TOKEN_FILE, the engine also writes that location into a file named token-path (0600), next to where the default token file would be. The panel looks for token-path only in ~/.config/renest/, so for now a custom location is found automatically on Linux only. On macOS and Windows, keep the token in its default place. A fix is under review.
2. The panel's Python half reads the file each time the browser asks for the token, and returns it from ComfyUI's own server at /renest/token.
3. The browser code keeps it in a variable. It is never written to localStorage, sessionStorage or a cookie. It is sent only as an Authorization header to 127.0.0.1:7799, and it is gone when the page reloads.
4. The engine re-reads the file on every request. To replace the token, delete the file, restart renest serve, and reload the ComfyUI page.

Know the limits of this token. Anyone who can open your ComfyUI page can ask for it, because it is served there. It is only useful from the machine itself: the engine listens on 127.0.0.1 and refuses to start on any other address. It lets the holder start pack and restore jobs on this machine. It is not your Renest account key, and it can't read your drive.

No cloud credentials and no uploads pass through the panel

• No bucket keys or account tokens. If you configure the engine to upload, the credentials stay the engine's business, read from its own config or environment. The panel never sees, stores or forwards them. Those credentials have their own home, a 0600 config file for the command-line tool, which the platform guides cover.
• No uploads. A nest from the panel is written to your own disk and nowhere else.
• No imports of engine code. The panel talks to the engine over HTTP only.