WebSocket Serving

WebSocketServing is the node for when Discord and Telegram are the wrong shape for what you're building. Instead of hosting a bot, your ComfyUI instance becomes a client that connects out to a WebSocket server you control - your own front end, a dashboard, a game, whatever. You send it JSON, it runs your workflow, and it pipes the image back over the same socket. It's the most "plumbing" of the pack's four entry points, but if you're building your own app, it's the one that fits.

The protocol is dead simple, which is the point. Outbound you send:

{ "_requestId": "abc123", "command_name": "generate", "prompt": "a robot saying it works!" }

and the node answers with:

{ "_requestId": "abc123", "base64_img": "<data>" }

with the request ID echoed back so you can match responses to requests. Output nodes map to fields the same way they do elsewhere: base64_img from ServingOutput, base64_images from ServingMultiImageOutput, text from ServingTextOutput. The command_name property is how commands route, mirroring the !command syntax on Discord - a CommandPickerServing node filters on it.

The pack ships a working reference server in examples/websocket.js (a Node/ws app that listens on port 8080 and saves whatever image comes back). Run it and you're two commands from a round trip:

cd examples
npm install
node websocket.js

then set the websocket_url input on the node to ws://localhost:8080.

The single input is websocket_url. That's it. The output is the usual Serving config that feeds the input and output nodes. The connection is resilient - run_forever(reconnect=1) keeps retrying and the error handler restarts the loop, so a dropped socket won't kill your workflow, it'll just wait.

Install via ComfyUI Manager ("Serving Toolkit") or clone into custom_nodes and pip install -r requirements.txt. The websocket client depends on websocket-client (and the rel reconnection helper); everything else is shared with the rest of the pack. No model downloads.

Two honest caveats. First, this needs something on the other end of the socket - unlike the Discord/Telegram nodes, there's no free front end included; the example server is a demo that auto-sends a prompt every five seconds, not a real app. Second, the usual serving gotcha applies harder here: the node blocks waiting for a message, so Auto Queue must be on, and your workflow is effectively single-request-at-a-time, so a slow generation holds up the queue while the socket waits. If your front end sends while the workflow is still busy, requests line up rather than parallelize. Fine for a personal tool; think twice before building a public service on it without putting a queue in front.