Skip to content

Cloudflare Pages and Access

Pages project

Create a Cloudflare Pages project connected to the private GitHub repository Kuru-Labs/kuru-docs. Update this reference if an organization administrator renames the repository.

Setting Value
Production branch main
Build command pip install -r requirements.txt && mkdocs build --strict
Build output directory site
Node.js / Python Use Cloudflare's current supported Python runtime; no project secrets are required for this build.

Enable production deployments from main and preview deployments for pull requests. A strict build makes broken internal links and MkDocs warnings fail CI rather than publishing incomplete docs.

Domain and Access perimeter

  1. Attach internal-docs.kuru.io as the Pages custom domain and complete the required DNS validation in the kuru.io Cloudflare zone. Do this before adding the custom-domain Access application.
  2. In the Pages project, go to Settings > General > Enable access policy. This creates the Access application for preview deployments.
  3. Select Manage for that application. In its public hostname, remove the * from the subdomain and save; it now protects <pages-project>.pages.dev.
  4. Return to the Pages project and select Enable access policy again. Confirm a second application exists for *.<pages-project>.pages.dev, which protects hash and branch preview URLs.
  5. In Zero Trust, create a self-hosted Access application for internal-docs.kuru.io and configure its public hostname.
  6. On all three Access applications, add an Allow policy for the Kuru Google Workspace identity provider and/or an explicit approved-email or email-domain rule. Keep a narrowly scoped break-glass group only if operations requires it.
  7. Set a final Deny policy for everyone else. Confirm policy order so the intended allow rule is evaluated before the deny rule.
  8. Test an unauthenticated browser session against the custom domain, the production pages.dev hostname, and a PR preview hostname. Each must challenge through Access; none may serve the site directly.

Cloudflare's Pages Access workaround is necessary because enabling Access in Pages initially protects previews only. Treat the default pages.dev and wildcard preview coverage as a release gate and verify it with an unauthenticated test after any Pages or Access configuration change.

Why this is required

Repository privacy restricts source access, not the public Pages origin. Protecting only internal-docs.kuru.io would leave the default Pages hostname and preview deployments as bypass paths.

Deployment checklist

  • The GitHub repository is private.
  • Pages is connected to GitHub and produces both production and PR builds.
  • The exact build command and site output directory above are configured.
  • The custom domain resolves through Cloudflare.
  • Access covers custom, default Pages, and preview hostnames.
  • Google Workspace/email policy was tested with both authorized and unauthorized identities.
  • No credentials or sensitive runbooks exist in the Git history or deployed output.