PhoneInfoga: dork queries and carrier lookups over one phone number

The scanner collection is yours to configure, so a fresh clone returns little

The feature list reads like a capability sheet: check whether a number exists, gather country, line type and carrier, run OSINT footprinting through external APIs, phone books and search engines, then check reputation reports, social media and disposable numbers. The About paragraph is where the catch sits. PhoneInfoga works with a collection of scanners that must be configured in order for the tool to be effective, and it does not automate everything.

Read those two sentences together and the feature list becomes a ceiling rather than a default. Number parsing is the part that works out of the box, because it needs no remote service. The footprinting half depends on third-party endpoints, and a clone with no scanner configured leaves that half empty. Judge the tool on a configured instance, because an unconfigured one understates it, and a configured one can overstate it if the endpoints answer with noise.

Four anti-features: no live tracking, no precise location, no verified data

There is a section headed Anti-features, and it is the most useful paragraph in the README. It states that the tool does not claim to provide relevant or verified data, that it does not allow you to track a phone or its owner in real time, that it does not allow you to get the precise phone location, and that it does not allow you to hack a phone.

The consequence for a reader is concrete. A scan result tells you a country, an area, a carrier, a line type, and whatever the scanners you enabled managed to return. It does not put a person next to a map pin, and it cannot follow a handset around. The About section is equally careful about the last step: it says the techniques try to find the VoIP provider or identify the owner. Try. Nothing in the project promises the owner comes back, which is why every field in a report is a lead to check by hand.

dorkgen builds the search queries, phonenumbers does the parsing

The dependency list in `go.mod` is the closest thing to a description of the mechanism. `github.com/sundowndev/dorkgen` at v1.3.1 generates the search engine queries behind the footprinting feature, and it is the same author's own library. `github.com/nyaruka/phonenumbers` at v1.1.0 and `github.com/onlinecity/go-phone-iso3166` handle the number itself, which is where country, area and line type come from. `github.com/spf13/cobra` at v1.1.3 is the command line, `github.com/fatih/color` and `github.com/sirupsen/logrus` shape the output.

Everything after that is someone else's answer arriving over the network: `google.golang.org/api` at v0.92.0, phone books, search engines, reputation services. So the tool's reach is exactly the reach of those endpoints, and its accuracy is exactly their accuracy. `github.com/joho/godotenv` reads a `.env` file, `github.com/swaggo/swag` generates the API description, and `gopkg.in/h2non/gock.v1` sits in the direct require block as the HTTP mocking library, which is how the test suite avoids calling live services.

gin on port 5000 serves the browser UI, the REST API and nothing else by default

Three surfaces are offered: a graphical interface in the browser, a REST API, and programmatic use through Go modules. `github.com/gin-gonic/gin` at v1.9.1 is the web layer, and the final stage of the Dockerfile makes the port explicit: it copies the compiled binary into alpine:3.18, declares `EXPOSE 5000`, sets `/app/phoneinfoga` as the entrypoint, and leaves the default command as `--help`.

So the port is named, and the default behaviour on that port is nothing at all. A container started with no arguments prints usage and exits rather than serving. Anyone who wants the API has to supply a command the README never spells out.

For Go callers, the module path carries the `/v2` suffix, `github.com/sundowndev/phoneinfoga/v2`, which is a hard requirement of Go's major version rule rather than a naming choice: an import without the suffix will not resolve. The API description the documentation links to is generated output committed at `web/docs/swagger.yaml` on the master branch.

make build, or a Dockerfile that needs Node before it needs Go

There is no install command in the README. It points at the documentation site, the releases page and a Docker Hub namespace, and leaves the rest to you. The repository does carry a Makefile whose `build` target is the real path to a binary, and the version it reports is stamped at link time from two git commands:

go generate ./...
go build -v -ldflags="-s -w -X 'github.com/sundowndev/phoneinfoga/v2/build.Version=${GIT_TAG}' -X 'github.com/sundowndev/phoneinfoga/v2/build.Commit=${GIT_COMMIT}'" -o ./bin/phoneinfoga .

`GIT_TAG` comes from `git describe --abbrev=0 --tags` and `GIT_COMMIT` from `git rev-parse --short HEAD`, so a build from a tarball or a shallow clone without tags reports an empty version. That is a small thing until you are trying to work out which build a report came from.

The container path is longer. Three stages: node:20.9.0-alpine runs `yarn install --immutable` and `yarn build` in `web/client`, golang:1.20.6-alpine runs `make install-tools` then `make build`, and the last stage is alpine:3.18 carrying only the binary.

EXPOSE 5000
ENTRYPOINT ["/app/phoneinfoga"]
CMD ["--help"]

The Makefile's `all` target chains fmt, lint, test, build and `go mod tidy`, and `make install-tools` pulls in gotestsum v1.6.3, mockery v2.38.0, swag v1.16.3 and golangci-lint v1.46.2. Running `make mocks` deletes the `mocks/` directory before regenerating it with `mockery --all`.

Stable but unmaintained: v2.11.0 shipped 2024-02-21, master moved 2026-08-25

The Current status section says the project is stable but unmaintained, that upcoming bugs will not be fixed, and that the repository could be archived at any time. The dates agree with that. The newest release is v2.11.0 from 2024-02-21, before v2.10.8 from 2023-08-17 and v2.10.7 from 2023-06-29, while the last push to master is dated 2026-08-25.

Commits without releases is the shape to plan around. A binary from the releases page is not the same build as a checkout of master, and nothing in the tag history tells you what the newer commits changed. If a scanner depended on an external endpoint that has since changed shape, the project has told you in advance that no fix is coming.

Two small signs of drift sit in the same place. The Go report card badge points at a path ending in `/v2` while the Code Climate badge points at `main`, and the default branch of this repository is `master`. The license is GNU GPL v3.0, and the fingerprint icon credited in the README is separate, licensed CC 3.0 BY.

Where a PhoneInfoga report stops, and what you still have to do by hand

A report ends where the anti-features end: carrier and line type from number parsing, then whatever your configured scanners returned. Identifying the owner is an attempt, not a lookup, and the project states plainly that it does not claim the data is relevant or verified.

Two gaps are worth naming before you build on this. First, the REST API on port 5000 has no authentication described anywhere in the README, so anyone who can reach that port runs the same scanners you configured, with your settings. Do not put it on a public interface without checking that yourself. Second, the repository tree carries a top-level `logs/` directory and an `examples/plugin/` directory, and neither the README nor the Makefile says what writes to the first or what the second is for, so treat plugin support and log handling as undocumented.

On the license, GPL-3.0 obligations follow distribution rather than mere use, which makes running the REST API on your own host a different question from shipping a modified binary. That distinction is worth reading the license text against rather than assuming.

Editorial conclusion

PhoneInfoga fits an investigator who already knows the number, has configured the scanners and treats every field as a lead rather than evidence. It does not fit an expectation of precise location, live tracking or a confirmed owner, since the project lists all three as things it does not do. Verify three things first: that your scanners are configured, because an unconfigured install returns little, that whatever you expose on port 5000 needs access control the README never describes, and that a GPL-3.0 copyleft license is acceptable for how you intend to ship the binary.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes