Connection Node
The Master Key That Does Nothing by Itself
- connection
The name is a small lie: the Connection Node doesn't actually connect to anything by itself. It's a key ring. You hand it three facts - your Open WebUI address, its port, and an API token - and it hands back a little bundle that every other node in the comfy-openwebuiapi pack (Generate Text, Generate Image) requires before they'll talk to your Ollama setup. No Connection Node, no pack. It's the first node you place in any workflow from this author, and usually the last one you think about again.
Why you'd reach for it: because you want a local LLM inside a ComfyUI graph, and this pack's way of getting one is to borrow the Ollama server already sitting behind your Open WebUI chat app. That's the "external Ollama server" pattern - as opposed to in-graph GGUF loaders - which means the language model runs in its own process and ComfyUI never loads one itself. You get prompt enhancement, image captioning, or plain chat, whatever the model in Ollama can do, and the Connection Node is the credential that makes the handshake legal.
How it works. Under the hood it's a straight pass-through: it packages ip, port, and api_token into one dict and emits it on the connection output. No network call happens here - the network happens downstream in the Generate nodes. The sneaky part is elsewhere: the pack's JavaScript walks your graph to find this node, reads its widgets, and calls a small server endpoint that asks Ollama (through Open WebUI) for its model list. That's how Generate Text gets its model dropdown populated without you ever typing a model name - which is why, despite the README claiming the Connection node "outputs models," the list actually shows up dynamically in the Generate node. The README is a little optimistic there; you'll see a dropdown, not a string.
The three inputs that matter:
ip- defaultlocalhost. Whatever host you type to open Open WebUI in a browser belongs here. If Open WebUI runs in Docker, "localhost" from ComfyUI's perspective isn't the container's view of itself, so use the host/IP you actually browse.port- default3000, Open WebUI's default. Mapped the container to something else? Use the port you browse.api_token- the JWT token you generate in Open WebUI under user settings → API keys (it's labeled JWT-Token). This is not an Ollama API key.
Output: connection (*), the only one, and it wires straight into the connection input on Generate Text and Generate Image.
Install, same for every node in the pack: ComfyUI Manager → search "Open WebUI API", or
cd ComfyUI/custom_nodes
git clone https://github.com/Gladon4/comfy-openwebuiapi
then restart ComfyUI. Dependencies are pillow, requests, torch, numpy - all things ComfyUI already ships, so there's no extra pip step.
Where people get burned:
- Wrong token type. You need the Open WebUI API key (JWT), not an Ollama key. Generate it in the web UI's settings and paste the whole thing.
- Host/port mismatch. The README's rule is exact: it should be the same IP and port you use to reach the web view. If the browser works and the node doesn't, that's the first suspect.
- The token sits in the workflow JSON in plaintext. Share that workflow file and you've handed out your credential. Don't paste a workflow with your token in it - and more broadly, a node that holds a key and phones out by design is exactly the shape of thing to install from the real repo and read before running. This category has been weaponized once already.
The Connection Node is boring on purpose. Get it right once, and the rest of the pack just works.
Inputs (3)
| Name | Type | Default | Description |
|---|---|---|---|
| ip | STRING | localhost | — |
| port | INT | 30000–65535 | — |
| api_token | STRING | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| connection | * | — |