Queue Manager

First, a naming warning, because it matters more than anything else here: "Queue Manager" is one of the most overloaded names in the ComfyUI ecosystem. rgthree has a Queue Node, there are half a dozen queue-ish utilities in ComfyUI Manager, and ComfyUI itself ships a queue tab in the bottom bar. The AC ComfyUI Queue Manager is none of those. It's not a node that sequences graph execution or builds control flow - it's a small, separate queue database with its own web interface and REST API, and its pitch is simple: your queue survives a restart.

Out of the box, ComfyUI wipes the pending queue when you close it. If you batch a bunch of jobs overnight and the machine hiccups, they're gone. This pack's whole reason to exist is persistence - everything you run gets recorded in a SQLite database (queue_manager.db, sitting in the custom node folder) and shows up in a web dashboard you open from the ComfyUI menu. Think of it less as a node and more as an "execution history you can filter, archive, and export."

How it actually works

The QueueManagerNode you drop into the graph is almost embarrassingly simple: on execution it builds a row with your workflow name, priority, tags, and a timestamp, and hands it to a QueueService that writes to SQLite. Then it returns (queue_item_id, queued_successfully).

The interesting machinery lives around it. A WorkflowInterceptor monkey-patches ComfyUI's execution path so every prompt you run gets captured automatically - even workflows that never contain the QueueManagerNode. The node itself returns float("nan") from IS_CHANGED, which is the standard ComfyUI trick to force it to execute on every run so it never misses a capture. A Flask app serves the web UI and REST API on port 5000, and queue items flow through the usual states: pending, running, completed, failed, archived.

The inputs that matter

Four optional inputs, and honestly you'll touch two of them:

• workflow_name (STRING, default "Workflow") - the label that shows in the queue. Name it something real or the dashboard is just a wall of "Workflow."
• auto_queue (BOOLEAN, default true) - if you flip this off, the node runs, logs "auto-queue disabled," and writes nothing. It's your opt-out switch, and it's easy to forget it's there.
• priority (INT, -10 to 10, default 0) - ordering hint for the queue. Higher runs first, that's it.
• tags (STRING, "") - comma-separated labels that feed the filter/search in the web UI.

The outputs are queue_item_id (STRING) and queued_successfully (BOOLEAN). In practice, they're bookkeeping - you'd wire queued_successfully somewhere if you're chaining anything off queue state, but most people just read the dashboard.

Installing it

Via ComfyUI Manager, search for "AC ComfyUI Queue Manager" - and double-check you got this one, not one of its name twins. Or the manual way:

cd ComfyUI/custom_nodes
git clone https://github.com/abdullahceylan/ac-comfyui-queue-manager.git comfyui-queue-manager
cd comfyui-queue-manager
pip install -r requirements.txt

Then restart ComfyUI. The good news: the only runtime dependency is flask>=2.3.0, and there are zero model files to download. Install it, restart, done.

Where people get burned

The README's own troubleshooting table is a preview of the pain: "Interface not loading" → check port 5000. That's the classic Flask port, which collides with AirPlay on macOS and a thousand other dev servers. If the dashboard won't open, that's your first suspect.

Second quirk, straight from the README: "Workflows not appearing" → open the Queue Manager interface first. The interceptor that captures your runs initializes when the extension loads, and the first-launch experience is finicky about it. If you run a job and it doesn't show up, open the dashboard once, restart, and re-run - that usually brings things in sync.

Honest caveat, because I looked: this pack has essentially zero community footprint yet (no reddit chatter, a tiny comfy.icu impression count, a young repo). It's a genuine, working tool with solid docs, but you're an early adopter. If it misbehaves, expect to read the source rather than find a fix thread. For the use case - a persistent, filterable, exportable record of every job - it does the job, and the API makes it scriptable. Just know that "queue manager" in the search bar has never been a more misleading pair of words.