# Cloudflare setup

Cloudflare Pages can host reviewed generated files or build a source repository. Choose one path based on the actual repository/project. This guide describes configuration; it does not connect accounts, push source, change settings or prove the current showcase project uses these values.

# Read-only project check

Before changing an existing project, preserve its current settings/deployment/return path. Source access and OAuth connection are not release permission. Preview artifacts can also reveal sensitive data, so do not treat them as private solely because the branch is not production.

# A. Pre-rendered output

Build/test/review outside the deployment repository. Include only approved output at its intended publishing root. A root-rendered repository has index.html, generated page folders, 404.html, search JSON, CSS/JS/fonts, public media, notices/manifest and supported host rule files.

For a repository whose generated files are at its root, select that root in the output setting. For a nested artifact, select its actual containing directory. Verify the dashboard accepts/resolves the value and resulting deployed tree. Do not assume a visually similar folder selector points at the same bytes.

No npm/Node/MarkStack runtime is needed to serve an already-rendered artifact. An exit 0 build cannot catch missing assets/source errors. Those checks must have passed on the reviewed artifact before release.

Never upload .markstack, users/hashes, audit/publish state, editor HTML/server, dependencies, private source/backups or environment files. Static copying can publish any supplied asset, not merely images. Hidden sections/search prose are public output unless a reader gate covers them.

# B. Source build

Source project root contains package, lockfile, builder, config, content, templates and static assets. Inspect intended effective branding/data. Do not place production account data into a connected source repository to get header settings working.

npm ci && npm test && npm run build

These chained commands stop on failure. Inspect real logs/exit and artifact, not just the provider green badge. If the host’s install stage already ran, understand its dependency behavior and keep locked install review consistent. Development dependencies matter for selected tooling; ordinary build consumes committed browser bundles and does not need regeneration.

Current Pages build-image guidance supports NODE_VERSION or project .nvmrc/.node-version. It does not support package engines detection in its v3 system, nor version codenames there. Set a numeric supported Node 24 release and confirm the build log’s actual version; the pin requires 24+, while provider defaults can be lower. Do not rely on a remembered default or silently pick a future major without testing the pin.

Configure final siteUrl and baseUrl before generation. The engine does not automatically derive them from CF_PAGES_URL. A custom content folder does not bring its own installation config/template/static files. If build data is supplied separately, record the selected safe settings/links/icons and intended public disclosures.

# Preview gate

Keep top-level 404.html; Pages assumes a SPA when it is absent. That can turn missing paths into home content and obscure failures. The pin’s 404 Return Home link points at /; inspect this limit on subpath hosting too.

Compare preview and production metadata/resource paths. A preview domain is not automatically the configured canonical origin. Do not change the public origin merely to make one transient preview look correct without an intended production decision.

# Host rules

Author supported host files in static/ for source-build copying, or at the reviewed artifact root for rendered releases. Redirect rules run before headers. Requests handled by Pages Functions need their own behavior; static file rules are not a guarantee there.

Do not copy blanket SPA rewrites or a CSP that blocks stock inline state initialization. Review current syntax and test the actual reader. Numeric provider quotas/plan prices can change; consult the selected project’s current policy when they become a deployment decision.

# Custom domain sequence

1. Confirm the observed successful Pages deployment and intended project.
2. Add the hostname through that project’s custom-domain flow.
3. For a Cloudflare-zone apex, use the required Cloudflare nameserver/account setup.
4. For an external-DNS subdomain, add the provider CNAME to the observed Pages hostname after project association.
5. Verify activation, DNS, HTTPS, redirect/canonical behavior and current reader.

Manually creating a CNAME without first associating the domain in Pages can produce 522 failure. Do not guess <project>.pages.dev from a display name. Use the actual provider-returned hostname. DNS setup distinguishes record/certificate paths.

# Complete only after live verification

Inspect deployment status plus actual public home/deep/search/media/404/resources, both fresh and cached browser contexts. Review zone caching that could retain old responses. Preserve prior artifact/deployment and a tested host rollback route.

These are source-backed setup templates. No existing account’s production branch, root, build, image, output, domain or cache was altered or certified by writing this page. Local tests/build/preview are separate from production provider acceptance.

# Official sources

Checked 12 October 2026:

• Static HTML.
• Build configuration.
• Build image/version selection.
• Serving/404/cache.
• Custom domains.
• Redirect rules.