Nodes/OpenOutpaint ComfyUI Interface/OpenOutpainter Serving
ComfyUI Node

OpenOutpainter Serving

The boss node that runs a fake A1111 API inside ComfyUI

By without-ordinary·Created about a year ago·Updated 9 months ago· 5
OpenOutpainter Serving
  • oop_styles
  • oop_checkpoints
  • oop_request
  • Server status
run_serverfalse
server_address127.0.0.1
port7860
enable_cross_origin_requestsfalse
request_id-1
spammy_debugfalse

This is the node that makes the whole pack work, and it's probably not what you think it is. OpenOutpainter Serving generates nothing, upscales nothing, and calls no external API. What it actually does is start a tiny HTTP server inside your ComfyUI process that speaks the same language as the AUTOMATIC1111 webui API - /sdapi/v1/txt2img, /sdapi/v1/img2img, /sdapi/v1/interrogate, and the rest - so the openOutpaint canvas can drive your ComfyUI workflow instead of an A1111 install.

Never met openOutpaint? It's the outpainting extension from the A1111 era: a resizable, infinitely-pannable canvas where you paint a mask over the edge of your image and hit generate to extend it, with layers, undo history, and a dedicated img2img tool. It was one of the better-known ways to do canvas-style inpainting/outpainting back when A1111 was the default. This pack re-aims that entire UI at ComfyUI. The author is refreshingly honest about the approach - the README opens with "This project is extremely cursed. You probably shouldn't do things like this does." Cursed it is. It's also the only real way to get that canvas UX with a ComfyUI backend.

How it works

Flip run_server to true and run the workflow once. That spawns a ThreadingHTTPServer on a daemon thread listening on server_address:port (default 127.0.0.1:7860). When openOutpaint POSTs a job, the server stashes the request and pushes a wo_QueuePrompt message over ComfyUI's websocket; the pack's web/httpserving.js extension catches it, writes the request id into the node's request_id widget, and re-queues the workflow. Your graph runs, and when the matching Output node finishes it wakes up the HTTP thread and the response goes back to the canvas. You literally watch each outpaint pass render live in the workflow - that's the "interactive" part.

Two details matter. First, IS_CHANGED returns NaN so this node re-executes on every single queue run; it has to, since it's checking for a fresh request each time. Second, request_id defaults to -1, which means "no pending request," and when there's no request the node returns an ExecutionBlocker - everything downstream just stops until openOutpaint actually sends a job. That's not a bug, it's the design: the graph idles until the canvas asks for something.

The inputs that matter

Only a few are worth touching:

  • run_server - the master switch. False and nothing starts.
  • server_address / port - where openOutpaint points. Local default is fine unless the canvas lives elsewhere.
  • enable_cross_origin_requests - flip it if you're serving openOutpaint from a different origin than ComfyUI.
  • spammy_debug - dumps every API request/response to the console. Great when things go weird, noisy otherwise.
  • oop_styles and oop_checkpoints (optional) - feed these from the Style Define and Checkpoints List nodes so the API can answer openOutpaint's dropdown queries.

Outputs are oop_request - the OOP_REQUEST you wire into every Input node downstream - and a Server status string that tells you whether the server is actually listening.

Install and gotchas

Install via ComfyUI Manager (search "OpenOutpaint ComfyUI Interface") or:

cd ComfyUI/custom_nodes
git clone https://github.com/without-ordinary/openoutpaint_comfyui_interface

Restart ComfyUI. Its one real pip dependency is opencv-python (that's the entire requirements.txt), and it needs a working openoutpaint_comfyui_interface install plus the fork of openOutpaint at without-ordinary/wo_openOutpaint pointed at this address - the upstream openOutpaint won't talk to this API properly.

The limits are real. Only one serving workflow may be active at a time; multiple Serving nodes in a graph is "behavior unknown," per the source. The server lives inside the ComfyUI process, so killing ComfyUI kills the canvas connection. And if your workflow errors mid-generation, the HTTP request just hangs - the code's own workaround is to re-run the workflow with the same request_id to complete it. It's not pretty. But for canvas outpainting on a ComfyUI backend, there's nothing else that does it.

CategoryOpenOutpaint-Serving

Inputs (8)

NameTypeDefaultDescription
run_serverBOOLEANfalse
server_addressSTRING127.0.0.1
portINT78601–65535
enable_cross_origin_requestsBOOLEANfalse
request_idINT-1-1–1125899906842624
spammy_debugBOOLEANfalse
oop_stylesoptOOP_STYLES
oop_checkpointsoptOOP_CHECKPOINTS

Outputs (2)

NameTypeDescription
oop_requestOOP_REQUEST
Server statusSTRING