SmartGallery DAM indexes your ComfyUI output without touching ComfyUI

ComfyUI-aware, ComfyUI-independent, and that is the bet

The central design decision is stated plainly: SmartGallery DAM is aware of ComfyUI but independent of it. It runs as a fully separate process, not a custom node, sharing no dependencies with ComfyUI's environment, and it keeps indexing and organising a library whether ComfyUI is running, broken after a Python update, mid-upgrade, or uninstalled entirely.

Awareness means it parses what ComfyUI produces: it reads workflow data, extracts prompts, and understands which models and LoRAs were involved, which is what makes prompt search and generation remixing possible without opening the node canvas.

Independence is what makes it survive. The stated line is that your DAM outlives any tool it connects to. Practically, you can run it beside ComfyUI on a different port, or run it on a different machine and point it at the output folder over the network, and if you switch generation tools entirely it still works, because it was never ComfyUI-only to begin with.

That bet also explains the feature set. The Queue Deck exists because the DAM can watch a running ComfyUI without being part of it, and the Remix Engine exists because it can queue work without hosting the graph editor.

One Python file, Flask and waitress, and the filesystem as the database

The application is a single Python entry point, `smartgallery.py`, with a `templates/` directory holding the interface. The dependency list is short and readable:

Flask
Pillow
opencv-python
numpy # needed for opencv-python
tqdm
werkzeug # needed for Flask
markupsafe
pyOpenSSL
click
itsdangerous
blinker
cryptography
waitress

What is missing from that list is as informative as what is in it. There is no database driver, no ORM and no SQLAlchemy. Everything a digital asset manager usually stores in tables, tags, ratings and comments, this one keeps on disk, which matches the promise of an in-browser file manager that renames, moves, copies, deletes and creates folders, and of nested collections as virtual albums with zero duplication on disk.

`waitress` is there rather than a development server, so the default serving path is a production WSGI server rather than Flask's own. Pillow and opencv-python handle images, pyOpenSSL and cryptography handle TLS material, and that is the whole dependency surface.

One curiosity worth noting: GitHub reports the repository's primary language as HTML, which reflects the templates directory rather than the application code.

The Queue Deck is what the last two releases were about

Release history is a good way to read where a project's effort is going, and here it is unambiguous. Version 2.23 in early September introduced the ComfyUI Queue Deck, a feature for inspecting and managing generation queues. Version 2.24 a few days later was an improved Queue Deck interface. Version 2.24.1, published on 2026-09-17, was about improved folder sync speed plus moving the Docker image to Python 3.14 and fixing bugs.

The Queue Deck itself is described as real-time mission control for execution queues: step tracking, a live stream preview, and GPU and VRAM load, reachable with `Shift+Q`. It is positioned explicitly as a way to bypass the node canvas.

So the project moved from being a gallery to being an operations console for the thing generating the gallery's contents. Two keyboard-first features arrived in the same period, which tells you the intended user is driving a long generation queue and does not want to alt-tab into ComfyUI to see what is running.

The other recent addition is Smart Asset Clustering, bound to `Shift+C`, which groups generations by node architecture or by prompt text and labels each group with a coloured hash badge.

Search arrives in three layers, and only one needs a model

There are three distinct search capabilities, and they differ in cost and in what you have to know.

The first is field search: find by prompt, checkpoint, LoRA with live autocomplete, date or comment. This is a filter over indexed metadata and needs nothing external.

The second is OmniQuery, which takes plain English with any criteria and has a model write the SQL behind it. This is the feature the repository description summarises as querying the gallery with AI in natural language, and it is the one place where a language model is in the loop. The visible documentation does not say where that model comes from or whether a key is needed, which is the first thing to check before planning a deployment around it.

The third is LoRA Synergy, and it is the opposite case. It is described as a fully offline matchmaker that scans Safetensors files to guarantee checkpoint compatibility across SD1.5, SDXL and Flux, surfaces trigger words, and auto-wires the workflow. Compatibility checking by reading the weights' own metadata costs nothing and needs no network, which makes it the most portable of the three.

The portable app and the container are different products

Two deployment paths are offered, and they are not the same thing with different packaging.

The Windows path is a zero-config portable app: unzip and run, with no installer and no Python runtime to arrange. The Docker path pulls a published image and mounts your ComfyUI directories:

services:
  comfy-smartgallery:
    image: mmartial/smart-comfyui-gallery:latest
    ports:
      - 8189:8189

Two things to notice in that snippet. The image lives under the `mmartial` namespace on Docker Hub while the repository is `biagiomaf/smart-comfyui-gallery`, so the image you pull is not named after the project you are reading. And the container needs the output, input and gallery paths mounted at `/mnt/output`, `/mnt/input` and `/mnt/SmartGallery`, plus the address of your ComfyUI server:

      - BASE_OUTPUT_PATH=/mnt/output
      - BASE_INPUT_PATH=/mnt/input
      - COMFYUI_SERVER_URL=http://192.168.100.1:8188

That last value is a placeholder from someone's network, and the comment above it says so: update it to reflect your host. Leave it and the Queue Deck will be watching nothing.

The container grants passwordless sudo and a readable umask

The container is built to run as an unprivileged user with a specific uid and gid so that files it writes on mounted volumes belong to you, which is the right instinct for a tool writing into your ComfyUI output folder. The compose file sets `WANTED_UID` and `WANTED_GID` to 1000 with a comment telling you to substitute your own values from `id -u` and `id -g`.

The Dockerfile goes further than that needs. It installs `sudo` among its system packages, appends a passwordless sudoers rule, and creates two users who are both in that group:

FROM python:3.14-slim
ENV FFPROBE_MANUAL_PATH=/usr/bin/ffprobe

RUN echo '%sudo ALL=(ALL) NOPASSWD:ALL' >> /etc/sudoers

That is normal container practice for a tool that chowns its data directory at startup, and it is also a container with `sudo`, `gnupg` and `wget` installed and passwordless root available to the service account. Mount your output folder read-only if the gallery does not need to write.

The file permissions default is worth a second look as well. The compose file documents a default umask of 0022, meaning files are readable by other users on the host, with a `UMASK` override present but commented out. On a single-user workstation that is harmless; on a shared server it is the difference between private and public generations.

Client sharing is the feature with the least documentation

The client-facing features are substantial: a sharing portal for curated galleries that keeps workflows, prompts and intellectual property private, per-image comments, star ratings, roles for a team, status tags tracking approval across the library, and an Exhibition Mode filter overlay. There is also a production-studio framing around collection notes and briefs, which are Markdown specifications and checklists attached to virtual albums.

The gap is that the visible documentation does not describe how any of this access is controlled. Whether the client portal has accounts, passwords, expiring links or is simply a filtered view on a port, is not stated in the text available here, and it is the first question to answer before sharing a link outside your own network.

That is the one place where this project is thinner than its feature list suggests, and it is worth contrasting with the parts that are documented in detail: the Queue Deck, clustering, LoRA compatibility and the Docker configuration all have their own manuals linked from the feature table.

The licence is MIT, releases are frequent, and the last push was on 2026-09-17, the same day as version 2.24.1.

Editorial conclusion

SmartGallery DAM suits anyone whose ComfyUI output folder has outgrown manual browsing, especially on Windows where the portable app needs no runtime, and it suits people who keep ComfyUI on a machine that updates underneath them, since the DAM does not live inside it. It does not suit a studio that needs documented access control on the client portal before shipping, because the visible documentation does not describe authentication. Verify first that the image name you pull matches the repository you read, that the ComfyUI server address in the compose file points at your host rather than the placeholder, and that the container's passwordless sudo and default umask are acceptable for a process with your output folder mounted.

Frequently asked questions

Official sources

1. biagiomaf/smart-comfyui-gallery on GitHub
2. License: MIT
3. Project website
4. README
5. Releases