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.
$ 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.
$ 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.
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.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.
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.
--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.