Getting started

Quick start.

A first Renest round trip is five steps: install the command-line tool, check the machine with renest doctor, pack a run that already worked to your drive, get a restore code from the web console, and run renest restore with that code on the other machine.

1 · Install the command-line tool

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.

2 · Check the machine first

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.

3 · Pack the run that already works

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.

4 · Get a restore code from the web console

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.

5 · Restore it on the other machine, then start it

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.

Where to next

• After the restore — finding your output and running the app again.
• If a restore stops — what each refusal and failure means, and what to do.
• Capture a run — what pack picks up, and what it deliberately doesn't.
• Restore anywhere — the two kinds of restore code, resuming, and what the pre-flight check refuses to do.
• Core ideas — what a nest, a manifest and a hand-off actually are.
• CLI reference — every command and the flags that matter.