Deploy Pulsar documentation

The existing Cloudflare Pages project is connected to FaranAli9/pulsar-arch.com and deploys main. Cloudflare owns that Git deployment. The repository workflow builds a frozen dependency set, runs every quality gate, generates the deploy headers, and uploads an inspection artifact; it never uploads to Pages or needs Cloudflare credentials.

Before you begin

Use main for production and a pull request for the Pages project's normal Git preview flow. Cloudflare's existing integration, not GitHub Actions, performs those deployments. The site does not use reader analytics or a static CSP nonce.

Control	Repository ownership	External activation
Quality gates and inspection artifact	.github/workflows/deploy-pages.yml	none
Git deployment	existing Pages project connected to FaranAli9/pulsar-arch.com	Cloudflare project settings deploy main
Response policy	generated .vitepress/dist/_headers	Pages build command runs pnpm run docs:headers; output directory is .vitepress/dist
Path aliases	docs/public/_redirects	none after Pages builds the site
Apex, HTTPS, and www redirect	documented host policy	existing Cloudflare zone, Pages custom domains, and a Redirect Rule

Deploy through the existing Git integration

1. Keep the existing Pages project connected to FaranAli9/pulsar-arch.com, with main as its production branch. Its build command must run pnpm run docs:headers and publish .vitepress/dist so the generated CSP hashes and response policy are part of the deployed artifact.
2. On the existing Cloudflare zone, create or retain a Redirect Rule matching the www.pulsar-arch.com hostname. Send a permanent 301 to https://pulsar-arch.com while preserving the request path and query string. This host redirect belongs in Cloudflare; _redirects only owns path aliases.
3. Let Cloudflare deploy the Git revision. Run the Verify documentation for Cloudflare Pages workflow separately; it verifies docs:check, accessibility, Lighthouse, headers, release impact, and critical security before retaining an inspection artifact, but it does not deploy it.
4. Record the Git revision and Pages deployment URL from Cloudflare. Probe the apex, www, a clean URL, its .html alias, /404.html, robots.txt, and sitemap.xml before announcing a release.

Verify the artifact

Run the local artifact checks before opening a pull request.

package.json — Production artifact and quality checks.

pnpm run docs:headers
pnpm run docs:a11y
pnpm run docs:lighthouse
pnpm run docs:security

docs:headers hashes every VitePress inline script after the production build. Its script-src allows those content hashes and never allows unsafe-inline; HTML uses no-cache, content-hashed assets are immutable for one year, and sitemap and robots responses use a short cache lifetime.

Roll back a known-good deployment

Open the Cloudflare Pages deployment history, select the prior known-good deployment, and promote it. Repeat the probes above and record the promoted revision, timestamp, operator, and result in the private launch evidence. Do not create a bespoke rollback upload while a known-good deployment is available.

Troubleshoot activation

An unavailable Cloudflare dashboard session for the existing Pages project or zone, an unverified custom domain, an incorrect Pages build setting, or an absent Redirect Rule is an activation blocker. Keep the last known-good deployment live, record the missing owner action, and do not report production activation as complete.