🔗 Pipe Hub

The 🔗 Pipe Hub is what you reach for when your workflow has graduated from "a few wires" to "a wall of cables and I can't tell which IMAGE goes where." It's a single node that collects a pile of different-typed signals into one pipe, with a genuinely nice trick: the ports appear and label themselves as you connect things. Plug an IMAGE into it and the port literally renames itself IMAGE. Plug in two images and you get IMAGE and IMAGE_1. It's the closest thing to a self-organizing bundle in this pack.

How it works

Each Pipe Hub exposes a pipe_in input and a main pipe output plus up to 30 dynamic input/output pairs. The pair structure is the whole point: whatever you push into inX comes out the matching outX, and the names propagate through the pipe. The ports are * (any type), so it accepts IMAGE, MASK, LATENT, MODEL, VAE, CONDITIONING, strings - anything - without a single type error. A Fix button recalculates the whole connected network: it restores missing ports, cleans up orphaned ones, and re-syncs names across every hub in the chain.

The smart part is how it plays with others. Pipe Hubs chain in series - [Hub A] → [Hub B] → [Hub C] - with each hub inheriting the names and types of the one before, so you can insert new links at any point and everything downstream updates. And it's explicitly compatible with rgthree's SetNode/GetNode pair, the standard way to stash a value under a name and pull it back out later. The flow looks like:

[Pipe Hub A] → [SetNode (pipe)] → [GetNode (pipe)] → [Pipe Hub B]

What actually matters

• pipe_in / pipe - the bundle's main line. This is what you chain between hubs.
• in1 / in2 (…up to in30) - dynamic inputs that appear as you connect; names auto-label from the source.
• Fix button - resyncs ports and labels across the connected network. Press it after you move or delete things.

The one limitation the README is upfront about: Fix does not traverse a Set/GetNode pair. If your chain goes through Set/Get, you have to click Fix on both sides to fully refresh - annoying, but predictable once you know it. Also worth knowing: don't hang multiple Pipe Hubs off the same SetNode key, or the naming conflicts get weird.

Is it for you?

If you're building reusable subgraph-heavy workflows or you just hate 20 parallel wires, yes - this is one of the more ergonomic bundle nodes in the ecosystem, and the auto-naming beats staring at any1–any30. If your graph is small, it's overhead. And note the difference from the pack's fixed-channel Pipe 5/10/20/30 nodes: those have a static port count you plan around; the Hub grows dynamically, which makes it better for exploratory wiring and worse for "I need exactly these five slots, always."

Install

Part of Light-x02 Nodes - ComfyUI Manager → search "ComfyUI-Lightx02-Nodes", or:

cd ComfyUI/custom_nodes
git clone https://github.com/Light-x02/ComfyUI-Lightx02-Nodes

Restart ComfyUI, look under 💡Lightx02/Pipes. No extra dependencies. The dynamic ports are driven by the pack's js/ folder, so if you ever see it missing its auto-naming behavior, check that the extension's frontend files are loading (a stale browser cache is the usual culprit).