Web-Check: What lissy93/web-check Actually Reports About a Site, and Where It Stops

The problem Web-Check solves is assembly, not discovery

Most of what Web-Check shows you is already obtainable. An A record comes from a DNS query. A certificate chain comes from opening a TLS connection. Headers come from one HTTP request. The README points to web-check.xyz/about for the full list of checks and what each one does. Each of those has a dedicated tool that does it better. The value here is that you type one hostname and get the results in one view, without writing the glue yourself.

That framing matters because it sets the correct expectation. Web-Check is a convenience layer over external data sources and network probes. The README describes the aim as helping you "easily understand, optimize and secure your website", which is a statement about the person doing the looking, not about the depth of any single result. The audience is sysadmins, security people doing triage, and developers who want to know what a site is actually serving before they touch it. The hosted instance at web-check.xyz exists for a quick look; the repository exists for people who would rather not send a target list through a third party.

One hostname in, a fixed set of jobs out

The repository is an Astro application: astro.config.mjs and svelte.config.js sit at the top level, package.json depends on @astrojs/react, and a server.js started by `yarn start` serves the API and the GUI from the api/ and src/ directories. The README points to web-check.xyz/about for the list of checks.

This is why the tool behaves the way it does. Results are computed on demand when you load a target, not stored and diffed over time. You get a snapshot. If you want to know whether a certificate changed since last week, Web-Check will not tell you; you would have to run it twice and compare the output yourself.

The second consequence is that a meaningful share of the panels depend on third-party APIs. The README's configuration section lists optional keys for Google PageSpeed Insights and Safe Browsing, Shodan, Cloudmersive and Tranco, which unlock additional checks or raise rate limits. When one of those upstreams rate-limits you, changes its response shape, or requires a key you have not set, the panel that depends on it degrades while the rest of the dashboard keeps working. That is a design trade-off, not a bug, but it means a partial result set is a normal state rather than an error condition.

Deploying it: Docker, source, and the platform options

The README documents six deployment paths. Four are managed platforms: Netlify, Vercel, Hostinger, and Render. One is Docker. One is from source.

Docker is the path most teams will want, and the repository ships a GitHub Actions workflow that builds and publishes an image. The README gives `docker run -p 3000:3000 lissy93/web-check`, then open localhost:3000. The image is on DockerHub as lissy93/web-check and on GHCR as ghcr.io/lissy93/web-check, or you can build it with `docker build -t web-check .` after cloning the repo.

Deploying from source means installing the prerequisites in the Developing section, then running git clone, cd web-check, yarn install, yarn build and yarn start. The README's Configuring section says no configuration is needed by default, and optional environment variables enable extra checks or raise rate limits. In .env.sample, API_DISABLED_CHECKS disables the listed checks, API_ENABLED_CHECKS restricts the run to the listed checks, and API_BLOCKED_HOSTS lists hosts that must never be scanned. If you are running Web-Check on a host that should not be making arbitrary outbound requests, or you are behind a policy about which third-party endpoints your infrastructure talks to, those are the settings to review.

A practical note on the hosted demo. The README lists both web-check.as93.net and web-check.xyz as live instances, and a Codeberg mirror of the source. Using the hosted version means your target list passes through someone else's deployment and, by extension, through whatever upstream APIs that deployment calls. For a one-off look at your own domain that is fine. For anything else, self-hosting is the point of the project.

The open ports panel is where expectations need adjusting

Open ports (the sample config lists `ports` among the checks) is the check most likely to be misread. An open port check from a single vantage point tells you what one machine, on one network path, could reach at the moment the job ran. A filtered port and a closed port can look similar from outside. A service that only accepts connections from certain source networks will appear closed to your instance and open to someone else's.

If port state is the question you are actually asking, a dedicated scanner run from a host you control, with a defined port list and a defined timing profile, answers it more honestly. Web-Check's panel is useful as a hint inside a broader picture. Neither is evidence on its own, and the README does not present them as such. A single load measurement from wherever your instance happens to be running is a data point about that path, not about the site's general responsiveness. Treat it as a smoke test.

What it does not do, and what to reach for instead

Web-Check has no notion of a scan target list, no scheduling, and no diffing between runs. If your need is continuous monitoring of certificate expiry across a fleet of domains, a tool built around scheduled checks and alerting is the right shape, and Web-Check is not it. The same applies to crawling: Web-Check is not described as a crawler, so if you want an inventory of what a site actually serves, you need one.

The comparison that clarifies the design is against a single-purpose CLI. dig, openssl s_client, and curl each do one of Web-Check's jobs with full control over the query: which resolver, which TLS version, which headers, which redirect behaviour. They produce output you can pipe, diff, and put in a script. Web-Check trades that control for breadth and a rendered view. If you are writing an automated check into CI, a handful of CLI calls will be more predictable than parsing a dashboard. If you are a person trying to understand an unfamiliar site in five minutes, the dashboard wins. Those are different jobs and the project is honest about which one it takes.

Licence, maintenance, and what version 2.x tells you

Web-Check is MIT licensed, which permits commercial use, modification, and redistribution provided the copyright notice and permission notice are preserved. That is permissive and unsurprising for a tool of this kind. Two things sit outside that grant and are worth separating. First, the third-party APIs the panels call have their own terms, quotas, and in some cases their own licensing; the MIT licence on this repository says nothing about them. Second, if you fork and deploy a modified version, you are responsible for what your instance sends to those upstreams. Nothing here is legal advice; read the licence file and the terms of each service you enable.

The release history is short and legible. Version 2.1.0 landed in May 2026, 2.2.0 in July 2026 and 2.3.0 in October 2026, with the last push to the default branch on 2026-11-02. That is a project that ships in occasional, substantial increments rather than continuous churn.

Upgrade cost between 2.x releases is likely low for a self-hosted instance, since the deployment is a container or an Astro build with no database migration path described. The recurring cost is not the upgrade; it is the upkeep of the environment variables and any upstream API keys, plus the work of noticing when a panel goes quiet because a dependency changed.

Editorial conclusion

Adopt Web-Check if you need a repeatable first-pass report on a hostname you are authorised to inspect, and you want it running on your own infrastructure rather than through someone else's hosted instance. Do not adopt it as an attack surface scanner, a continuous monitor, or a substitute for a DNS or TLS specialist tool when a panel's output is the thing you actually care about. Verify three things before you rely on it: that every panel you need returns data from your deployment rather than erroring on an upstream API, that API_DISABLED_CHECKS and API_ENABLED_CHECKS are set so only the checks you intend to run reach third-party services, and that the MIT licence and the bundled third-party API terms both fit how you plan to use the output.

Frequently asked questions

Official sources

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