Start with profile leads
Maigret is worth evaluating when a username is the starting point for an investigation and you need reports you can inspect or process elsewhere. Its documented recursive search can follow identifiers found on profile pages. A matching handle still needs corroboration before you attribute an account to a person.
The README lists 5,900 supported sites. It says a default run checks the 500 highest-ranked sites by traffic; -a selects the full catalog, and tags narrow searches by category or country. Those are documented scope claims, not counts of sites successfully checked in our sandbox. We did not run a measured live-site search.
The README also documents username permutations and keyword highlighting. These can expand or organize leads, but neither proves common account ownership.
Reports and integration
Documented outputs include HTML, PDF, XMind, JSON, NDJSON, CSV and text, plus an interactive graph and a Neo4j Cypher export. The README describes the Neo4j script as idempotent on re-import. We did not generate or import these reports in the recorded run.
For custom workflows, the project documents a Python library built around an asynchronous search function. That gives developers an integration route without requiring them to drive the CLI. It does not establish compatibility with a particular application or deployment environment.
The README says Maigret fetches a newer site database from GitHub once per 24 hours and falls back to its bundled database offline. That fallback supplies site definitions; searches still depend on reaching the target sites. Record the database copy and search options alongside reports when reproducibility matters.
What our recorded run establishes
Our stored run is dated October 2, 2026, at 03:49:42.707 UTC, using commit b6642744988e7e6c2d21f75db60ec3093019ba25. Its recorded configuration was 3 CPUs, 8 GB of memory and image ghcr.io/astral-sh/uv:python3.12-bookworm. The install tail identifies Python 3.12.12 at /work/home/venv.
The harness marked the install step successful in 46.930 seconds, rounded to 47 seconds, and recorded 94 dependencies and 207 MB. It marked the build step successful in 7.737 seconds, rounded to 8 seconds. The supplied record does not include the command text for either step, and the build tail is empty. These are successful recorded steps, not proof that the installed maigret command was invoked or that a search completed.
The test step exited 1 after 24.901 seconds, rounded to 25 seconds. The pytest tail says: "73 failed, 403 passed, 5 skipped, 15 errors in 14.61s". The harness duration and pytest's internal duration describe different timing scopes.
The parser also records a total of 491. We have not reconciled that field with the reported outcome counts or established exhaustive unique test coverage. We therefore do not calculate a pass percentage or describe this as a verified 491-test suite. Skipped cases remain skipped, and the 15 errors are not established as exclusively collection errors.
Many failures listed in the tail report that async def functions are not natively supported. They include checking, executor, self-check and site-submission cases. The tail shows that async test execution was unavailable for those cases; it does not identify why. A missing plugin, a configuration problem or a product defect cannot be assigned from this extract alone.
The repository record includes six CI workflows, a Dockerfile and a tests directory. Those show testing and packaging infrastructure exists. They do not resolve the failed command. No installed-binary check, report-generation workload, search-accuracy measurement, live-site timing or false-positive benchmark is supplied.
The audit result has unknown coverage
The stored pip-audit record reports an advisory total of 0 and a packages field of 0. It supplies no verified scanned-package count. Coverage is unknown, so the result does not establish that the 94 recorded dependencies were checked or that the dependency tree has no known vulnerabilities. It is also not a security assessment of Maigret or its web interface.
Optional features need separate evaluation
The README requires Python 3.10 or newer for the Python installation path. The installation guide documents pip, isolated installation, Docker and other options. Those instructions provide choices; our single run does not validate every method or platform.
PDF output is optional and needs additional system graphics libraries on Linux/macOS. Tor and I2P require their gateways to be running separately. Cloudflare bypass is explicitly experimental and can offload protected checks to FlareSolverr, normally exposed on port 8191. The project warns that the configuration and behavior may change without backward-compatibility guarantees.
Optional AI mode builds an internal Markdown report and sends it to an OpenAI-compatible chat endpoint. The README documents a configurable endpoint, including a local-server option. Before enabling it, decide which endpoint may receive the findings and what data the report contains. Basic username searches do not require this AI mode or an API key.
Hosting requires an access decision
The README documents a local web-interface URL and a Docker web image on port 5000. That is not evidence of a verified network-binding policy in our run.
For its one-click Render deployment, the README explicitly says: "No login is set up on the instance, so anyone with the URL can use it." Add access control before making that deployment available to others. Review access to saved reports too, since the documented exports can contain profile details and linked identifiers. We did not conduct a web security test.
Maintenance evidence and editorial ratings
The supplied v0.6.6 release notes list false-positive fixes, database additions, engine changes and fixes to cookie handling, DNS-resolver behavior and non-UTF-8 output. These are evidence of maintenance work, not a measurement of current detection accuracy. The supplied extracts do not substantiate the earlier dated star totals, issue counts or same-day activity claims, so those figures do not support this review's ratings.
Scores are editorial assessments of the supplied evidence, not benchmark results. The scale is 1 for an evidenced major obstacle, 2 for limited support or unresolved validation, 3 for a usable documented path with material limits, 4 for detailed supporting documentation or broader validation, and 5 for strong corroboration across the assessed area. Unknowns lower confidence; they do not establish poor product quality.
Setup receives 3/5 because recorded install and build steps succeeded, while installed-CLI use and the test environment remain unverified. Documentation receives 4/5 for concrete installation, report, integration and optional-service instructions, although those instructions were not all exercised. Community receives 2/5 because the release notes identify multiple contributors, but adoption and support responsiveness were not measured. Maturity receives 3/5 for release, test and packaging infrastructure alongside unresolved test execution and unmeasured search behavior.
A useful next check
For an evaluation, start with the documented default search scope and a username whose expected accounts you can independently verify. Check that the installed command runs, inspect its reports and investigate unexpected matches before broadening the search with -a. Reproduce the project's documented development test setup and resolve the async-support errors separately. These are recommended next steps, not tests completed for this review.