Send Images

The whole point of renting a cloud GPU is that you don't want to sit there waiting on your own. Send Images is the node that hands a picture to the other ComfyUI over the wire - so your local instance feeds an input image to a RunPod or Vast.ai box doing the actual generation, or ships a result back home. It's the workhorse of the ComfyUI-Jumper pack, and for once the name isn't a lie: it opens a raw TCP socket and throws your image tensor down it.

How it works

Send Images takes an IMAGE tensor batch, turns it into bytes, and pushes it to the peer over a plain socket. The transport is the same for every Jumper node: a size prefix, the format name, a SHA-256 hash, and base64-encoded payload. The receiving side (a Receive Images node) checks that hash and refuses anything that doesn't match, so you get corruption errors rather than silent garbage.

The mode input decides who dials and who listens. Client connects to the address; Server binds and waits for a connection. The README's rule is simple: local is Client, remote is Server. Because you're expected to run the whole thing through an SSH tunnel (ssh root@REMOTE_IP -p REMOTE_PORT -NL 8282:localhost:8282), the same tunnel carries traffic both ways - your Client dials 127.0.0.1:8282, and the remote Server sitting on the other end of the tunnel accepts it.

The inputs that matter

• addr - host:port, default 127.0.0.1:8282. Change it on the node if you want a different port, or edit DEFAULT_ADDR in nodes.py.
• mode - Client or Server. Match the role with the Receive Images node on the other side.
• images - the IMAGE tensor you're shipping.
• send_as - this one's the real decision:

| send_as | Size | CPU | What it does | | --- | --- | --- | --- | | png | Small | Moderate | Converts each tensor to a PNG before sending | | zlib | Large | Moderate | Compresses the raw tensor | | raw | Very large | Very low | Sends the raw tensor untouched |

That table is the README's, and it's worth taking seriously. png is the lossy one - tensors round-trip through uint8 0–255, so it's fine when the receiving side just needs to look at the image or run it through img2img with a fresh encode. But if you need the exact values back - say you're re-feeding the received image into an IP-Adapter or ControlNet preprocessor where precision matters - use zlib or raw. The progress bar also tells you what it's doing: the first 100 ticks are conversion, the second are the actual sending.

The one thing you can't skip: order. It's an input and an output on the same node. Chain every Jumper node together by wiring one node's order output into the next node's order input (start the chain with a Primitive Int at 0), and wire the end of the chain into something like a PreviewAny so the whole sequence actually runs. Both sides must have the same chain, because order is how a Send and a Receive know they're talking about the same message. It increments by one each run.

Installing it

ComfyUI-Jumper is a no-dependency, no-model pack - requirements.txt is empty and there's nothing to download. It's published to the Comfy registry, so the easiest path is ComfyUI Manager: search for ComfyUI-Jumper and install. Or, per the README:

cd ComfyUI/custom_nodes/
git clone https://github.com/myonmu0/ComfyUI-Jumper

Then restart ComfyUI.

Where people get burned

Two things, mostly. First, job cancel doesn't work while a Jumper node is running - the README calls this a known issue, and the fix is restarting ComfyUI. So don't send a 4K batch if you might want out halfway. Second, this is unencrypted TCP with zero authentication - the author is emphatic that you must use an SSH tunnel for anything remote. The ComfyUI community learned the hard way that exposing an unauthenticated ComfyUI instance to the internet is how you get your box walked through and your API run for someone else's benefit. Jumper doesn't change that calculus: the tunnel is the lock, not the node.