Guides

Capture a run.

renest pack captures a run that already worked: the model weights and adapters it used, each custom node's source pinned to its commit, the dependency lock, and the workflow or training config that produced the result, written as a nest to your disk and, if you ask, to your drive.

Pack after it works, not before

Renest captures a result you already have. Get the workflow rendering or the training run finishing first; then pack it. There is no mode where Renest helps you get an unfamiliar setup running — that's a different product. What Renest keeps is the files and dependencies of a run that worked, checked; it can't do that for a run that never worked.

Before packing anything, look at the plan:

$ renest pack --dir ./run --workflow workflow-api.json --dry-run

That prints what would be captured and writes nothing.

Image workflows (ComfyUI)

$ renest pack --dir ./run --workflow workflow-api.json --out ./nests

--dir is the environment root — the folder that holds ComfyUI/ — and --out is where the nest is written; a real pack needs both. --workflow is the workflow exported in API format — in ComfyUI, Export (API); the ordinary saved workflow is refused with a note saying so. Renest reads it to work out which models and nodes the run actually touched, instead of hoovering up the whole disk.

If ComfyUI lives somewhere unusual, point at it with --comfyui-dir. The ComfyUI desktop app keeps its own program files apart from your nodes and models; point --program-dir at the program folder and --dir at the one with your nodes and models. The nest that comes out is an ordinary ComfyUI install either way.

No workflow to name? --auto packs the folder as it stands. It looks for a picture ComfyUI already produced in its output folder (the recipe travels inside the picture) and uses it to check the file list. If it finds none, it still packs, and the nest records that nobody saw this environment produce anything — a restore of it has no finished run to repeat.

The ComfyUI panel does the same packing from a button in ComfyUI's sidebar.

Fine-tuning runs (kohya_ss and LLaMA-Factory)

$ renest pack --dir ./run --framework kohya --run-record run.json --out ./nests
$ renest pack --dir ./run --framework llamafactory --run-record run.json --out ./nests

--run-record is a small JSON file describing the training run that worked — {"cwd": …, "argv": [...], "env": {…}}: the working directory, the command line, the environment. Renest reads the recipe out of it: for kohya_ss that is the command line itself, for LLaMA-Factory the config file the command names. Without it, --framework stops and says so.

Run the training command through renest watch while it trains, and the nest also records which machine libraries the run really loaded. A trainer exits when it is done, so by packing time there is nothing left to ask; watch records it while the run is happening, inside the folder you will pack (--env-root, default the current one). It changes nothing about the run — same arguments, same output, same exit code:

$ renest watch -- accelerate launch train_network.py --config config.toml

Two named frameworks, on purpose: kohya_ss and LLaMA-Factory. Both state their settings somewhere Renest can read them back, which is what makes a capture a recipe rather than a backup. An arbitrary training script states them nowhere — there'd be nothing to capture except "copy these bytes", so it isn't offered.

The output of a fine-tuning run is the input to an image workflow: the adapter kohya trains is the one ComfyUI loads. They're two ends of one chain, not two products.

What ends up inside

• Weights and adapters the run referenced, each stored under the checksum of its bytes, so the same file is kept once.
• Custom nodes, archived in full and pinned to the commit that was there — not "latest", which is what quietly breaks a restore two weeks later. The source travels with the nest, so a restore doesn't depend on that repository still existing.
• The Python dependency lock, so packages are reinstalled at the versions that worked. Packages pinned to a vendor-only version (like torch==…+cu124) also get their direct wheel links recorded, by default — unless you pack with --offline, which needs no network but leaves the nest marked as not restorable on another machine.
• The workflow or training config that produced the result.
• A fingerprint of the machine — GPU model, architecture, driver — so a later restore can warn you when the target hardware can't run what was compiled here.

When the dependency list can't be installed on another machine as recorded — packages that belong to conda or the operating system rather than a package index, or ones installed from a folder with pip install -e . — the pack still finishes, because the files are still a faithful record of this machine, but it says so, names the packages and the fix, and marks the nest as not restorable elsewhere. Handing such a nest off to someone else can be refused for the same reason. Restoring it yourself is not refused up front: the restore's own check, before any model files move, finds out whether the list installs on that machine.

If something in your code folder looks like a credential, the pack stops: a nest carries your code folder as it is, to anyone you hand it to. Remove it, or pack with --i-know if you are sure it is not a real one.

Say which files are your own with --mine

Files you did not make are treated as restricted by default, and restricted files never travel to someone you hand the nest off to — they fetch those themselves, under their own terms. That is right for downloaded models and wrong for your own work. Declare a LoRA you trained, or your own images, by its path inside the environment; repeat the flag for more:

$ renest pack --dir ./run --workflow workflow-api.json --out ./nests \
    --mine ComfyUI/models/loras/my-style.safetensors

A licence lookup that recognises the file still wins, so --mine can't loosen a real restricted model. It only matters for hand-offs; restoring your own nest from your drive is not affected.

Where it goes: your disk, and your drive if you ask

--out says where the nest is written on this machine. --dest hosted also uploads it to your Renest drive as it packs, so it isn't left only on the machine you're about to destroy. That needs an access key (see Signing in to your drive), and the key is checked before packing starts.

Pack the same folder again and the new pack becomes a new version of the same nest. --new-nest starts a separate nest instead, and --nest-id adds the new version to a nest you name. --nest-name gives a new nest a name.

If you keep nests in a bucket of your own rather than on the drive, --dest s3 uploads there instead; renest doctor --storage shows how to set the bucket up.

What it won't do

• It won't judge compatibility between nodes. If two nodes fought on your machine, they'll fight on the restored one — faithfully.
• It won't recommend or curate models. It captures what you used.
• It won't claim a run it never saw. A nest packed without any record of a finished run says so in its manifest, instead of looking like one that was.
• It won't take your storage key to a rented machine. The machine you restore on gets a restore code instead.