# What Is Static Site Hosting? — Serving Files Without a Server

Canonical: https://commareports.com/glossary/static-site-hosting
Published: 2026-09-11

> Static hosting serves pre-built files straight from storage or a CDN, with no application runtime. What it does well, the four things it never handles, and where reports fall between.

# 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`](/glossary/mime-type), which is most of what a
  [generated report](/glossary/html-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

1. **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](/alternatives/cloudflare-access-alternatives)).
2. **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.
3. **Comments.** There is nowhere to put "this assertion is the real
   failure" except a separate chat thread that scrolls away.
4. **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:

1. Push reports to GitHub Pages or an S3 bucket. Rendering is fixed.
2. 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.
3. 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](/comment-on-html)).

## Try it

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

**[Publish a report directory →](https://commareports.com/)**

### Related

- [GitHub Pages alternatives](/alternatives/github-pages-alternatives) · [Netlify Drop](/alternatives/netlify-drop-alternatives) · [S3](/alternatives/s3-static-hosting-alternatives)
- [Presigned URL](/glossary/presigned-url) · [Build artifact](/glossary/build-artifact)
- [Host an HTML file](/host-html-file) · [Glossary](/glossary)