Nodes/ComfyUI_NetDist/Fetch from remote
ComfyUI Node

Fetch from remote

Pull the finished image back from your other ComfyUI instance

By city96·Created 3 years ago·Updated 2 years ago· 507
Fetch from remote
  • final_image
  • remote_info
  • IMAGE

FetchRemote is the second half of NetDist's simplest trick: it's the node that actually hands you back the image your other GPU generated. On its own it does nothing - it only makes sense sitting downstream of RemoteQueueSimple (or a RemoteQueueWorker if you've gone the advanced route), waiting for whatever job that node shipped off.

NetDist is by city96, who you've probably run into already if you use quantized models - he's the same person behind ComfyUI-GGUF, the loader that put Flux and friends on 8-12GB cards. NetDist predates that and does something completely different: it doesn't touch your models, it turns a second ComfyUI process (a different GPU, a different port, sometimes a different PC entirely) into a worker you can hand jobs to over plain HTTP.

How it works

When RemoteQueueSimple fires, it POSTs your workflow to a second ComfyUI instance and hands FetchRemote a remote_info token describing that job. FetchRemote polls the other instance until it's done and downloads the resulting image. There's no streaming and no partial preview here - the README says it outright: "there's currently no preview/progress bar." Your graph will just sit there looking stuck until it isn't. That's normal, not broken.

The inputs and outputs that matter

Two required inputs, both non-negotiable:

  • final_image (IMAGE) - this is your local final image, the same output slot that exists on the remote workflow too. The README is blunt about the one trap here: "make sure not to route it back into itself." Don't wire this node's own IMAGE output back into its final_image input - that's a cycle ComfyUI's graph can't resolve.
  • remote_info (REMINFO) - the handshake token from whichever queue node sent the job. This is what tells FetchRemote which job on which host to poll.

Output is a single IMAGE - the actual pixels the remote instance produced, ready to route into Save Image, Preview Image, or CombineImageBatch if you want to merge it with what you generated locally.

How to install it

Through ComfyUI Manager, search for ComfyUI_NetDist. By hand:

cd ComfyUI/custom_nodes
git clone https://github.com/city96/ComfyUI_NetDist
pip install requests

Restart ComfyUI. That's the entire dependency list - requests, nothing else. No models, no CUDA extensions.

Common issues & troubleshooting

It looks hung and there's no way to tell if it's actually stuck. That's the point above, not a bug - no progress bar means a slow remote render and a genuinely wedged connection look identical from inside ComfyUI. Give it as long as you'd expect the workflow to take on that GPU before you assume something's wrong.

Wired the output back into final_image by accident. This is the specific self-feed loop the README warns about. If your graph won't queue or just spins, check you haven't looped FetchRemote's own IMAGE output back into its input.

It never comes back at all. That almost always traces back to the upstream remote_url on RemoteQueueSimple - wrong IP, wrong port, or the second instance simply isn't running yet. FetchRemote can't distinguish "still rendering" from "nothing's listening," so check the remote instance directly if you've waited well past a normal render time.

Running the remote instance across your LAN. If you launched the second ComfyUI with --listen so a different machine can reach it, remember that's now an unauthenticated endpoint on your network. Custom nodes run arbitrary Python with full OS-level access on load - there's no sandbox - so treat an exposed --listen instance the way you'd treat any other unauthenticated service and keep it off anything but a network you trust.

Categoryremote

Inputs (2)

NameTypeDefaultDescription
final_imageIMAGE
remote_infoREMINFO

Outputs (1)

NameTypeDescription
IMAGEIMAGE