What is static site hosting?

Static site hosting serves files that already existed before anyone asked for them. A visitor requests a URL, the host finds the matching file, and sends it. No database is queried, no template is rendered, no application code runs. The HTML that reaches the browser is byte-for-byte the HTML that was sitting on disk a moment earlier.

That is the whole definition. Everything else about static hosting — why it is fast, why it is cheap, why it is hard to break — falls out of it.

What “static” does not mean

It does not mean the site is plain, old-fashioned, or lacking JavaScript. A static site can be a React app with client-side routing, a documentation site with instant search, or a store that talks to a payment API. All of that runs in the visitor’s browser, which is a computer that is not yours and not billed to you.

It does not mean the content never changes, either. Most static sites are generated: a build step turns markdown, a CMS export, or a database query into finished HTML, and that build runs whenever the content changes rather than on every request. Hugo, Astro, Eleventy, Jekyll, Next.js in export mode and Vite all do this. The page a visitor gets is static; the process that produced it was not.

What it does mean is that nothing on the server decides anything at request time. Two visitors asking for the same URL get the same bytes.

Static versus a server that runs code

The contrast is with hosting that executes your application per request — WordPress on PHP, Rails, Django, a Node server, a serverless function.

	Static hosting	Application hosting
What happens on a request	A file is read and sent	Your code runs, then produces a response
What can differ per visitor	Nothing server-side	Anything
What can go wrong at 3am	The file is missing	The runtime, the database, a dependency, memory, a deploy
Cost driver	Storage and bandwidth	CPU time, memory, concurrency
Attack surface	The file that is there	Every line of code that executes

The security difference is the one people underrate. A static host has no database to inject into and no interpreter to trick, because there is no interpreter. The classic vulnerabilities of the dynamic web mostly do not have anywhere to land.

How serving actually works

Three things happen between a URL and a page:

1. Routing. The host maps the request path to a file — /about usually means /about/index.html. Where no file matches, it serves a 404 page, or, for a single-page app, serves index.html and lets the client router decide.
2. Caching. Static files are ideal to cache, because a given file’s content never changes in place. Good hosts cache aggressively at the edge so a repeat visit does not travel back to the origin at all.
3. TLS. The host terminates HTTPS and, on a managed one, issues and renews the certificate for your domain so you never think about it.

The interesting engineering is in how a new version gets published without the site ever being half-old and half-new. A host that copies files over the live ones has a window where a visitor can get the new HTML and the old CSS. Hosts that publish atomically — including One9x Pages — write the whole new version first and switch to it in one operation, so that window does not exist.

When static is the wrong answer

Be honest about this early, because retrofitting is painful:

• Per-user pages rendered on the server. A dashboard that must not send one user’s data to another’s browser needs server-side rendering or an API with real auth behind it.
• Content that must be correct the instant it changes. A static site is as fresh as its last build. For a stock ticker or a live inventory count, that is too slow, unless the number is fetched client-side.
• Anything needing server-side secrets at request time. A static file cannot hold an API key; anything shipped to the browser is public.

A common and good middle path is static pages that call APIs from the browser — search, comments, a cart, a form endpoint. The pages stay static; the dynamic part lives somewhere else that is built for it.

What to look for in a host

Once you know the site is static, hosts differ on a short list of things:

• Atomic publishing, so a deploy is never half-applied.
• Rollback that does not mean rebuilding — the previous version should still exist and be one action away.
• A preview of the new version before it becomes the live one.
• Custom domains with managed HTTPS, issued and renewed without you.
• A price shape you can predict. Some hosts bill a flat plan; some meter bandwidth, build minutes or seats. Neither is wrong, but they behave very differently on the month you get linked from somewhere large.

We wrote up what those actually cost in practice in what static hosting costs, and the free-tier options — including their catches — in hosting a static site for free.