Web-Check: What lissy93/web-check Actually Reports About a Site, and Where It Stops
🕵️♂️ All-in-one OSINT tool for analysing any website
At a glance
- What is it?
- Web-Check is a self-hostable TypeScript dashboard that runs a fixed set of reconnaissance jobs against one hostname at a time. It is useful for a first pass on a site you already have permission to look at, and it is not a scanner, a crawler, or a substitute for a purpose-built tool for any single one of its panels.
- Who is it for?
- 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.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 2 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
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 lists the panels it renders: 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. Each of those has a dedicated tool that does it better. The value here is that you type one hostname and get all of them in one view, without writing the glue yourself.
That framing matters because it sets the correct expectation. Web-Check is a convenience layer over a dozen external data sources and a handful of direct 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 architecture visible in the repository is a Next.js application. The front end is a dashboard that renders one card per job. The server side exposes API routes, and each route corresponds to one job: one fetches DNS records, another opens the TLS connection and walks the chain, another issues the HTTP request and reads back headers and cookies, another runs the traceroute, another queries an external service for geolocation or carbon estimates. The README's feature list is effectively an index of those routes.
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. There is no database described in the README, no scheduler, and no alerting. 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. IP geolocation, carbon footprint estimation, and tracker classification are not things you compute locally from a DNS lookup. The README's sponsor section is a reminder that this project sits inside an ecosystem of commercial APIs. 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 five deployment paths. Three are managed platforms: Netlify, Vercel, 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 does not reproduce a full docker run invocation, so the exact image tag and port mapping should be read from the repository's Dockerfile and workflow file rather than guessed. Treat that as the first thing to check after cloning.
Deploying from source follows the standard Next.js shape. The README points to a Developer Setup section, and the repository is TypeScript throughout, so the sequence is a package install followed by the project's dev or build script. The README references a Configuration Options section for environment variables, and the deployment sections reference WEB_CHECK_ENABLE_ALL. That variable is the one worth understanding before you expose the app: it controls whether all jobs are enabled, which in practice means whether the instance will reach out to every external service the panels depend on. 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, that flag is the switch that decides it.
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
Of everything in the feature list, open ports is the panel 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. It is not a scan of the target's full range, it is not run from multiple geographies, and it is not repeated. 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, in the same way the redirect ledger is useful for spotting an unexpected hop. Neither is evidence on its own, and the README does not present them as such.
The same caution applies to the performance panel. 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: the page map and search crawl rules panels read what the site declares in robots.txt and sitemap files. They do not discover pages by following links. If you want an inventory of what a site actually serves, you need a crawler, and Web-Check will only show you what the site admits to.
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 1.0.0 landed in May 2024, 2.1.0 in May 2026, and 2.2.0 in July 2026, with the last push to the default branch in September 2026. That is a project that ships in occasional, substantial increments rather than continuous churn. The README itself carries a note under the feature list saying the list needs updating because many more jobs have been added since it was written. That is a small but real maintenance signal: documentation drifts behind the code, so the API routes in the repository are a more current inventory of what runs than the README's feature list.
Upgrade cost between 2.x releases is likely low for a self-hosted instance, since the deployment is a container or a Next.js 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 WEB_CHECK_ENABLE_ALL is not exposing jobs you did not intend to run against third-party services, and that the MIT licence and the bundled third-party API terms both fit how you plan to use the output.
Community notes