Web-Check: a self-hosted OSINT dashboard for any website

What Web-Check actually collects about a domain

Point Web-Check at a hostname and it returns a dashboard of independent checks rather than a single score. The README lists what the dashboard shows today: IP info, SSL chain, DNS records, cookies, headers, domain info, search crawl rules, page map, server location, redirect ledger, open ports, traceroute, DNS security extensions, site performance, trackers, associated hostnames and carbon footprint. The stated aim is to help you understand, optimize and secure your own website, which frames the intended user as a site owner or administrator rather than an outside attacker. The README also notes that the feature list needs updating and that many more jobs have been added since, so treat the list as a floor and read the api/ directory for the current set. The audience is sysadmins, security reviewers and anyone doing due diligence on infrastructure they control or have permission to probe.

How the checks are wired: Astro frontend, Express API, Chromium worker

The repository splits into a frontend and a backend that can run as separate processes. The package.json scripts show the split directly: dev:api starts the server with DISABLE_GUI set to true on port 3001, and dev:astro points the frontend at http://localhost:3001/api through PUBLIC_API_ENDPOINT. The yarn dev script runs both concurrently. On the server side, server.js sits next to an api/ directory and a healthcheck.js, and the Dockerfile installs chromium and traceroute in the final image, then sets CHROME_PATH to /usr/bin/chromium so browser-driven checks use the system binary instead of Puppeteer's bundled download. That tells you where the heavy work happens: page rendering, cookie and header collection and similar checks depend on a real browser being present at runtime. The Express layer carries express-rate-limit and a configurable CORS origin, and the .env.sample exposes API_ENABLED_CHECKS and API_DISABLED_CHECKS for narrowing the job set, plus API_BLOCKED_HOSTS for refusing targets outright. Each check is a separate job with its own external dependency, which is why a missing API key degrades one panel instead of breaking the page.

Installing Web-Check with Docker and running a first lookup

The repository ships a docker-compose.yml that references the published image lissy93/web-check and maps port 3000. The README lists Docker as deployment option three, alongside Netlify, Vercel, Render and building from source. Start the container with the compose file as written:

version: '3.9'
services:
  web-check:
    container_name: Web-Check
    image: lissy93/web-check
    ports:
      - 3000:3000
    restart: unless-stopped

After the image pulls, the service answers on port 3000. The Dockerfile declares EXPOSE 3000 and installs tini as the init process, so the container shuts down cleanly. If you want to run only the API and skip the GUI, the package.json script does that with DISABLE_GUI set to true and PORT set to 3001:

DISABLE_GUI='true' PORT='3001' node server

For a source checkout, the engines field requires Node.js 22.12.0 or newer, and the scripts expect yarn: run yarn install, then yarn dev to bring up the API and the Astro frontend together. Configuration lives in a .env file modelled on .env.sample. The sample marks everything as optional but warns that some features will not work without external API access, and it lists keys for Google Cloud, Shodan, SecurityTrails, Cloudmersive, URLScan, Tranco, WHOIS and a GitHub token. Copy the sample, uncomment only the lines you populate, and set API_BLOCKED_HOSTS before exposing the instance to anyone else.

Where Web-Check stops: no verdict, thin docs, key-gated panels

Web-Check is the wrong tool if you want a yes-or-no answer about whether a site is safe. Nothing in the README promises a reputation score or a malware verdict; it describes insight into a site's inner workings. The related searches show people asking whether a site is safe, and that expectation does not match what the dashboard produces. A second limit is dependency gating. The .env.sample states plainly that some features will not work without external API access, so a default install leaves panels empty or erroring until you supply keys. Third, the browser dependency is real: without a working Chromium at CHROME_PATH, the checks that render pages will fail, which is why the Dockerfile installs it explicitly and the build even imports the compiled server entry to catch a broken runtime tree early. Fourth, scanning third-party hosts from a public instance raises both legal and operational questions, and the project's own API_BLOCKED_HOSTS setting exists because operators need to refuse ranges. Finally, the README admits the feature list is out of date, so documentation lags the code and you should read api/ to know what a given version runs.

Web-Check versus a vulnerability scanner such as Nuclei

The closest mental model for comparison is a template-driven scanner like Nuclei, and the difference is the question each one answers. Nuclei sends requests built from community templates and reports matches, so its output is a list of suspected findings tied to specific template IDs, and its value scales with the template set you maintain. Web-Check instead assembles descriptive facts about a host: who issues the certificate, which names resolve, what headers come back, which trackers load, what ports answer. There is no template language and no finding severity. That makes Web-Check better as a first pass before you decide what to test, and worse as evidence of a vulnerability. The two are complementary rather than competing: use Web-Check to map the surface, then point a template scanner at the parts that matter. If you need active exploitation checks or a CI gate that fails a build, Web-Check will not provide either.

Licence, maintenance and the real upgrade cost

The project is MIT licensed, which permits commercial and private use, modification and redistribution provided the copyright notice and permission notice are retained. That is the extent of what the repository states; questions about your own compliance obligations belong with your legal team, not with a README. Maintenance signals are mixed. The last push was on 2026-09-10, and the most recent release listed is 2.2.0 from 2026-07-28, with 2.1.0 before it in May 2026, so the codebase is moving. The upgrade cost is not the version bump itself but the runtime you carry: the Dockerfile pins Node 22 on Debian bookworm, installs Chromium and traceroute into the final image, and the package.json engines field requires Node.js 22.12.0 or higher. Pulling a new image means re-pulling a browser and re-running that dependency chain. If you deploy on a serverless platform instead, the .env.sample and the Netlify, Vercel and Render options in the README exist for that path, but the platform's limits on long-running browser jobs and outbound traceroute will decide which checks survive.

Editorial conclusion

Adopt Web-Check if you need a self-hosted, MIT-licensed reconnaissance dashboard for domains you own or are authorised to assess, and you are willing to run Chromium and traceroute in the container. Do not adopt it as a malware or phishing verdict engine: the README describes it as an insight tool, not a scanner that returns a safe or unsafe label, and several checks stay dark without third-party API keys. Before trusting a deployment, verify that CHROME_PATH points at a real Chromium binary, that API_BLOCKED_HOSTS covers your internal ranges, and that the checks you care about return data rather than an error.

Frequently asked questions

Official sources

1. License: MIT
2. lissy93/web-check on GitHub
3. Project website
4. README
5. Releases