A Serious Website Without a Server
How Cloudflare Pages turns one static build into a globally delivered site—and where that model stops being the right fit.
Many small websites inherit operational work they never needed: a virtual machine, operating-system patches, an Nginx configuration, and a database kept alive for a site that publishes a new article once a month. Those technologies are useful, but they solve a different class of problem.
When a site’s output can be known ahead of time, an application server is optional. Articles, documentation, portfolios, and many browser tools can be rendered to HTML at publish time and delivered directly by a CDN. That is the model Cloudflare Pages serves particularly well.
What happens when a page is requested
A conventional dynamic site may execute application code, query a database, and assemble HTML for each request. A static site moves that work to the build:
Markdown + templates → build → HTML/CSS/JS → CDN edge → browserThe visitor receives a finished document. With no database connection or server-side rendering step in the request path, there are fewer moving parts to fail. Files can be cached at the edge, producing more consistent latency around the world.
“Static” does not mean inert. Search, image compression, format conversion, and Markdown preview can all run in browser JavaScript. The word describes the deployed artifacts, not the experience.
Why Pages is useful
Cloudflare Pages combines build integration, deployment history, HTTPS, CDN delivery, preview URLs, and custom domains. Its value for a content site is less about one spectacular feature and more about turning routine operations into a repeatable release.
A dependable initial configuration is small:
| Setting | Recommendation |
|---|---|
| Build command | npm run build |
| Output directory | dist |
| Node version | Pin it in the repository |
| Production address | Use a domain you control |
| Preview deployments | Keep them for review |
Do not leave essential configuration only in a dashboard. Put the Node version in .nvmrc, scripts in package.json, and response rules in _headers. The project should be able to explain how it is built six months from now.
Direct Upload or Git integration
Git integration works well for continuous publishing: a push starts a build and each change gets a preview. Direct Upload is useful when you do not want to bind a code host, or when a local release script should control exactly what is uploaded.
Wrangler reduces the final upload to one command:
npx wrangler pages deploy dist --project-name your-projectThe important part is everything before that line. A release script should select the agreed Node version, install locked dependencies, run checks, and create a production build. Any failed step must prevent the upload.
When static is not enough
Pure static hosting is the wrong boundary when a feature must protect API credentials, write durable private data, maintain long-lived connections, or run background work. Small dynamic features can live in Workers or another API service, but secrets must never be moved into frontend code merely to preserve a “static” label.
If every visitor can receive the same document shell and the computation can happen at build time or in their browser, static-first is usually worth considering. If every request depends on private state, a server-side component belongs in the design.
Good architecture does not use the fewest technologies. It gives every technology a necessary, explicit job.
Start with a publishing flow simple enough that you will keep using it. Add dynamic infrastructure when an observed requirement calls for it—not when an imagined future scale does.