Practical research · explicit evidence

ComfyUI ecosystem research: a source map and reproducible repository snapshot

ComfyUI is a collection of related software layers, models and workflows. This report maps four maintained core projects and publishes the source data behind its repository snapshot. It does not infer active users or market revenue from GitHub activity.

Published 2025-08-31 ·

Four layers to keep distinct

LayerPrimary projectPractical question
Execution engineComfyUIWhich application revision executes the graph, and which model/runtime dependencies does it require?
Browser interfaceComfyUI frontendWhich interface version loads and edits the workflow? Interface and execution failures may have different causes.
Extension managementComfyUI ManagerWhich optional extensions are installed, who maintains them, and which revisions were tested?
Workflow templatesWorkflow templatesWhat is the starting graph, and what additional model files or credentials are needed to run it?

A saved graph is a useful starting artifact. It is not a complete environment, a model licence, or proof of a successful run on another machine. Keep those pieces together when handing a workflow to someone else.

Dated repository snapshot

Observed through GitHub’s public repository API on 16 September 2026 at approximately 03:00 UTC. These are four deliberately selected projects, not a census of all ComfyUI extensions.

RepositoryStarsForksArchived
Comfy-Org/ComfyUI133,41315,783No
Comfy-Org/ComfyUI_frontend2,013699No
Comfy-Org/ComfyUI-Manager16,1512,481No
Comfy-Org/workflow_templates904188No

Download the source dataset (JSON)

Each row includes the API URL, observation timestamp, default branch, last-push timestamp and licence identifier reported by GitHub. Counts change after collection. A star is not a verified user; a fork is not an active installation. Do not add the rows together to estimate an audience.

Reproduce the observation

Request each row’s source URL through GitHub’s REST API and preserve the returned metadata with a new UTC timestamp. Record redirects to the maintained owner rather than silently combining repositories with similar names. Compare like-for-like fields and keep both dates. The download contains the original observation used in this table.

The selection covers the execution engine, interface, manager and templates because they are useful layers for evaluating a deployment. It excludes model-hosting download totals, private installations, commercial-provider revenue and community membership. Those measures have different populations and cannot be merged into a unique-user count without a separate study.

What the evidence supports

The source map establishes where to inspect and track each selected component. The snapshot provides public activity indicators at one time. Neither proves workload compatibility, software quality, user satisfaction or a future growth rate. A vendor comparison needs a defined task and an execution record, not a larger star count.

A practical evaluation for your own team

  1. Choose one deliverable, such as a fixed image-generation graph with an agreed visual acceptance rule.
  2. Record the core and interface versions, graph hash, exact model hashes, extension revisions and relevant licences.
  3. Run from a clean start and preserve the log, output and failures. Measure setup effort separately from repeat execution.
  4. Identify any remote service used by the graph. A local interface does not guarantee local-only processing.
  5. Change one dependency at a time when comparing routes, then record whether the same deliverable still passes.

For memory and timing, use the RTX diagnostic procedure and benchmark methodology. For workflow provenance, see the workflow library and trust levels.

Further primary documentation

The four repository links above and their API addresses in the downloadable dataset are the sources for this snapshot.