Web Check

Last reviewed Sep 13, 2026 · 811 words

Web Check runs about two dozen of its checks with no configuration at all and quietly skips the rest until you hand it API keys. That single fact explains most of the confusion in the issue tracker: people deploy the container, type in a domain, and assume the blank panels mean something is broken. Nothing is broken. The DNS, SSL, header, cookie, redirect, tech-stack, robots.txt, sitemap and port-scan panels come from the app itself; the quality scores, threat lookups and traffic rank come from third-party services that want a key.

What you get with an empty environment

The zero-key report is already the useful part. Point it at a domain and within 10 to 20 seconds you get the full DNS record set including DNSSEC status, the certificate chain and expiry, every response header with the security-relevant ones graded, the HSTS policy, cookies with their flags, the redirect chain, a Wappalyzer-style technology fingerprint, crawl rules, the TXT records that reveal which SaaS the owner uses, and a scan of the common ports. That last one deserves a sentence of etiquette: the port scan originates from your server, so only run it against hosts you own or have permission to probe. A VPS provider will not care about one scan of your own domain. They will care about a script that loops over someone else's range.

The keys that are actually worth adding

Five environment variables cover the panels most people miss. GOOGLE_CLOUD_API_KEY drives the Lighthouse quality audit and Safe Browsing check. SHODAN_API_KEY fills the Shodan exposure panel. WHO_API_KEY gives cleaner WHOIS data than the fallback. TRANCO_USERNAME and TRANCO_API_KEY add the traffic rank. All of them have free tiers that comfortably cover a homelab's usage. I would add the Google key first because Lighthouse is the panel people show to other people, and skip Shodan unless you already have an account.

Deployment is one line, and 64 MB is honest

The image is lissy93/web-check and it listens on port 3000:

services:
  web-check:
    image: lissy93/web-check:latest
    ports:
      - "3000:3000"
    environment:
      - GOOGLE_CLOUD_API_KEY=your-key
    restart: unless-stopped

The 64 MB minimum is real for the idle process. A report against a heavy site briefly spikes higher because several checks run in parallel and Lighthouse is not light, but on a 1 GB box you will not notice. Put it behind your usual reverse proxy with authentication if it faces the internet; the app has no login of its own and an open instance is a free scanning service for strangers. There is a hosted demo at web-check.xyz, but running your own removes the rate limits and keeps your list of scanned domains off someone else's logs.

Maintenance has slowed, and that is fine for this tool

The project comes from the same author as Dashy, and it shows the same pattern: a burst of feature work, then a long tail of small fixes while the author's attention moves on. Commits have thinned since the initial surge. For a monitoring daemon that would worry me. For a stateless request-and-render tool it barely matters, because the checks depend on stable protocols (DNS, TLS, HTTP) rather than on a moving upstream API. The panels that could rot are the third-party ones, and those degrade to a blank card rather than taking the app down. At 34,669 stars and MIT licensed, a fork would appear within weeks if it were ever abandoned.

What it is not

Web Check is a point-in-time inspector, not a monitor. It does not poll, alert, or keep history. If what you actually want is "tell me when my certificate expires" or "tell me when the site goes down", that job belongs to Uptime Kuma or one of the other tools in the dashboards category. Where Web Check earns its place is the 5 minutes after you deploy something: you point it at the new domain, read the header grades, notice the missing Content-Security-Policy, spot the mail records you forgot, and fix them before anyone else finds them. I also use it when evaluating a vendor: the TXT records and tech stack tell you a surprising amount about how a company runs its infrastructure.

What I'd do

Deploy it in Docker on whatever box already runs your dashboard, add the Google key, and leave the rest empty. Put it behind the reverse proxy with basic auth so only you can trigger scans. Then make it a habit: every new subdomain you expose gets a Web Check pass before you share the link. For continuous checks, pair it with Uptime Kuma rather than expecting Web Check to grow into one. It is a good tool precisely because it stayed small.