What is the difference between static hosting and a web application?

A static host returns bytes that already exist. An application computes a response per request, which is what makes per-user access control, form handling and stored state possible. Static hosts have none of that, which is exactly why they are cheap and fast.

Can static hosting do access control?

Not on its own. Some providers bolt on a password or an identity proxy at the edge, but the underlying model is 'anyone with the URL gets the file'. Anything per-reader — who opened it, revoking one person — needs something in front of the files.

Is static hosting a good place for CI reports?

It solves rendering — the assets travel and the page loads over a real origin. It does not solve access, versioning, comments or deletion policy, which is why teams that start with GitHub Pages usually end up building a small application around it.

Static site hosting

Static site hosting serves pre-built files — HTML, CSS, JavaScript, images — directly from storage or a CDN, with no application code running per request. Path in, file out, correct headers attached.

GitHub Pages, Netlify, Vercel's static output, Cloudflare Pages, S3 plus CloudFront, GitLab Pages and Surge are all this model.

What it is very good at

Speed and cost. Files at the edge, no runtime, effectively free at report-sized traffic.
Correct headers. A real HTTPS origin and a correct Content-Type, which is most of what a generated report needs to render.
Whole directories. Relative asset references resolve, so the multi-file structure that breaks in email works here unmodified.

For publishing a docs site or a marketing page, this is the right answer and has been for a decade.

The four things it does not do

Per-reader access. The model is "whoever has the URL has the file". Edge password protection and identity proxies exist as add-ons, but nothing is per-person by default, and nothing is revocable per person (Cloudflare Access alternatives).
Versions. A deploy overwrites. Comparing today's coverage tree to last month's means having kept two directories under two paths and remembering which was which.
Comments. There is nowhere to put "this assertion is the real failure" except a separate chat thread that scrolls away.
Lifecycle. Nothing tells you a report is stale, nobody opened it, or the branch it documented was deleted.

Where report publishing lands

A CI report is a static file that needs application behaviour around it. Teams reach the same three stages:

Push reports to GitHub Pages or an S3 bucket. Rendering is fixed.
Discover reports are visible to everyone or to nobody, and start building a path scheme — /reports/<branch>/<sha>/ — plus a cleanup job, plus an index page.
Discover that reviewers still screenshot findings into Slack, because there is nowhere in the report to say anything.

The build in stage 2 is real work with no end: the index needs maintaining, the cleanup job deletes the wrong thing eventually, and the access question is still unanswered.

The other shape

Publishing to an address that already has the application behaviour: unlisted or restricted access per report, a stable id PATCHed on every run so the URL never changes, every run appended as a diffable revision, and comment threads anchored to selections inside the report body (comment on HTML).

Try it

Comma is free — unlimited reports, unlimited commenters, unlimited revision history.

Publish a report directory →

GitHub Pages alternatives · Netlify Drop · S3
Presigned URL · Build artifact
Host an HTML file · Glossary