MyIP (jason5ng32/MyIP): a self-hosted IP toolbox that runs on port 18966

What MyIP replaces, and who ends up using it

The everyday problem is that no single page answers "what does the internet think my IP is" with any confidence. One site reports a country, another reports an ASN, a third reports nothing because a proxy is in the way. MyIP's answer is to query multiple independent sources and show the results side by side, so a disagreement between them is visible rather than hidden. The README describes IP Cards as detecting IPv4 and IPv6 "from multiple independent sources side by side" with country, region, city, ASN, organization and the IP's local time zone.

That framing tells you who it is for. It is for someone running a VPN, a proxy or a residential exit node who wants to know whether the exit looks like what they paid for. It is also for people who suspect a browser is leaking an address through WebRTC, or that DNS queries are resolving outside the tunnel. The feature list is unusually broad for one page: connectivity checks against up to 60 sites, a global latency test using Globalping probes, MTR from distributed probes, censorship checks, a DNS resolver comparison, Whois, MAC lookup, subnet math, ASN upstream topology, and a service status panel for Claude, OpenAI, GitHub and Cloudflare.

That breadth is the product. It is not a library you import, and it is not a monitoring agent. It is a browser UI plus a Node backend, self-hosted with the Docker command in the README, with a public demo at ipcheck.ing if you only want to look once.

How the frontend, backend and probe network fit together

The repository layout separates two servers. frontend-server.js serves the built Vite bundle; backend-server.js handles the API calls that need secrets or that would otherwise hit CORS walls. The start script runs both concurrently, and the Dockerfile copies node_modules, dist, both server files, api/ and common/ into a node:24-alpine production stage, exposes 18966 and runs npm start. The build stage enables corepack so pnpm comes from the packageManager field rather than a global install, and it installs a python3/make/g++ toolchain for native dependencies; that toolchain is deliberately absent from the production stage.

Three groups of work happen in three different places. Geolocation and ASN lookups go through the backend to MaxMind and to optional third-party APIs keyed in .env.example (IPinfo, IP2Location, ipapi.is, Google Maps, MAC lookup). Global latency and MTR do not run on your server at all: they are delegated to Globalping probes, which is why the UI can offer countries grouped by continent. The browser does the rest locally, which is the interesting part. WebRTC detection has to run in the page because the leak is a browser behaviour. The IP Calculator is described as computed locally. IP History is stored in your browser only, and the 258-item security checklist saves progress in the browser.

That split has a consequence worth stating plainly. Anything browser-local disappears when you clear site data or switch machines. MyIP is a diagnostic instrument, not a record keeper.

Installing MyIP with Docker and running a first leak check

The README gives a one-line Docker run that starts the container on port 18966. There is no configuration in that command, which means the MaxMind-backed sources will not work until credentials are added.

docker run -d -p 18966:18966 --name myip --restart always jason5ng32/myip:latest

Open http://localhost:18966 and the IP Cards load. Expect the MaxMind source to return 503 at this point: the README states that MaxMind GeoLite2 credentials are required and that without them "the MaxMind source returns 503".

To fix that, register a free MaxMind account and pass the credentials, plus the hostname allowlist, as environment variables. The README marks ALLOWED_DOMAINS as required on a real domain because it is the hostname allowlist for the backend API, and without it every request from a non-localhost domain gets 403.

docker run -d -p 18966:18966 \
  -e MAXMIND_ACCOUNT_ID="YOUR_ACCOUNT_ID" \
  -e MAXMIND_LICENSE_KEY="YOUR_LICENSE_KEY" \
  -e MAXMIND_AUTO_UPDATE="true" \
  -e ALLOWED_DOMAINS="your-domain.com" \
  --name myip --restart always \
  jason5ng32/myip:latest

The docker-compose.yml in the repository is a shorter variant: it declares the same image, the same 18966:18966 port mapping and a restart policy, but carries no environment block, so the same credentials have to be added before the MaxMind source works. Running from source instead means Node.js, then pnpm, then a build:

git clone https://github.com/jason5ng32/MyIP.git
npm install -g pnpm
pnpm install && pnpm run build
pnpm start

package.json pins [email protected] and requires Node 24 or newer, so an older runtime will fail before the build starts. Once the page is up, the first useful test is the DNS Leak Test: it shows which DNS endpoints resolve your queries, which is the check that tells you whether a VPN is actually carrying DNS traffic. Then run WebRTC Detection, which reveals the address exposed during WebRTC connections and whether browser privacy hardening is on. The README also documents a curl API for getting your IP from the terminal, configured through VITE_CURL_IPV4_DOMAIN, VITE_CURL_IPV6_DOMAIN and VITE_CURL_IPV64_DOMAIN in .env.example.

The two settings that break a fresh deployment

Most self-hosted tools fail quietly. MyIP fails loudly in two specific ways, and both are documented.

The first is MaxMind. Geolocation and ASN lookups depend on GeoLite2, and the README states the credentials are required rather than optional. On a deployment without them, one of the IP sources returns 503 while the others keep working, which produces a page that looks functional but is missing a source. If you are comparing sources to detect a mismatch, a missing source is worse than an error page.

The second is ALLOWED_DOMAINS. The backend treats it as a hostname allowlist, and the README warns that without it every request from a non-localhost domain gets 403. This catches people who test on localhost, see everything work, then put the container behind a reverse proxy and find the API dead. The docs link for this is titled "Reverse Proxy & Domains", which suggests the intended deployment is behind a proxy on a real hostname rather than exposed directly.

A third constraint is smaller but real: the shareable report feature depends on Cloudflare Workers KV. According to .env.example, CLOUDFLARE_ACCOUNT_ID and CLOUDFLARE_KV_NAMESPACE_ID must both be set, together with CLOUDFLARE_API_KEY carrying the "Workers KV Storage: Edit" permission, or the share-link feature stays hidden. Nothing breaks, but a feature you may have deployed the tool for simply is not there.

Where MyIP is the wrong tool

MyIP is a browser application. That is not incidental, it is the design, and it rules out some uses.

WebRTC leak detection cannot be scripted from a server, because the leak is a property of the browser making the connection. If you need to verify that a fleet of machines is not leaking, MyIP will not do it from a cron job; you would be driving a headless browser against a UI. The same applies to browser fingerprinting, which is calculated in the page.

State does not persist server-side. IP History is described as stored in your browser only, and the security checklist saves progress in the browser. There is no database in the repository layout, and no history API is documented. If your goal is "show me every IP this machine has been seen with over the last month", MyIP answers a different question.

The third limitation is dependency on third parties for the most distinctive features. Global latency and MTR run on Globalping probes, so their coverage and reliability are not yours to control. Service Status reads official status pages. The optional API keys in .env.example exist because several lookups are delegated to commercial providers. A fully air-gapped deployment would lose a meaningful share of the feature list.

Finally, the security checklist is a content feature, not an assessment. A 258-item checklist across 12 areas with progress saved in the browser is a reminder tool. It does not inspect your machine.

MyIP compared with a commercial IP intelligence API

The closest alternative for the geolocation half of this tool is a commercial IP intelligence API such as IPinfo, which MyIP itself can use as one of its sources through IPINFO_API_KEY. The difference in approach is architectural. An IP intelligence API gives you a JSON endpoint you call from your own code, with a contract, rate limits and a per-request cost, and it returns one vendor's answer. MyIP gives you a page where several vendors' answers sit next to each other, and the disagreement is the signal.

That matters for a specific task: deciding whether a proxy exit is misclassified. One source can be wrong. Two sources disagreeing tells you the address is ambiguous, which is often the actual answer. If you are building an application that needs to geolocate an address at request time, the API is the right tool and MyIP is not; you would be scraping a UI. If you are a person trying to understand why a service treats you as being in the wrong country, the side-by-side view is more useful than a single authoritative-looking field.

The same split applies to network testing. A standalone MTR or ping tool gives you raw output you can paste into a ticket. MyIP runs MTR from distributed probes and renders the route, which is better for a quick read and worse for archival. The README's own framing, "an open-source, all-in-one IP toolbox", is accurate: the value is aggregation, and aggregation is exactly what you do not want when you need a stable machine-readable contract.

Maintenance, licence and what upgrading costs

The repository is not archived, and the last push was on 2026-09-21, the same day as the v7.6.0 release. Two earlier releases, v7.5.0 and v7.4.0, landed on 2026-09-03 and 2026-08-22, so the release cadence over the visible window is roughly every two to three weeks. That is the observable fact; the project does not publish a support policy or a long-term release branch, so there is no documented upgrade path to point at.

The licence is MIT, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is a permissive licence with no copyleft obligation on your own code. It says nothing about the data sources: MaxMind GeoLite2 has its own terms, and the optional providers keyed in .env.example each have theirs. Running MyIP commercially means checking those separately, and this is not legal advice.

The practical upgrade cost is low but not zero. The image is published as jason5ng32/myip:latest, and docker-compose.yml pins the same tag, so a pull can move you across versions without warning; the compose file's comment shows the alternative form, my-app: x.x.x, for pinning a specific version. Node 24 or newer is required by package.json, and the Dockerfile builds on node:24-alpine, so a host that cannot run Node 24 needs the container. Configuration surface is the part that grows: .env.example already covers ports, third-party API keys, MaxMind, CAIDA, security rate limiting, Sentry, and several VITE_ build-time variables that control what ships at all.

Editorial conclusion

Adopt MyIP if you want one self-hosted page that answers what an IP looks like from several vantage points at once, and you are willing to register a free MaxMind account and set ALLOWED_DOMAINS before exposing it. Do not adopt it if you need unattended CLI output or long-term history, since the leak tests are browser-driven and IP history is kept in the browser only. Verify first that the MaxMind source returns data rather than 503 and that requests from your real hostname are not answered with 403.

Frequently asked questions

Official sources

1. jason5ng32/MyIP on GitHub
2. License: MIT
3. Project website
4. README
5. Releases