🐳IP Workflow

You've got one machine with the GPU and another where you actually build workflows - or you want to fire a job at the beefy box down the hall while you keep tinkering locally. The name is a little dramatic: the 🐳IP Workflow node (class RemoteWorkflowExecutor) from the comfy_Pond_Nodes_V2 pack doesn't call some cloud API and needs no key. It does something simpler and rarer in the ComfyUI ecosystem: it takes a workflow JSON, ships it to another ComfyUI server over HTTP, runs it there, and pulls the results back. If you've ever found yourself duplicating node setups across two PCs because "that machine has the model, this machine has the GPU," this is the node that makes you stop.

How it works

Under the hood it's exactly what you'd write if you were building a remote-execution client by hand. The node connects to http://<ip>:<port>/system_stats to test the link, then walks the API-format workflow JSON you give it, swapping out the input nodes you selected. Your local IMAGE, STRING, AUDIO, and IMAGE (video, as a frame stack) inputs get uploaded to the remote server via its /upload/image and /upload/audio endpoints, and the matching nodes in the workflow - LoadImage, LoadVideo, LoadAudio, and text nodes like CR Prompt Text or Text - get their fields rewritten to point at the uploaded files. Then it POSTs the workflow to /prompt and listens on the WebSocket (ws://.../ws) for the executed messages, the same protocol the ComfyUI frontend uses. Outputs are downloaded through /view and converted back into tensors.

A few honest catches from reading the source. It returns only the last image, text, audio, and video it finds, so don't expect a batch of frames to all come back - output_image, output_text, output_audio, and output_video are single tensors. Video handling needs ffmpeg on your PATH (it shells out to extract audio from the mp4), and execution waits up to a hard 600-second timeout. Errors come back as Chinese-language strings in output_text (the README is Chinese too), so if you see a message you can't read, that's the node telling you the connection failed or the workflow isn't API format.

The inputs that matter

You mostly set three things, then forget it:

• remote_ip / remote_port - where the remote ComfyUI lives. Default 192.168.1.100:8188.
• workflow_file - paste the workflow's API-format JSON (Save → "Save (API Format)" in ComfyUI). Plain .json workflow files will be rejected.
• selected_nodes - a JSON map of which input nodes to override; the ⚙️ gear button and "解析工作流" (parse workflow) button in the frontend build this for you.

The JS extension does the heavy lifting in the UI: it parses the pasted workflow, shows you the input nodes it found, and generates the image_1, text_1, audio_1, video_1 ports you actually wire your local nodes into. There's also an IP-hiding toggle that masks the address in the UI - genuinely thoughtful if you screen-share, and the author's one nice touch.

Installing it

ComfyUI Manager: search comfy_Pond_Nodes_V2 and install. Manually:

cd ComfyUI/custom_nodes
git clone https://github.com/Pondowner857/comfy_Pond_Nodes_V2
cd comfy_Pond_Nodes_V2
pip install -r requirements.txt

Then restart ComfyUI. The dependency list is the real story here: requests, websocket-client, opencv-python, and torchaudio on top of the usual numpy/Pillow/torch - it's a chunky install for a node with one job, and it pulls opencv even if you never touch video. Your requirements.txt will do it; no model files to download.

Where people get burned

The biggest one has nothing to do with this node specifically: ComfyUI's API is unauthenticated by default, and the community has gotten loud about it. Anyone who can reach that port can execute arbitrary workflows - so run this over a trusted LAN or behind auth, never port-forwarded bare to the internet. The remote server also needs every custom node and model the workflow references, or the whole thing fails with an error the local node can't see in detail (the remote log is where you'll actually find it). And remember: both the HTTP and WebSocket ports need to be reachable, and large video inputs transfer over that link in real time. It's a LAN tool. Use it like one.