It works on its own — no account, no card, and it never asks a server of ours for permission to run. Its source is published in full and you may read, audit, modify and redistribute it; the one thing the licence withholds is using it to run a commercial service competing with the Renest hosted service (see licensing), so it is source-available rather than open source. The format specification and the escape-hatch script are the genuinely open (Apache-2.0) parts.
# no account needed $ uv tool install --upgrade renest # put it on this shell's PATH $ export PATH="$HOME/.local/bin:$PATH"
The second line is not optional on a fresh machine. uv puts
renest in ~/.local/bin, and on a box you just rented that
directory is not on your PATH yet — so typing renest answers
command not found and nothing tells you why. Opening a new shell also picks it
up. To keep it after a reboot, add the same line to your ~/.bashrc.
--upgrade is there on purpose: if you have installed renest
before, plain uv tool install renest leaves the old version in place and says
nothing, so it looks upgraded but is not. --upgrade moves it to the latest and
does nothing on a fresh machine.
It needs Python 3.11 or newer. Everything it rebuilds is pinned with
uv, which comes with it as a dependency. No
uv yet? curl -LsSf https://astral.sh/uv/install.sh | sh puts one
there first. On a proxy network, export HTTPS_PROXY=http://host:port (and
ALL_PROXY) first — uv and curl use only that, not the
OS proxy, or the install hangs with no error.
On its own, doctor gives the machine you're standing on a general check-up
— CPU features, memory, free disk, whether the GPU can actually be used — and says plainly
that it has nothing to compare against yet. The download speed test is skipped unless you
add --no-skip-net.
$ renest doctor
Point it at a nest's manifest and it answers the question that matters — can this machine take this particular setup? — checking the driver and GPU against what the nest needs. That check is what stops you renting a card the setup can't run on:
$ renest doctor ./nests/nests/<nest-id>/manifest.json
You don't have to run it before a restore: renest restore runs the same
check first on its own.
Get the run working first. Renest only captures setups that already
produced a result — it does not help you get an unfamiliar setup running. Once your image
workflow renders or your fine-tuning run finishes, pack it. --dest hosted
uploads it to your Renest drive as it packs; that needs an access key, which you create in
the web console under Settings → Access and give to the tool as
RENEST_TOKEN or in its config file (see
Signing in to your drive).
# image workflow (ComfyUI) $ renest pack --dir ./run --workflow workflow-api.json --out ./nests --dest hosted # fine-tuning (kohya_ss or LLaMA-Factory) $ renest pack --dir ./run --framework kohya --run-record run.json --out ./nests --dest hosted
--dir is the folder holding your environment (the one with
ComfyUI/ inside it) and --out is where the nest is written on this
machine: its manifest lands at ./nests/nests/<nest-id>/manifest.json, and
the files beside it under ./nests/blobs/. --workflow must be the
workflow exported in API format — in ComfyUI that's Export (API);
the ordinary saved workflow is refused with a note saying so. For a fine-tuning run,
--run-record is the JSON record of the run that worked (cwd,
argv, env) — the recipe is read from there, so what gets packed is
what you actually ran. A finished pack prints one line starting
Sealed ✓ nest <nest-id>, with the file count, size, whether a dependency
lock was captured, and any warnings.
What comes out is a nest: a manifest listing every file with a fingerprint of
its bytes, plus the model weights, the custom-node source archived in full and pinned to
its commit, the dependency lock, and the workflow or training config that produced the
result. Not sure what it will pick up? --dry-run prints the plan and writes
nothing.
Prefer a button? The ComfyUI panel packs the workflow on your canvas to this machine's disk. It never uploads; to put that nest on your drive, use Upload a nest in the web console and pick the folder it wrote.
In the web console, open the nest and choose Restore. Pick how long the restore code should last — 1 day, 3 days or 7 days — and copy the command the page gives you. The code works on any machine until it expires, so if a rented box breaks you can paste it on the next one. You can revoke it from the console at any time. Treat it like a password while it is valid.
On a fresh box — a different GPU, a different cloud, a month later. Renting one? The
RunPod and vast.ai
guides cover starting the machine. Install the tool there (step 1), then paste the command
from step 4. It writes the code to grant.json and runs the restore:
$ cat > grant.json <<'RENEST_GRANT'
{ …your restore code… }
RENEST_GRANT
$ renest restore --grant grant.json --dir ./run
The restore checks the machine first, downloads every file and checks it against its recorded checksum, installs the dependencies from the lock, then starts the app and runs the packed workflow once. If the connection drops, run the same command again; files already on disk that match are kept.
When it finishes it prints What's next: where your output lands and the command
that starts the app. renest start runs that command for you;
--listen 0.0.0.0 makes the app reachable from your own browser once you have
exposed its port in your provider's panel:
$ renest start --dir ./run --listen 0.0.0.0
To re-check the restored folder later, renest verify prints
Verified (… files byte-checked), or
Byte check failed: … missing, … with the wrong bytes or size — add
--json to see exactly which files.
Keeping nests in a bucket of your own instead of the drive also works: pack with
--dest s3 and sign the code on your own computer with renest
presign. See Restore anywhere.
pack picks up, and what it deliberately doesn't.