LOG 07 · INFRASTRUCTURE
Cloudflare Pages Deployment
Static builds pushed straight to Cloudflare's edge network via Wrangler — fast first-byte times worldwide, and nothing running that needs a server bill or a patch schedule.
Published · Updated
Deploy is a build artifact, not an operation
Because the site compiles to static files, deployment is `wrangler` pushing that output directory to Cloudflare's edge network — no server to provision, no runtime to keep patched, no scaling configuration to get wrong under a traffic spike. The entire site is replicated to edge locations worldwide, so a visitor gets served from whichever location is physically closest to them.
For client work, this matters beyond raw speed: a static, edge-hosted site has a dramatically smaller attack surface and no ongoing server cost that scales unpredictably with traffic — one less thing for a client to budget for or worry about after launch.
Headers are part of the build
On a static host there is no application code left to set response headers, so they become a file that ships with the build. A `_headers` file declares the security set — nosniff, frame options, referrer policy, HSTS, a permissions policy — plus the cache policy, which is the one thing that genuinely varies by file type: content-hashed build output can be immutable for a year, images for a month, the HTML itself not at all.
There is a sharp edge worth knowing. Cloudflare Pages applies every rule that matches a request and appends the headers, rather than letting the most specific rule win. Repeating a security header inside a per-extension block therefore does not reinforce the global rule — it emits that header two or three times on the same response, and a repeated single-value header reads to a scanner as no protection at all. Declare each one once, globally, and let the narrower blocks carry only what actually differs.