Update, September 2026. Kept as measured in July 2026; the packed environment is now called a nest. The finding in section 2 — judge a restore by the extensions the original machine actually loaded — became part of the current standard for counting a restore as working. Current results are on the Proof page. We no longer quote a "typical" door-to-door time.
Vol. 1 proved the mechanics on a minimal nest. This volume answers two harder questions: does capture survive a real workflow — custom nodes, a LoRA, actual dependency mess? And do Vol. 1's cleanest conclusions hold when we add Asian machines and more hosts? New spend: about $1.24. One process note first: this report went through two rounds of founder recomputation, which caught a table row filled from memory — a "Thailand 2080Ti" machine that never existed (the actual machine was an A4000 in Japan; the orchestrator logs prove it). New house rule: appendix rows may only come from logs. The corrections are kept in the report, not scrubbed.
The headline: a real workflow came back alive
The nest: ComfyUI + 3 custom nodes (controlnet_aux, Impact-Pack, ReActor) + SDXL + LCM-LoRA — 6.83GB, 7 files, with a Canny edge branch actually running in the workflow. The revive: byte-for-byte verified, image check passed at SSIM 0.9873 (across card models, A5000 → A4000), Canny branch working on both sides. The number we were hunting: the dependency step took 198 seconds — 3–7× heavier than the minimal nest's 28–65s, but it installed in one shot with zero failures. Door to door: boot 30s + transfer 118s + dependencies 198s + verification 32s + first image 16s ≈ 6.6 minutes — well inside the "typically 12–20 minutes" promise.
Two real findings — catching these was the point of the exam
1. Unpinned node dependencies drift into incompatibility. ReActor doesn't pin onnxruntime-gpu, so the resolver took the newest 1.27.0 — built for CUDA 13 — on a CUDA 12.4 machine. It installs fine and dies on import (libcudart.so.13: cannot open shared object file). Package installs don't check your GPU stack; the failure waits until launch. This kind of ecosystem rot is why lockfiles exist — but when upstream doesn't pin, a lockfile can only faithfully record the drifted result.
2. A nest can carry a node that never lived. ReActor never imported successfully on the packing machine either — same error. But "it runs" was judged by the nodes the workflow actually uses, so the broken node got packed without anyone noticing. The revive reproduced the defect exactly — same failure, same cause. Faithful reproduction is intact; what's missing is capture telling you at pack time which nodes actually load. That's now a candidate field for format v1.1.
Supply picture: 36 rentals in
Cumulative hit rate is now 22/36 = 61% (a mixed-cap tally; see Vol. 1 for the strict-cap caveat). Boot stays extremely consistent: p50 = 31.5s, p90 = 39s, worst 62s (n=22). We have still observed only one shortage window (that same European-afternoon slot) — so the time-of-day finding stays a cautious observation, not a rule. Hit prices span $0.104–$0.74/hr, about 7× — the spread isn't converging, and that's good news: absurdly cheap machines really exist and can really be rented.
Download speed vs. distance: from "irrelevant" to "layered"
Vol. 1 said download speed doesn't correlate with bucket distance. That conclusion still holds in its original scope — 20 new Europe/US measurements agree. But the new layer, Asia, is n=2 hosts and the two contradict each other: one Japanese host pulled a trans-Pacific US-West bucket at 867 and 841 Mbps — fast, no distance penalty — while the second showed an apparent distance gradient, except its own two pulls from the same bucket differed 2.2× (560.7 vs 254.6 Mbps), so the gradient can't be distinguished from its own variance. Honest verdict: the Asia-side distance effect is unresolved. Our guidance softened to: "a nearby bucket won't hurt; whether it's meaningfully faster, the data can't yet promise."
Determinism, layered by host — with a self-correction
We initially labeled two Japanese results "same host, stable." Rechecking offer IDs showed two different hosts — which makes the finding stronger and stranger: both Japanese A4000 hosts produced exactly 0.981439 (bit-identical to each other), while the Swedish A4000 hit a perfect 1.000000. That points to some shared regional factor, not a single machine's quirk. n is still small; the wording stays: "same GPU model is usually pixel-identical; host factors can create a stable micro-difference (>0.98, still passing)."
Dedup paid off for real, and a retraction on downloaders
Content addressing earned its keep: the exam's SDXL file matched Vol. 1's nest, so the upload skipped 6.46GB and sent only 447MB in 38.8 seconds. Streaming upload also landed: packing now adds 0.016GB of disk overhead — 0.2% of the nest — versus +100% before.
On downloader selection, our first benchmark was invalid and is retracted: aria2 wrote to disk while curl wrote to /dev/null (unfair), and the "host disk caps at 630 Mbps" attribution was wrong — the same host later wrote 2260 Mbps to disk. The fair rerun: single stream 1105 Mbps, aria2c -x8 2260, 8-way curl 5587 Mbps (6.9GB in 9.9s). Verdict: build our own range engine; keep aria2 for multi-source fallback.
Caliber
The real-workflow exam ran once — 198s is a data point, not a distribution. The 30–40GB video-scale nest hasn't been tested; that's where door-to-door times get their real stress test. Asia is two contradictory hosts. Networks inside China remain untested. And this report's own errata — a ghost machine, a retracted benchmark — are part of the data.