Because pip install -r requirements.txt re-decides the versions each time
you run it, against whatever the package index holds that day. Users of both tools ask for
the same thing — "python requirements.txt doesn't install all the right versions …
please lock them down" — and the honest fix is to keep the list that worked, not the
file that produced it. A fresh
resolve is a different environment explains why.
Renest does that for a run that already finished: it records the versions that were actually installed when the training worked, and on the next machine installs exactly that list with uv, with no new resolution step.
Pack it right after a training run that finished. You describe that run in a small JSON
file — the working directory, the command line and the environment
({"cwd": …, "argv": [...], "env": {…}}) — and Renest reads
the recipe out of it: for kohya_ss the command line itself, for LLaMA-Factory the config file
the command names.
$ renest pack --dir ./run --framework kohya --run-record run.json --out ./nests --dest hosted $ renest pack --dir ./run --framework llamafactory --run-record run.json --out ./nests --dest hosted
What goes in: the training tool's folder, the config files the run read, the base model
it trained from, and the dependency lock. What stays out: the checkpoints and adapters the
run produced, and your dataset. They aren't dropped silently — each is recorded in the nest
as a spot that pointed at your own files. --dest hosted uploads the nest to your
drive as it packs, so it isn't left only on a machine you are about to destroy.
Capture a run has the details.
When the dependency list can't be installed elsewhere as recorded — a package installed from a folder the pack can't carry (a folder outside the environment is carried when it is under 100 MiB), packages from conda's base environment — the pack still finishes, names those packages and the fix, and marks the nest as not restorable on another machine. See why pip freeze isn't a backup.
Run the training once under renest watch before packing. A trainer exits when
it's done, so by packing time there's no process left to ask which system libraries it
loaded. watch records that while the run happens, inside the folder you will
pack, and changes nothing about the run — same arguments, same output, same exit code:
$ renest watch -- accelerate launch train_network.py --config config.toml
Without it, packing falls back to what the installed packages declare, which is wider than what the run used and can only ever warn.
In the web console, open the nest and choose Restore; the page gives you a command with a restore code. On the new machine:
$ uv tool install renest $ cd /workspace 2>/dev/null || cd ~ $ renest restore --grant grant.json --dir ./run
Before any file moves, the restore checks the machine against the one the nest was packed
on: a GPU generation the recorded build has no code for, a driver too old for its CUDA build,
or a CPU without avx2 stops it there. A missing git, C compiler, git-lfs or system library is offered for install first (it asks; --yes skips the question), or named with the command if it can't install it. It also asks whether the recorded package list can be
installed here, before the large downloads.
Then every file is checked against its recorded checksum, the packages are reinstalled
from the lock, and the training command runs once. Its output goes to
.renest/evidence/<run>/entrypoint.log inside the folder you restored to;
when the run fails, that log is the real diagnosis and the restore points you to it. A run
that dies on a missing system library such as libGL.so.1 is reported as that,
with the install command, not as a broken environment. More in
Restore a nest.
Your dataset is never packed into a nest, and a restore says so as soon as the files have landed: it lists each spot in the recipe that pointed at your own files — the training data it read, where results went — so you know what to put back. If the run then fails because the data isn't there (kohya prints a "no data found" kind of message), the restore says exactly that: put the data back where the recipe expects it and run the same restore command again. Files already checked are kept.
When the run produces the adapter it was packed to produce. An exit code alone isn't trusted: kohya can print an error and exit 0 when it finds no data, so when a nest names the expected adapter file, the restore requires that file to appear and fails if it doesn't.
Our own fine-tuning restores, failures included, are on the Proof page.
Related: Keep a setup between cloud sessions · What a backup has to include · The official base image