Why 404cache is built for Cloudflare Pages

404cache is a Next.js site, but it is not deployed as a long-running Next.js server. The repository sets output: 'export', builds an out directory, and is configured around Cloudflare Pages delivery. That is the decision this note records.

This is Adam's project context, not a general claim that Cloudflare Pages is better than GitHub Pages. The previous article compared the platforms category by category without measurements from an identical deployment. There was not enough evidence for that comparison, so I removed it rather than preserving a confident but generic verdict.

The requirements that mattered here

For 404cache, the useful constraints are visible in the project itself:

• articles are MDX compiled through Contentlayer;
• most public pages can be generated ahead of time;
• browser tools do their work in client components;
• the generated site can be served as ordinary static files;
• response headers need to be deployable alongside those files.

The export setting is inspectable in next.config.js. Cloudflare Pages can serve the resulting directory, while public/_headers carries host-level header rules into that deployment.

That fit is more useful evidence than a broad feature table. The site does not currently need a server process to render an article for each request.

The boundary: static first does not mean JavaScript-free

The document shell, article copy, links, metadata, and navigation are available in the exported HTML. Interactive tools then run in the browser. This keeps the reading path independent of a client-side data request while still allowing utilities such as the Robots.txt & Sitemap Generator to be interactive.

There is a cost: features that require a server cannot simply be added as if this were a conventional Next.js deployment. A route under app/api, authentication callback, private database query, or request-time page needs a separate service or a Cloudflare runtime designed for that job. The static export boundary should be checked before promising a feature.

What I would verify before choosing the same setup elsewhere

This note documents one repository's choice. For another project, I would check:

1. whether every important route can be produced at build time;
2. whether forms and APIs have an explicit runtime outside the static export;
3. whether preview builds and deployment logs suit the publishing workflow;
4. whether redirects and headers are supported in the target host's static-file format;
5. whether current platform limits cover the built asset count and size.

Those platform details can change. Cloudflare's Pages documentation and Next.js's static export documentation are the sources to check at decision time.

Current outcome

The decision remains: build 404cache as a static export and use Cloudflare Pages as its delivery layer. I am not publishing build-speed, latency, or cost wins because this repository does not contain a controlled GitHub Pages comparison. If the requirements move towards request-time application behaviour, this decision should be revisited rather than defended by default.

Next: see what GitHub Actions actually checks before the site is built.