MyIP - Moses Yebei

Abstract

The best IP Toolbox. Check your IP address & geolocation, test IP for WebRTC and DNS IP leaks, run an IP quality check, browser fingerprint check, website availability check, network speed test, global latency test, MTR test, Whois search, and more.

The Problem

Users behind VPNs, proxies, or restrictive networks need to verify what the outside world actually sees: their public IP, whether DNS or WebRTC leaks expose their real location, and whether their proxy rules route traffic correctly. Manually checking each of these across multiple services is slow and error-prone.

What This Does

MyIP is a self-hosted IP diagnostics toolbox. It detects local and public IPv4/IPv6 addresses, runs WebRTC and DNS leak tests, checks website availability, measures global latency, performs MTR and Whois lookups, and tests browser fingerprints. The frontend/ directory contains the Vue 3 interface with nearly all features as standalone components, while api/ and common/ hold the server-side handlers and shared utilities.

The project is a fork of jason5ng32/MyIP with 11,729 stars. It ships with Docker support, GitHub Actions CI, and a test suite of 60 files.

How It Is Wired

Execution starts at frontend/main (the Vue entry point), which imports the app shell and routes to feature components like frontend/components/Advanced.vue and frontend/components/SpeedTest.vue. These components call API endpoints defined in api/ — for example, api/dns-leak-test.js and api/get-whois.js — which run server-side in backend-server.js. That server also mounts the frontend static build.

The two hub modules with the widest blast radius are common/logger.js (imported by 26 modules) and common/fetch-with-timeout.js (imported by 19). A change to either ripples across nearly every API handler. The import graph shows 192 internal modules and 233 edges with zero circular dependencies — clean structure, but the frontend/store module sits at instability 0.67 (imports 8, imported by 4), meaning it's both a dependency and a dependent, making it awkward to refactor.

The frontend is a PWA with dark mode and keyboard shortcuts, and the backend handles rate limiting, referer checks, and report generation via common/report-schema.js.

How To Use It

Setup — pnpm is the package manager. Install and start the dev server:

pnpm install
pnpm dev

Configuration — Copy .env.example to .env and set any required API keys or service endpoints. The Dockerfile and docker-compose.yml are present for containerized deployment.

Running it — For production, build the frontend and start the backend:

pnpm build
pnpm start

The backend-server.js serves both the API and the built frontend. Docker deployment is supported via docker-compose.yml.

Real-World Use

Deploy this behind a reverse proxy on a VPS to give your team a self-hosted diagnostics page. Users on VPNs can visit it to confirm their egress IP, check for DNS leaks, and verify proxy rules — without sending that data to a third-party service. The shareable report feature (api/share-report.js) lets users export results for support tickets.

Code Health & Issues

Static analysis found 66 issues: 24 high, 42 medium. The top findings:

High — Deep nesting (38 occurrences) in common/logger.js, frontend/components/Achievements.vue, and frontend/components/Advanced.vue. Max indentation depth of 8 makes control flow hard to follow.
High — Hub modules: common/logger.js and common/fetch-with-timeout.js each have 26 and 19 dependents respectively; changes have high blast radius.
High — Duplicated code blocks: 115 repeated 6-line blocks across 75 files, notably in api/get-user-info.js and common/maxmind-updater.js.
High — Oversized file: frontend/data/speedtest-colos.js at 1,323 lines.

Additional findings: third-party GitHub Actions are pinned to tags (@v4) not commit SHAs, no Dependabot configured, the Docker base image node:24-alpine is unpinned by digest, and the container runs as root. These are all medium-severity supply-chain and hardening issues.

The Bottom Line

This is a well-structured, feature-complete IP toolbox with clean module boundaries and no circular dependencies. The main maintenance risks are the duplicated logic and the oversized speedtest data file, plus the supply-chain hardening gaps. It's a solid choice for anyone who wants a self-hosted, privacy-respecting IP diagnostics suite.

What the analyser found

Deployment readiness

7/7

Container image
CI pipeline
Lockfile committed
Test suite
README
License
No committed secrets

Composition

417 files

JavaScript191
Vue137
JSON16
Markdown14
YAML8
CSS1

ReactVueExpressDocker

Architecture

Top-level areas of the codebase, sized by module count. Arrows show how many imports cross from one area into another.

graph TD g0["frontend 99 modules"] g1["tests 43 modules"] g2["api 23 modules"] g3["common 22 modules"] g4["(root) 5 modules"] g2 -->|44| g3 g1 -->|30| g0 g4 -->|23| g2 g1 -->|15| g2 g1 -->|13| g3 g4 -->|8| g3 g0 -->|5| g3 g4 -->|1| g0

Module dependencies

The 10 most depended-upon modules of 192, from static import analysis. Red outline marks a module in an import cycle.

graph LR n0_common_logger["logger"] n1_common_fetch_with_timeout["fetch-with-timeout"] n2_end_utils_fetch_with_timeout["fetch-with-timeout"] n3_common_valid_ip["valid-ip"] n4_common_report_schema["report-schema"] n5_common_geo_handler["geo-handler"] n6_frontend_utils_app_events["app-events"] n7_frontend_store["store"] n8_common_bgp_prefix["bgp-prefix"] n9_common_maxmind_service["maxmind-service"] n8_common_bgp_prefix --> n3_common_valid_ip n5_common_geo_handler --> n1_common_fetch_with_timeout n5_common_geo_handler --> n0_common_logger n9_common_maxmind_service --> n0_common_logger n4_common_report_schema --> n3_common_valid_ip n7_frontend_store --> n2_end_utils_fetch_with_timeout n2_end_utils_fetch_with_timeout --> n1_common_fetch_with_timeout

Dependencies

2 of 51 declared dependencies are a major version behind. Resolved 51 of 51 against the registry.

Package	Declared	Latest	Behind
`@tanstack/vue-table`	^8.21.3	9.1.2	1 major
`whoiser`	^1.18.0	2.0.0-beta.10	1 major

What would stop me shipping this

Ranked by severity × confidence × production reach. Reach is the honest discriminator across a collection that is mostly other people's code: the same finding matters more in something that ships.

high1

medium5

low2

Pin third-party GitHub Actions to a commit SHAhigh6 occurrences

.github/workflows

pnpm/action-setup@v4, docker/setup-buildx-action@v4, docker/login-action@v4, docker/build-push-action@v7

A tag can be moved, so the action running with your token and secrets is whatever its owner last pushed; this is how tj-actions/changed-files leaked secrets from thousands of repos.

Fix: Replace each @vN with the 40-character commit SHA, keep # vN as a comment, and let Dependabot bump the SHAs.

Enable Dependabot or Renovatemedium

1 manifest(s), no update bot configured

Without a bot a published advisory sits unpatched until someone audits by hand, which across 1,322 repositories means never.

Fix: Commit .github/dependabot.yml covering the repo ecosystems plus github-actions.

Pin the container base image by digestmedium2 occurrences

Dockerfile

node:24-alpine, node:24-alpine

An untagged or mutable base means today's build and last month's contain different libc and a different CVE set, with no record of which shipped.

Fix: Use image:tag@sha256:<digest> and enable Dependabot's docker ecosystem.

Gate pull requests on a dependency vulnerability scanmedium

.github/workflows

no dependency scan in CI

This is the one gate that would catch a known-vulnerable package before it reaches a build, and no repository in the sample had it.

Fix: Add dependency-review-action on pull_request, or osv-scanner on push and a schedule.

Set persist-credentials: false on checkoutmedium

.github/workflows/ci.yml

checkout keeps the token, then dependencies are installed

The token stays in .git/config for every later step, so a malicious postinstall script reads a pushable credential without one ever being passed to it.

Fix: Add with: persist-credentials: false, and pass an explicit token only to the step that pushes.

Add a non-root USER to the imagemedium

Dockerfile

CMD or ENTRYPOINT with no USER directive

A process running as root in the container is root against every mounted volume, and it turns any container escape or writable-mount mistake from a contained problem into a host one.

Fix: Create an unprivileged user, chown what it needs, and end the Dockerfile with USER.

Set timeout-minutes on the workflow jobslow4 occurrences

.github/workflows/ci.yml

4 workflow(s) declare no job timeout

A wedged step runs to the six-hour platform default, which on a two-hourly schedule means three runs overlap behind it.

Fix: Add timeout-minutes with a realistic bound to each job.

Add the repository convention files this project lackslow3 occurrences

missing .editorconfig, .gitattributes, a formatter config

Without them one contributor's editor writes tabs into a Python file, a shell script commits with CRLF and fails in the container, and a notebook diff is unreviewable.

Fix: Add .editorconfig, .gitattributes with text=auto eol=lf, and a formatter config.

Checked deterministically against the repository tree and a bounded set of its files: committed credentials, unpinned actions and base images, missing lockfiles and update bots, workflows that discard failures, published advisories against the declared dependencies, runtime configuration, licensing and notebook reproducibility. No language model is involved in this section.