Short answer: a restore can bring every file back checksum-perfect and the app can still refuse to run, because some of what an environment needs lives on the machine, not in the files: the GPU generation, the CPU's instruction sets, the driver. That is why Renest promises the files and dependencies coming back checked — and treats "does it run" as something to test on every restore and report, not something to assume.
Verified bytes are not a running app
This is the lesson this project learned first, on its first archive: every file restored and matched its fingerprint, and the application crashed on start-up. Since then a restore only counts as working when the app starts and the recorded workflow produces output again — see three gates, not an exit code. Below are the three host-side failures we have hit on real rented machines, each one outside anything a nest can carry.
A GPU newer than the packed code
Compiled GPU code is built for specific GPU generations. Restore a nest packed on an older card onto a much newer one and every file can match while generation stops with CUDA error: no kernel image is available. The files were right; the machine was from the future.
What we check now: the nest records the GPU generation it was packed on, and the pre-check compares it with the machine you rented. A pairing that cannot work is refused before anything downloads.
A CPU missing an instruction set
On one rented host with an older CPU, the restore completed, every file verified, the dependencies installed — and ComfyUI died the instant it started with Illegal instruction. A numerical library in the environment ships native code built for the avx2 instruction set, which that processor does not have. There is nothing to debug: the binary is correct and the CPU cannot execute it.
One host, seen once, in a marketplace where hardware varies a lot — it says nothing about how common such machines are, only that they exist.
What we check now: the pre-check reads the CPU's instruction sets and refuses a machine without avx2.
A driver too old for the CUDA the environment needs
On another host, GPU driver 545.23 could not run a container built on CUDA 12.4 — every CUDA call failed with Error 803. Files exact, environment dead.
That incident taught us to be careful about which driver table applies. A Renest restore installs the environment's own PyTorch wheels, which carry their own CUDA runtime; for those, the vendor's minimum for CUDA 12.x is driver 525.60, and we confirmed it on a rented card with driver 535.154.05 by running a real matrix multiply on the GPU and checking it against the CPU result — not just asking the library whether CUDA was available. An older, stricter number we had copied from the CUDA toolkit table turned out to belong to a different install path and was turning away machines that worked.
What we check now: the pre-check compares the driver with the floor for the CUDA family the nest was built with, and refuses one that is too old.
What we will and won't claim
These failures define the boundary. What we stand behind: your files and dependencies come back, each one checked. What we deliberately don't say: "restored means usable". Whether it runs depends on the machine — its GPU, CPU and driver — which the nest has never seen. So the job is split: check what the nest carried, refuse machines that are provably wrong before you spend time on them, then start the app, run the workflow once and tell you plainly what passed.
If a restore does stop, If a restore stops lists the messages and what to do about each.