The checked tree contains 2,061 workflow files, not 4,343
The README describes a collection of 4,343 production-ready workflows with a 100% import-success rate. GitHub's tree for commit 94007c1 contains 2,061 JSON files under workflows/. That does not make the smaller collection useless, but it changes how its claims should be read. This is a broad pile of automation examples with a convenient index, not a verified catalog whose headline count matches the checked source.
Our checkout contained 2,178 files, about 10,761 lines of source, and 41.9 MB. Most of the value is data rather than Python application code: each workflow JSON describes nodes, parameters, connections, and metadata for later import into n8n. The repository adds a browser interface and API over that material. It never becomes the automation runtime itself, so you still need n8n and every account, token, database, or webhook used by a selected example.
A 2-second build makes the catalog easy to browse
The included server indexes workflow metadata into SQLite and FTS5, then exposes search, category, statistics, workflow-detail, and export routes through FastAPI. Search can filter by trigger and complexity, while the static interface provides a friendlier path through thousands of filenames. This layer is useful when GitHub directory browsing becomes tedious. It tells you what may be relevant; it cannot prove that the underlying graph imports or performs the advertised job.
Our sandbox installed 61 packages in 17 seconds, used 76 MB, and completed its build in 2 seconds. Those numbers make local catalog browsing cheap compared with running a full automation stack. The Dockerfile uses a non-root user and includes a health check, and compose can add Traefik. Issue 159 reports that pulling the exact Docker Hub image shown in the README returned access denied, so building the supplied Dockerfile is the safer documented fallback to verify.
What happened when we ran it
Our Python 3.12 Debian container used 3 CPUs and 8 GB of RAM with no secrets. Installation and the 2-second build both succeeded. The repository had a Dockerfile, a compose file, and 5 CI workflow files. Nothing in those results exercised an n8n import, authenticated to an integration, or ran an automation. They establish that the catalog application can be prepared, not that its workflow contents are correct.
There was no test script or target, so the harness skipped tests. The checkout also had no tests directory. Pip-audit found 32 known vulnerabilities in the installed environment; the supplied result does not list severities or establish whether a particular advisory is reachable through this server. It does contradict the README's dated statement that all CVEs were resolved. Pinning a deployment to this commit still requires reviewing and updating the affected dependency set.
Issue 200 finds placeholder nodes in the same checked commit
Issue 200 reports that many AI-labeled nodes use n8n-nodes-base.noOp instead of LangChain node types and that many connection targets point to absent node IDs. The reporter pinned the analysis to commit 94007c1, the same commit our lab received. In the issue's named MongoDB Agent example, the checked JSON contains noOp entries for its OpenAI model, memory, chat trigger, tool, and agent. That workflow should not be imported with an assumption that its labels describe executable nodes.
Our 2,061-file tree is too large for sensible line-by-line trust. Review a candidate as code: confirm every node type exists in your n8n version, trace each connection, inspect Code and HTTP Request nodes, replace credential references, and check where data leaves the system. Issue 189 raises another basic gap, the collection does not state the n8n version for each workflow. An import can succeed syntactically while losing or changing behavior across node versions.
The 76 MB search service should stay separate from production n8n
Run the catalog as a read-only reference service, preferably away from the n8n instance that holds production credentials. Its search API does not need those secrets. Download one workflow at a time, put it in a disposable n8n environment, and compare the visual graph with the raw JSON. Trigger it only with test accounts and synthetic data. This separation limits what a malformed, stale, or unexpectedly destructive example can reach during evaluation.
The 32 audit findings also argue against exposing the FastAPI container without normal controls. Bind locally when remote access is unnecessary. For a shared service, update dependencies, put authentication and TLS at the edge, restrict origins, and retain container logs. The compose profile includes a Traefik dashboard configured as insecure in the checked file, so operators should not publish that dashboard unchanged. None of these steps repairs a workflow with missing nodes; server hardening and content validation are separate jobs.
June code and September reports show attention without resolution
The repository was last pushed on June 24, 2026. GitHub showed 56,512 stars and 41 combined issues and pull requests, while issue 200 arrived on September 4 with no reply when fetched. That is recent user activity alongside a codebase that had not yet addressed the report. The open queue also contains many empty or off-topic submissions, so its raw size says little about maintainer capacity or defect volume.
The latest release is an August 2025 history-rewrite notice rather than a normal software release. It says 8 files were removed for DMCA compliance and instructs existing users to re-clone or force-sync. A fresh checkout avoids that history problem, but it does not settle provenance or correctness for every remaining example. The collection is worthwhile for discovery. With no tests, 32 audit findings, absent per-workflow n8n versions, and a concrete integrity report, production use begins only after your own reconstruction and review.

