SendBase64ToRemote
Send an image to a workflow running on another ComfyUI box
SendBase64ToRemote is the "send" half of the comfyui-remote-tools pack, and the concept is refreshingly direct: it takes a base64 string (an image, typically), injects it into a remote workflow at a specific node's input, and dispatches that whole workflow to another ComfyUI server. Two ComfyUI instances, no shared filesystem, the image travels as text. That's the whole trick, and it's why the pack exists - the author's README is one sentence: "To connect to another ComfyUI server."
Here's the mechanism, grounded in the actual source rather than the marketing: the node json.loads your remote_prompt, then does prompt[remote_node_id]['inputs'][remote_node_input] = base64, then POSTs the whole thing to http://<remote_address>/prompt. That's it. It's marked as an output node with no return values, so it runs as an endpoint whenever your local graph executes - you can just drop it in, fill the widgets, and hit run.
A couple of mechanism details are worth knowing because they'll bite you:
- It's fire-and-forget. It returns as soon as the HTTP POST gets a response. It does not wait for the remote to finish. If you need the result back in the same graph, you run
LoadBase64FromRemoteas the companion - either in a second graph or after the remote completes. - Injection is silent when it fails. The code only overwrites the input
if remote_node_id in prompt, and then dispatches the workflow regardless. So if you typo the node id, nothing tells you - the remote just runs its workflow without your data. - It doesn't dodge the remote's execution cache. The load-side node renames node ids to force re-execution; this one doesn't. Send the exact same workflow and data twice and the remote may serve the cached run. In practice your base64 changes between sends, so this rarely bites.
The inputs that matter:
- base64 - the payload. It's
forceInput, so you're meant to wire it fromLoadBase64(js)(the pack's file-picker node) or any other source of base64 image strings. You'll almost never type it by hand. - remote_address -
host:port, no scheme, no trailing slash. Default127.0.0.1:8188; for a real second machine it's its LAN IP plus:8188. - remote_node_id - which node in the remote workflow receives your data (the key in the prompt JSON).
- remote_node_input - which input field on that node gets overwritten, default
base64Images. The remote node has to actually have an input with that name. - remote_prompt - the remote workflow, as API-format prompt JSON. This is the fiddly input; grab it by saving your remote workflow and pasting the
promptobject.
Install is the same for every node in the pack, and uncommonly light - no models, no heavy dependencies:
# ComfyUI Manager: search "comfyui-remote-tools" → install → restart
cd ComfyUI/custom_nodes
git clone https://github.com/linshier/comfyui-remote-tools
# restart ComfyUI
The shipped requirements.txt lists websocket-client plus a request line that's a typo for requests - the code actually imports requests and websocket, both already present in virtually every ComfyUI environment.
Troubleshooting, from the source and the ecosystem's well-worn warnings:
- Connection refused / timeout - the remote isn't reachable, a firewall is blocking 8188, or you put a scheme in
remote_address. It's plain192.168.1.50:8188. - Remote runs but your image isn't there - node id or input name doesn't match, and the code won't complain. Double-check both against the remote workflow's JSON.
- Security: this sends plain HTTP with no headers or credentials, and ComfyUI's
/promptendpoint is unauthenticated by default. Anyone who can reach that port can run arbitrary workflows on the remote. Keep it on your LAN, and if the remote ever needs to face the internet, put real auth in front of it first. - Don't expect updates - the pack is small and barely maintained (v0.1, last touched 2024). It's fine: it only depends on ComfyUI's stable
/promptAPI, so there's little to break.
If you're deciding between this and a proper distributed setup: for a fleet of load-balanced render boxes, NetDistro is the serious answer. This node is for the "I have one extra GPU and I want to use it" case, and for that it's refreshingly honest about being simple.
Inputs (5)
| Name | Type | Default | Description |
|---|---|---|---|
| base64 | STRING | — | |
| remote_address | STRING | 127.0.0.1:8188 | — |
| remote_node_id | STRING | 1 | — |
| remote_node_input | STRING | base64Images | — |
| remote_prompt | STRING | — |
Outputs (0)
No outputs