# Restore anywhere. > 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. Canonical page: https://renest.ai/docs-restore.html

A restore starts from a restore code or a manifest

# a restore code — the usual way
$ 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 downloadable from somewhere. A nest that lists no download sources needs --blob-base URL, the address its blobs/sha256/ folder is served from. 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.

There is a second, cheaper question you can ask before renting anything: --check-only stops after working out whether everything this nest does not carry — the files it expects to fetch from elsewhere — can actually be reached from here. 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: files an earlier run already confirmed are kept, 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.
--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.

$ renest restore --grant grant.json --dir ./run --plan

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.