The Static-Edge Model

Before touching a single command, we have to be precise about what “deploy” even means here, because it is not the meaning the rest of this book has used. In Part 4 and the capstone, to deploy was to get a process running — schedule a container onto a node, keep it alive, health-check it, and route traffic to it. In the static-edge model, to deploy is to copy a folder of finished files onto a CDN. There is no process. That single difference is the source of everything this Part deletes.

Static output: the artifact is files, not a program

An Astro + Starlight site is a static site generator. At build time it runs your code once, renders every page to HTML, and writes plain files — .html, .css, .js, images, fonts — into a dist/ folder. After the build finishes, your code never runs again. What ships to production is the output, not the generator.

   BUILD TIME (once, on a CI runner)        REQUEST TIME (millions of times, at the edge)
   ─────────────────────────────────        ──────────────────────────────────────────
   your source ──► generator runs ──► dist/     browser ──► CDN edge node ──► returns a file
   (Astro, MDX, React components)   (HTML,       (Tokyo, Frankfurt,    (already sitting on disk,
                                     CSS, JS)      São Paulo, …)         nothing is computed)

Contrast that with the Snip service, which runs your program on every request — parse the URL, query Postgres, touch Redis, redirect. Snip’s correctness depends on a process behaving well under load, forever. A static site’s correctness was decided once, at build time, and then frozen. Freezing the work is the whole trick. It is the same idea as immutable infrastructure: you don’t patch the running thing, you replace it wholesale with a new, pre-built artifact.

”The edge”: the CDN is the runtime

A CDN is a network of servers spread across the globe that cache and serve content close to the user. In a classic web app the CDN sits in front of an origin server and caches what the origin produces. In the static-edge model there is no origin to sit in front of — the files are the whole application, so the CDN holds all of it, everywhere, permanently. Cloudflare Pages pushes your dist/ to Cloudflare’s global edge; a reader in Tokyo and a reader in Frankfurt each get the bytes from a node near them.

This is why the capstone’s autoscaling chapter has no counterpart here. There is no per-instance capacity to grow, because the thing serving requests is a globally-distributed CDN that was already built to absorb planetary traffic. You are not scaling a server; you are handing files to an infrastructure that is horizontal by construction.

What the model deletes — and why each thing goes

Line up the model against the operational burdens from earlier Parts and watch them disappear:

Ops burden (earlier Parts)	Why it vanishes for a static site
Keeping a process alive (probes, restarts, systemd)	There is no process. A file cannot crash.
Autoscaling (Part 9)	The CDN is global from the first byte; there is nothing to scale up.
Runtime secrets (secrets mgmt)	The site computes nothing at request time, so it holds no DB passwords or API keys to leak.
Patching a running OS/userland	Immutable output; the next deploy replaces everything atomically.
Rollback orchestration	A previous deploy is just a previous set of files — roll back = re-point to it.
A whole class of injection bugs	No server-side request handling means no SQL injection, no SSRF from your handler, etc.

The point is not that static sites are “better.” It is that a large family of production risks are structurally impossible in this model — not mitigated by good practice, but absent because the machinery that produced them isn’t there. That is the strongest kind of safety: the guardrail you don’t have to remember to install.

The honest boundary — where this model stops

A first-principles book has to say where the abstraction breaks, or it is selling something. The static-edge model applies only when a request needs no per-user, per-request server computation. The moment you need to do something dynamic on the server, you are back to running code:

• Per-request logic (auth checks, form processing, personalized pages, a database read) needs compute at request time. On Cloudflare that means Pages Functions / Workers — small serverless functions at the edge — which reintroduces runtime code, and with it secrets, cold-path errors, and observability of a running thing. That is a real and powerful model (it is the WASM & the edge story), but it is no longer “just files.”
• Truly dynamic, user-specific data that can’t be baked at build time.
• Server-held secrets — anything the client must not see cannot live in a static bundle. If it’s in the dist/, it’s public. This is a security invariant, not a preference.

This site sits squarely on the static side of that line: it is documentation, the same for every reader, so 100% of it can be frozen at build time. That is why the model fits — not by luck, but because the artifact genuinely has no per-request work to do. Choosing the deployment model is really choosing whether your artifact does per-request work. Get that judgment right and the rest of this Part is almost free.

Check your understanding

1. In one sentence each, define “deploy” as it was used in the capstone versus how it is used in this Part.
2. A static site’s code “never runs again” after build. Where, then, does all the work happen, and what is the single artifact that reaches production?
3. Autoscaling was a whole chapter in Part 9 but is absent here. Explain, from first principles, why there is nothing to autoscale.
4. Name two production risks that are structurally impossible for a purely static site, and say what makes them impossible rather than merely unlikely.
5. Give a concrete feature you might add to this site that would push it over the boundary into needing runtime code, and name what you’d reintroduce by adding it.

Show answers

1. Capstone: to deploy is to get a process scheduled and kept running so it can serve requests. This Part: to deploy is to copy a folder of pre-rendered files onto a CDN, after which nothing of yours runs.
2. All the work happens once, at build time, on a CI runner, where the generator renders every page. The single artifact that reaches production is the dist/ folder of static files — HTML, CSS, JS, assets.
3. Autoscaling grows the number of instances of a running process to meet demand. A static site has no running process; the thing serving requests is a globally distributed CDN that is horizontal by construction and already sits close to every user. There is no per-instance capacity that could become the bottleneck, so there is nothing to scale.
4. Any two of: SQL injection / SSRF / server-side injection (there is no server-side request handler to inject into); runtime secret leakage (the site holds no secrets at request time — nothing is computed); a crash/OOM taking the site down (a file cannot crash). Each is impossible because the mechanism that produces it (a running handler, held secrets, a live process) does not exist, not because it was carefully prevented.
5. Examples: a login/auth flow, a contact form that emails you, a per-user dashboard, a comment system, or anything reading a live database. Any of these needs compute at request time (e.g., Cloudflare Pages Functions / Workers), which reintroduces runtime code, secrets, cold-path error handling, and the need to observe a running service — the very burdens the static model deleted.