The product

apps/server runs the upstream @lhci/server. It receives Lighthouse reports uploaded from CI, stores each Build and its Runs in Postgres, and serves the dashboard for comparing scores over time.

Storage is outside the container, so the score history survives redeploys and restarts. The server has no build step and no schema of its own: @lhci/server creates its tables on first boot.

Server basicAuth is one username and password pair that gates every route, including the upload endpoint. Every onboarded repo shares it.

Each Project also has a Build token, printed at registration, that tells the server which Project an upload belongs to, and an Admin token, shown once, that is needed only to rename or delete that Project.

For a Client site with no CI of its own, the server can run scheduled PageSpeed Insights audits itself (PSI collection) and store them in an already-registered Project.

Each Run stores a full Lighthouse report. A daily job deletes Builds and their Runs older than a set number of days, so the database does not grow without limit.

lhci-toolkit (@houses/lighthouse-cli) registers Projects and lists them. @houses/lighthouse-login-helpers gets Lighthouse past a login before it audits a page. The lhci-onboarding skill, published on npm as @houses/skill-lhci-onboarding, walks through the whole onboarding.