PhoneInfoga generates leads, not verified identities
PhoneInfoga takes an international phone number and turns it into useful search material. Its local work includes parsing the number and identifying basics such as country, area, carrier, and line type. Scanner integrations then look toward APIs, phone books, search engines, reputation reports, social networks, and disposable-number services. The browser interface and REST API make the same workflow accessible outside a terminal.
The README draws a clear boundary around those results. PhoneInfoga cannot track a handset in real time, return a precise location, hack a phone, or guarantee that a result is relevant and verified. That warning should shape the whole investigation. Numbers get reassigned, public records can be wrong, and a search hit may mention a number without proving who controls it. Treat each result as a lead that needs another source.
What happened when we ran it
Our run cloned commit 041f34a into an unprivileged Go 1.24 Bookworm container with 3 CPUs, 8 GB of RAM, and no secrets. The checkout contained 155 files, about 7,831 lines of source, and occupied 3.5 MB. Installation succeeded in 40 seconds with 229 packages. The build then completed successfully in 13 seconds.
The test command finished with exit code 1 after 42 seconds. Go reported 9 passing packages and 3 failing packages out of 12. The final lines listed successful packages such as lib/remote, web/v2/api, and web/v2/api/handlers, several directories with no test files, and a final FAIL. That tail does not identify the failed assertions or explain their causes, so we will not guess.
PhoneInfoga has 6 CI workflow files, a Dockerfile, and a tests directory. The small 3.5 MB checkout and 13-second build are friendly contributor signals, but the red test result matters. Anyone adopting commit 041f34a should inspect the complete test output and decide whether those 3 package failures touch the scanners or deployment mode they intend to use.
The local scanner is the dependable starting point
A local scan handles number normalization and basic metadata without pretending to identify an owner. That part is useful even when no outside account is configured: an investigator gets consistent international forms and context for further searches. PhoneInfoga then organizes other scanners around the result, reducing the repetitive work of reformatting the same number and preparing queries for different services.
Useful coverage depends on configuration. The README says the collection of scanners must be configured for the tool to be effective. Some outside services need API credentials, impose request quotas, or change what their endpoints return. Search links still require a person to judge whether the result concerns the right number and person. This is investigator assistance, not an automatic evidence pipeline.
Four interfaces do not remove operational duties
PhoneInfoga can be used through its CLI, browser interface, REST API, and Go modules. That range makes it practical for an analyst's workstation or a controlled internal service. The latest tagged release, v2.11.0, added scan options to the REST API and fixed Docker builds, which shows that the API and container paths were intentional parts of the project rather than incidental demos.
Running a shared service creates work the quick start cannot solve. Searched phone numbers are sensitive operational data even when they came from a lawful case. Teams need authentication, network restrictions, secret storage, log retention rules, and an audit trail for who queried what. Scanner options supplied through API calls also deserve filtering so credentials or case details do not leak into ordinary request logs.
Unmaintained status outweighs a recent push
GitHub recorded 17,637 stars, 123 open issues and pull requests combined, and a last push on August 25, 2026. The push date shows repository activity, but the README still says the project is stable and unmaintained, that future bugs will not be fixed, and that the repository may be archived. That explicit statement is stronger evidence about support than a fresh timestamp alone.
The latest release arrived on February 21, 2024. A release age by itself would not prove abandonment, especially with a 2026 push, but the maintainer's own warning settles the question. Phone-number OSINT is a poor category for passive maintenance because search behavior, provider APIs, quotas, and anti-automation rules change outside the repository. A working binary today can lose useful scanners without any change to its local parsing code.
The project is honest about investigative limits
The README's anti-features are among the best parts of PhoneInfoga. It refuses the common sales pitch that a public-data tool can locate a phone or establish an owner's identity. That protects competent users from building a case around suggestive but weak evidence. It also gives teams a useful acceptance rule: every reported identity claim should name the outside source and the separate corroboration used.
The GPL-3.0 license matters for organizations that modify and distribute the software. Legal review should cover that obligation along with the rules governing the investigation itself. PhoneInfoga is software for gathering public clues, not permission to search any person for any purpose. Internal policy should define allowed cases, retention periods, and when an analyst must stop.
PhoneInfoga is still worth keeping in a supervised OSINT toolkit. Our 13-second successful build makes the code easy to trial, while the 3 failing packages and unmaintained notice argue against trusting it unattended. Use a pinned artifact, test only the scanners you need, record each source, and corroborate conclusions. Teams building a maintained identity product should choose supported data providers or own a fork openly.