Guides

Restore a nest.

renest restore brings a nest's files and dependencies back on another machine: it checks the machine first, checks every file against its recorded checksum, reinstalls the dependencies from the lock, then starts the app and runs the packed workflow once. When this machine can't run the nest, it says so before downloading.

A restore starts from a restore code or a manifest

# a restore code — the usual way
$ cd /workspace 2>/dev/null || cd ~
$ renest restore --grant grant.json --dir ./run

# a manifest whose files you can already reach
$ renest restore --manifest https://…/nests/<nest-id>/manifest.json --dir ./run

--grant takes the code as a file or as a URL. --manifest takes a manifest file or URL; the files themselves have to be reachable from somewhere. A manifest file read from a nest folder on this machine takes its files from the blobs/sha256/ folder beside it. Otherwise, a nest that lists no download sources needs --blob-base: the URL its blobs/sha256/ folder is served from, or that folder's path on this machine. For anything on your drive or in a private bucket, use a restore code.

Your drive issues restore codes; renest presign signs them for your own bucket

A restore code lets a machine download one nest version without ever seeing a storage key. There are two kinds, and they come from different places:

• From your Renest drive. In the web console, open the nest and choose Restore. You pick how long the code lasts — 1 day, 3 days or 7 days — and the page gives you a command that writes it to grant.json and runs the restore. The code is not tied to a machine: if a pod breaks, paste it on another one. You can revoke it from the console at any time.
• Signed by you, for your own bucket. If your nests live in an S3-compatible bucket you set up yourself, renest presign signs time-limited links on the computer that holds your bucket key. It needs that key configured (run renest doctor --storage for the steps); without one it stops with No bucket of your own is set up yet. The links cover what is in the bucket, so pack with --dest s3 first. The code lasts 6 hours by default and 24 hours at most (--expires-in, in seconds); when it runs out, sign a new one.

# own bucket only: on your own computer, where the key lives
$ renest presign --manifest ./nests/nests/<nest-id>/manifest.json --out code.json
# on the rented machine
$ renest restore --grant code.json --dir ./run

Either way the rented machine gets the code, never the key. A machine you rented for an hour should not be able to read your storage tomorrow.

The pre-flight check runs first, and it can refuse

Before pulling a single byte, Renest checks the machine against the nest: disk space, driver, and — the one that actually bites — GPU architecture. Code compiled for one generation of card does not run on a newer one it was never built for; you get no kernel image is available at the worst possible moment, half an hour into a paid rental.

So the check blocks that case up front. If you know better, --force goes ahead anyway.

It also looks for git, a C compiler, git-lfs and the system libraries the working run loaded. If any is missing and this account is root or can use sudo without a password, it asks Install them now? before anything downloads; --yes skips the question. Without those rights it prints the command instead. If an install it attempted fails, the restore stops there, and --force goes ahead anyway.

There is a second, cheaper question you can ask before renting anything: --check-only lists every file this nest does not carry — with its size and the address the nest recorded for it — says which of them can be fetched from here, and stops without moving any bytes. It needs no GPU, so run it on your laptop.

The hardware check is available on its own too — see doctor.

If it dies halfway, run the same command again

Big models over a shared link means interruptions. Re-running the same restore picks up where it left off: a file already on disk with the right size and matching bytes is kept, and everything else is fetched again. --reverify checks the kept files against their checksums once more; --no-resume forces a clean start.

If a source is unreachable, the restore falls back to the next place that file can be found and checks whatever it gets against the recorded checksum. A dead download link doesn't end the restore.

A few flags change what a restore does

• --package-source ADDRESS — install dependencies from a package index closer to you when the default one is slow. Every package is still checked against the fingerprint recorded in the nest, and the address has to be one Renest recognises, or one you name with --trust-host.
• --yes — install the git, C compiler, git-lfs or system libraries the nest needs without asking. Only works as root or with password-free sudo; otherwise the command is printed.
• --no-setup — don't run the setup commands the nest brought with it. You get the files; the environment may be incomplete, and the report says which commands were skipped.
• --skip-launch — restore the files and dependencies, then stop, without starting the app or running the packed workflow.
• --no-report — with a code from your drive, the restore reports its progress back so the console's Restore page can show it: which stage it is in, how fast, how it ended, and facts about this machine (GPU, driver, free space). It never sends your file names or paths, the raw error text of other programs, or which host the files came from. If reporting fails it goes quiet and never affects the restore. --no-report turns it off.

renest verify checks a restored folder again, at any time

A restore checks files as it goes. To check again later — say, before trusting a restored folder that's been sitting around:

$ renest verify ./manifest.json --dir ./run
Verified (… files byte-checked)

--check bytes is the default and compares files. If any are missing or wrong it says how many — Byte check failed: … missing, … with the wrong bytes or size — and --json (or --report to a file) lists which ones. --check image goes further and compares a newly rendered image against the one captured, for when you want evidence that the environment is alive, not merely present — hand it the picture with --rendered, or add --render and Renest will start the restored app and produce it (it asks first, because that spends this machine's GPU time). --check both does both.

Nests someone handed to you

Restoring another person's nest means running their custom nodes and setup steps on your machine. Renest treats that as what it is:

Make a habit of reading first: --plan checks this machine, then lists what the restore would download, whether the dependency list resolves, what the nest does not carry, and every setup command it would run, in full — and stops before a single byte is fetched. If the machine fails the check, --plan gives you that verdict instead of a plan.

$ cd /workspace 2>/dev/null || cd ~
$ renest restore --grant grant.json --dir ./run --plan

• It lists every file that does not travel before anything downloads, in two groups: the ones it will fetch for you from their public original source and check against the nest, and the ones you need to provide, each with the exact path to put it at. If any cannot be had, it stops before the big download (exit 16) and names them all; put them in place and run the same command again. An address on a host Renest doesn't recognise is not contacted until you name the sender with --trust-sender.
• It shows you who sent it and stops before running any setup step from a stranger. --trust-sender is how you say you know them.
• It prints the setup commands before running them, including for nests you packed yourself.
• It only installs dependencies from well-known sources by default — that step runs code those servers hand you. An internal mirror is allowed with --trust-host — see unrecognised dependency sources. Model files travel a different path and are checked against their recorded checksum instead.

When it finishes, it tells you what to run next

A restore that finishes prints Done, then What's next: where your output lands, the command that starts the app, and renest start --dir ./run, which runs it for you. After the restore covers that part.

If it stops instead, the last lines name the stage and the reason. If a restore stops goes through them one by one.