Cloudflare Pages + Workers: The Static-but-Dynamic Stack

For most of the last decade, the default architecture for a content-heavy business was a server: a Node app behind a load balancer, a Rails monolith on Heroku, a WordPress install on a managed host. The server rendered HTML, talked to a database, and answered every request. That made sense when content was small and personalized. It stopped making sense as content libraries grew into thousands of pages and as AI search engines started crawling those pages constantly.

Today, the workload is upside down from the old assumption. A site like Pillar serves more than 14,000 HTML files, most of which change at most once a week. A small fraction handle anything that needs to run real code: the buy-now redirect, the contact form, the occasional webhook from a payment processor. If you keep the entire site server-rendered to handle that 1%, you pay for 100% server time, accept cold starts on every region you do not have a warm instance in, and patch a database for the rest of your career.

The static-but-dynamic split flips it: pre-render everything you can, run code only when you must, and let the edge absorb the rest. Cloudflare Pages and Workers are not the only way to express this pattern Vercel's static output plus Edge Functions does it too, and Netlify has its own version but they are the cleanest and cheapest expression of it for a content business that does not need server-side personalization.

Cloudflare Pages is, at its core, a build-and-deploy system for static sites. You point it at a Git repository or push directly with the wrangler CLI, and Cloudflare runs your build command, takes the resulting directory of HTML, CSS, JS, and assets, and replicates it across the global edge network. The deploy is atomic: every URL flips to the new version at once, and old versions are kept around as preview deployments you can roll back to from the dashboard.

Where Pages gets interesting is the configuration that lives alongside the static files. A _headers file lets you set custom HTTP headers per path: cache-control rules, security headers, CORS. A _redirects file handles 301s and 302s without writing code, which is enough for most legacy-URL migrations. Pages Functions let you drop a JavaScript file into a special directory and have it deployed as a Worker bound to that route. You do not need to run a build for most of these features they are static configuration files that Cloudflare reads at deploy time.

The deploy flow we use on Pillar is straightforward: wrangler login once to authenticate, wrangler pages project create <YOUR_PROJECT> to register the project, and wrangler pages deploy ./build to push the contents of the build directory. From a clean machine to a live global deployment is under five minutes. Custom domains are added in the dashboard, Cloudflare provisions the TLS certificate automatically through Universal SSL, and DNS records point at the project hostname.

A Worker is a single JavaScript file that exports a fetch handler. When a request hits a route bound to that Worker, Cloudflare spins up a V8 isolate (not a container, not a VM), runs your handler, and returns the response. Isolates start in single-digit milliseconds, so there is no cold-start tax of the kind you see on AWS Lambda when a function has been idle. You write code as if it were a tiny HTTP server and Cloudflare runs it everywhere at once.

The mental shift that matters is that you do not need a Worker per feature. On Pillar we run a single Worker whose job is to receive a request to a buy URL, look up the corresponding Stripe Payment Link, and 302-redirect the visitor to the checkout. Twenty lines of code, one route binding, no maintenance. The same pattern handles form submissions (POST to a Worker, validate, forward to Formspree or your email provider), A/B tests (read a cookie, rewrite the response, set the cookie), and webhook receivers (POST from Stripe or another provider, verify signature, write to a queue).

When you do need more, Cloudflare gives you primitives that compose with Workers: KV for low-write key-value storage, D1 for SQLite at the edge, R2 for object storage with no egress fees, Queues for async work. You can build a real backend with these, but the discipline of the static-but-dynamic sandwich is to avoid building one until you actually need it. Every primitive you adopt is a new thing to monitor.

The honest comparison: all three competitors are fine platforms. They differ on price, defaults, and where the surprises hide. Vercel is excellent if you are running Next.js with server-side rendering, but for a static site at scale you start paying $20+/mo on the Pro tier and bandwidth costs become real once you cross a few terabytes. Netlify is similar in price and has historically charged for build minutes, which means a chatty CI pipeline can quietly become expensive. AWS S3 plus CloudFront is the cheapest at the raw infrastructure layer but requires you to assemble the pieces yourself: bucket policies, origin access identity, CloudFront behaviors, ACM certificates, Route 53. You can do it well, but it is half a week of setup and a permanent surface area you maintain.

Cloudflare Pages plus Workers wins on three axes for a content business. First, unlimited bandwidth on the free tier means your cost does not scale with viral spikes, which removes a category of anxiety. Second, the unified control plane DNS, certs, edge, Workers, R2, D1 means you configure one platform instead of stitching together five. Third, the developer experience of wrangler is consistently better than the equivalent AWS CLI workflow and roughly on par with Vercel's CLI, with the added advantage that you are not betting on a single vendor's framework opinions.

The architecture is also easy to leave. Because your static output is just HTML and your dynamic logic is a single Worker per concern, migrating to another edge platform is a matter of changing the deploy command and rewriting the Worker against a different runtime. There is no lock-in to a proprietary framework, no database export ritual, no infrastructure-as-code drift. If you outgrow Cloudflare in five years, you walk away with your repo and your domain intact.