🔒 HTTPS Bridge Info

Here's the niche this node exists for. You built a slick "wrapper" web app - think a custom gallery, a client portal, an internal tool - and you deployed it on a public https://yourapp.com page. Now the browser flat-out refuses to let that page talk to your local ws://localhost:8188. That's not a ComfyUI problem, it's the browser's mixed-content policy: a page served over HTTPS will not connect to an unencrypted localhost endpoint, no matter how much you beg. ComfyUI's own web UI works because it is the local page. Your hosted wrapper isn't.

The name is a bit of a lie - "bridge" here is a local HTTPS proxy, not a cloud relay. It calls no external API and needs no key. It just gives your browser a URL it's allowed to talk to.

What it actually does

comfyui-https-bridge is a two-piece setup. On load, it generates a self-signed TLS certificate (via the cryptography library - no openssl, no external tools, valid 10 years, stored in a .certs/ folder inside the pack) and boots a small aiohttp HTTPS server on port 9999 in a background thread. Then every request that hits https://localhost:9999 gets forwarded to your real ComfyUI: plain HTTP requests (streamed in 64KB chunks, CORS headers added, up to 512MB bodies), WebSocket connections (bidirectionally piped), and image streaming all pass through.

It's smart about where ComfyUI lives. Detection priority is: environment variables COMFY_HOST/COMFY_PORT → whatever --listen/--port ComfyUI was launched with → default 127.0.0.1:8188. If you run with --listen 0.0.0.0, it resolves your actual LAN IP and bakes it into the certificate so the IP is covered too.

Then in your app's connection settings, you point it at https://localhost:9999 instead of the localhost:8188 URL that was never going to work from a hosted page.

The node itself is a readout, not a data node

Here's the honest bit: the HttpsBridgeNode (display name "🔒 HTTPS Bridge Info") does no work in your graph. It takes zero inputs and returns a single STRING - the status text HTTPS Bridge: https://localhost:9999. The proxy starts the moment the pack loads in ComfyUI, whether or not this node is on your canvas. The node is a status indicator you can drop into a workflow to see the bridge URL, or hang off the end of a workflow as an output node (which is how it's registered) so you always know which address your app should connect to. Nothing about image generation flows through it, and that's fine - its job is the network plumbing, and it does that in the background.

Installing it

Standard custom-node install, nothing exotic, and no model downloads:

cd ComfyUI/custom_nodes
git clone https://github.com/caissonfiv/comfyui-https-bridge.git
cd comfyui-https-bridge && pip install -r requirements.txt

Or just search ComfyUI-HTTPS-Bridge in ComfyUI Manager and let it handle it. The requirements are cryptography and aiohttp; aiohttp ships with ComfyUI already, so cryptography is the only real dependency to worry about. Restart, and the bridge starts in the background automatically.

The one-time certificate dance

Because the cert is self-signed, your browser will throw a fit once. Open https://localhost:9999, click Advanced → Proceed to localhost, and you'll get a page (possibly blank - that's the proxy talking to ComfyUI's root). The browser remembers the exception permanently after that. Do this in whatever browser your wrapper's users use, because each one needs its own approval.

Where people get burned

• Port 9999 already in use. The bridge logs a warning and simply doesn't start. Fix with COMFY_BRIDGE_PORT=9998 python main.py.
• "Can't connect to ComfyUI" in your app - that's the proxy returning a 502, which means ComfyUI isn't listening where the bridge thinks it is. Check --listen/--port or force it with COMFY_HOST/COMFY_PORT.
• The bridge starts even if you never add the node. That's by design ("zero configuration"), but if you only installed the pack to test something, the proxy is live regardless.
• The security one, and it's real: the bridge binds 0.0.0.0 with no authentication, and ComfyUI's own API is unauthenticated. Anyone who can reach port 9999 and accepts the cert effectively has your ComfyUI. The self-signed cert does block random strangers (browsers refuse it without consent), but on a LAN or a port-forwarded box this is a genuine opening. The community's been saying "secure your ComfyUI instance" for years for exactly this reason - don't run this on anything reachable from the internet.

If your wrapper isn't browser-based at all, skip this - a tailscale or SSH tunnel is simpler and skips the cert ceremony entirely. But for a hosted web app that must reach a local ComfyUI, this is the least-fiddly way to close the mixed-content gap.