RemoteCLIP Server

RemoteCLIP Server is the "other side of the fence" node in the lhyNodes remote pipeline: the machine that actually holds the CLIP and VAE models and does the encoding work for a workflow running somewhere else. You wire real CLIPs and VAEs into it, tell it which port to listen on, and it becomes a small model-serving daemon inside your ComfyUI instance - one that other machines' ComfyUI installs can borrow from.

The design is intentionally spare. Required inputs are just bind_ip (default 0.0.0.0, i.e. listen on all interfaces) and listen_port (default 8181). The optional inputs are where the actual models go: up to four CLIPs (clip_1 through clip_4) and four VAEs (vae_1 through vae_4). Load your text encoder and VAE as usual - say the SDXL or Flux CLIP and a good VAE - wire them into the slots, and the node opens a TCP server that answers encode and decode requests. It's an output node, so it runs for as long as the workflow runs, accepting connections in the background.

When a client (the RemoteCLIP Client node on another machine) asks for encoding, the server tokenizes the prompt text, runs the real CLIP encode, and ships the conditioning tensors back over the wire. Same for the VAE slots - it'll decode latents to pixels or encode pixels to latents on request. Under the hood it's a plain socket server with its own little binary protocol for shipping tensors, plus keep-alive connections so a long session doesn't drop.

The inputs that matter

• clip_1–clip_4 - up to four CLIP models to expose. The client picks one by index, so the numbering is the contract between the two sides.
• vae_1–vae_4 - up to four VAEs, same deal.
• bind_ip / listen_port - where to listen. Default 0.0.0.0:8181 works for LAN use; don't expose it past your firewall.

Realistic expectations - and the honest warnings

This is where the security caveat gets serious. The protocol is plain TCP with no authentication and no encryption. Any machine that can reach the port can request encodes, and there's no handshake to filter clients. That's fine inside a trusted home LAN; it is a bad idea on any network you don't fully control. Treat this like an open port, because that's literally what it is.

The other thing to know: the server holds its models in VRAM while listening, so you're dedicating memory on the serving machine. And because a client reconnects and re-fetches models on demand, the server node runs every workflow pass - that's why it's marked as always-executing under the hood, so don't be surprised when it shows activity even if nothing "visually" changes.

Installing it

Part of lhaoyun6/ComfyUI-lhyNodes. Install via ComfyUI Manager by searching for lhyNodes, or:

cd ComfyUI/custom_nodes
git clone https://github.com/lihaoyun6/ComfyUI-lhyNodes.git
python -m pip install -r ComfyUI-lhyNodes/requirements.txt

Restart ComfyUI after. The pack's shared requirements are ultralytics, opencv-python, numpy, and yarl; the models you expose are whatever you load into the slots - no special downloads.

For a two-machine setup where one box has the VRAM and the other has the workflows, this plus the client is a clean way to split the load. Just remember: the node doesn't add security, it adds a port - so keep it on the LAN.