Mirroring ComfyUI models to make cold starts boring
Why app.nz mirrors popular Comfy model weights into R2 so GPU workers fetch predictable artifacts instead of relying on third-party hosts during cold starts.
Listen to this article
On-device voiceUses the voice built into your browser; no article text leaves this page.
Audio narration is not supported by this browser.
ComfyUI workflows often fail the same way: the container starts, the workflow queues, and then the worker spends a long time downloading model files from a third-party host. Sometimes the download is slow. Sometimes it is rate-limited. Sometimes it disappears.
app.nz's answer is to mirror known Comfy model files into R2 and make workers prefer the mirror.
The model index
The server keeps a Comfy model index. Each entry records enough information for a worker to place the file correctly:
- model id,
- source URL,
- Comfy folder,
- filename,
- size or metadata when known,
- mirror key.
The mirror key is deterministic. A given model maps to a stable object path in the appstatic bucket.
Streaming to R2
When a model is mirrored, the server streams the remote file into R2. It does not need to load the whole file into memory. Once mirrored, the model can be served from app.nz-controlled storage.
That changes the operational dependency. Instead of every worker relying on Hugging Face, Civitai, or another host at boot time, app.nz relies on its own object store path for the hot files.
Worker lookup order
Workers should prefer:
- app.nz R2 mirror,
- original upstream URL,
- fail with an explicit missing-model error.
The fallback keeps obscure workflows usable before every model is mirrored. The mirror keeps popular workflows fast and reliable.
Why this helps cold starts
Mirroring does not make weights smaller. It makes weight fetches predictable:
- fewer upstream rate limits,
- fewer random host outages,
- better regional placement,
- reusable URLs,
- easier cache headers,
- no surprise auth pages.
For serverless workers, this matters because every scale-from-zero can become a weight fetch. For pods, it matters after a new image or new workflow lands on a fresh machine.
Workflows should declare models
The long-term fix is for workflow deployment to understand its model dependencies before the first run. If app.nz can parse or ask for the required model list, it can:
- verify mirrors exist,
- show expected disk footprint,
- prewarm the worker cache,
- fail before a user waits on a doomed run.
That is the difference between "queue a graph and hope" and a deployable Comfy app.
The principle
Cold starts are not only container starts. They are also data starts. Moving a 7 GB checkpoint is part of the start path. If app.nz wants predictable GPU latency, it has to own the artifacts, not just the containers.