A local graph for investigations, not another lookup page
Flowsint treats an investigation as a web of entities, not a sequence of isolated searches. You add domains, IP addresses, ASNs, websites, emails, phone numbers, people, organizations, wallets, or social identities, then use enrichers to expose relationships on a graph. Its 8,149 GitHub stars show unusual attention for a young security utility. Findings that otherwise live across terminal output, browser tabs, and notes remain connected in one case-oriented interface.
The project is explicit about its boundaries. It describes itself as an ethical OSINT tool and points users to a dedicated ethics policy. Release v1.2.12 arrived on August 26, 2026, while the repository was pushed again on September 6, only 8 days before this review. Code activity is recent and the project is cutting versions, although the README still calls development early.
The graph and enrichers cover real investigative paths
Its strongest feature is the breadth of transitions between entity types. Domain enrichers cover DNS, reverse DNS, subdomains, WHOIS, history, ASN ownership, and conversion into website or root-domain entities. Website tools can crawl pages, extract links and text, identify trackers, and turn URLs back into domains. Other paths span organizations, people, breach lookups, social username discovery through Maigret, wallet transactions, NFTs, IP geography, and CIDR enumeration. This is a graph tied to actions that can advance an investigation.
The architecture is divided into 5 core layers. The frontend calls a FastAPI service, which delegates orchestration, tasks, and vault functions through the core, then reaches enrichers and shared Pydantic types. PostgreSQL, Redis, and Neo4j each have an apparent role, while the N8n connector accommodates custom workflows.
Privacy is treated as a deployment property. The README says investigation data stays on the operator's machine, and its production Compose design exposes only port 5173 while PostgreSQL, Redis, Neo4j, and the API bind to localhost. For network use, operators must replace 3 secrets, add the host to an allowlist, use a reverse proxy, and bind the app to 127.0.0.1.
What happened when we ran it
Our run used commit 1820569 in a fresh, unprivileged Debian container with 3 CPUs, 8 GB of RAM, Node 22, and no secrets. The Yarn install succeeded in 127 seconds, adding 1,246 packages and occupying 765 MB. That proves the dependency graph resolved on our box, but not that the full Compose application or every enricher works.
The repository contained 878 files, about 88,485 lines of source, and a 7.9 MB checkout. We found 4 CI workflow files, a Compose file, monorepo workspaces, no Dockerfile, and no tests directory. There was no build script or target, so the build check was skipped. There was also no test script or target, so no tests ran. These are missing verification surfaces, not failures, but a successful install is not a validated application.
This explains the gap between the quick start and our evidence. The README's Unix path is make prod; Windows users copy 4 environment files and start a production Compose file that pulls prebuilt images. Our measurement exercised the Node/Yarn repository path, not those services. Teams evaluating source changes still need to identify how each workspace is built and tested.
The rough edges are mostly about confidence and operations
Flowsint's early-development warning should be taken literally. There are 50 open issues, enough to check for blockers affecting your enrichers and deployment mode. Still, an 8-day-old push and a v1.2.12 release only 19 days old argue against calling it stale. The supplied evidence does not show response time, closure rate, or support quality, so stars and commits are encouraging signals, not a guarantee.
Operating the full product is more involved than the first 3 setup commands suggest. A team deployment needs secret rotation, HTTPS termination, hostname allowlisting, database persistence, upgrades, and backups. Some enrichers will depend on external services or credentials. The README addresses immediate exposure risks well, but this remains a multi-database security tool.
The documentation is strongest on exact Compose commands, Windows environment copying, port behavior, reverse-proxy configuration, and the module map. It is weaker as proof of engineering readiness because our 2026-09-14 checkout offered no common root build or test target. Four CI workflows indicate automation exists, but their presence alone cannot establish coverage.
It belongs in an investigator's private workspace
Flowsint fits best as the interactive layer after collection begins. Feed it a domain, address, organization, or identity, expand connections with selected enrichers, and preserve the graph for review. It can complement command-line discovery and N8n automation. For a technically capable small team, keeping the app behind 1 HTTPS endpoint while data services remain local is a sensible shape.
It is less convincing as an unattended production dependency or organization-wide intelligence system. OpenCTI better suits structured intelligence sharing; SpiderFoot favors automated collection breadth; OWASP Amass focuses on repeatable attack-surface discovery. Flowsint earns a pilot because its graph workflow, local storage stance, and v1.2.12 activity align well. It has not earned blind trust, because our only completed gate was a 127-second dependency install.