09 — Cloudflare routing

This bundle includes a Cloudflare Worker proxy template for the literal path GitHub Pages → Cloudflare Worker → visitor. Git-FED still uploads the source to GitHub. GitHub Pages remains the origin; the Worker fetches only the fixed GITHUB_PAGES_ORIGIN configured in wrangler.toml and forwards GET/HEAD requests. The Worker is not an open proxy and does not add data storage.

Choose one production path

Worker in front of GitHub Pages: keep GitHub Pages enabled. Set GITHUB_PAGES_ORIGIN to the exact project URL, such as https://OWNER.github.io/Meta-Sites, replace the username placeholder, and deploy wrangler.toml with Wrangler. Attach the Worker to a Cloudflare Worker route on a proxied hostname (for example site.example.com/*). The public hostname must be in an active Cloudflare zone and have a proxied DNS record. Use a hostname separate from the github.io origin so the Worker does not proxy to itself. The Worker rewrites the repository prefix and forwards the request path. See the Cloudflare Worker route documentation and external-origin Worker example.

Cloudflare Pages connected to GitHub: instead of proxying the GitHub Pages site, connect the same GitHub repository to a Cloudflare Pages project. For this no-build static HTML project, select no framework, leave the build command empty, and use the repository root as the output directory (. if the setup UI requires a value). Cloudflare Pages then deploys from GitHub on pushes. In that arrangement, GitHub is the source repository and Cloudflare Pages is the host; GitHub Pages is not in the visitor request path. See Cloudflare Pages GitHub integration.

Do not configure a Worker proxy and a Pages custom domain as if both were the same origin. Choose which product serves the public hostname. A Pages custom domain is attached under Workers & Pages → your Pages project → Custom domains → Set up a domain; follow Cloudflare's custom-domain guide.

Deploying the Worker template

  1. Git-FED creates or updates the Meta-Sites repository and confirms GitHub Pages works directly first.
  2. Replace YOUR_GITHUB_USERNAME in wrangler.toml with the GitHub account name. Keep the repository path /Meta-Sites and verify the exact URL shown in GitHub Pages settings.
  3. From the repository root, run npx wrangler deploy after authenticating Wrangler to the intended Cloudflare account. This package does not perform that deployment.
  4. Add the production route in Cloudflare Workers settings for a Cloudflare-managed, proxied hostname such as site.example.com/*. If the Worker itself is the hostname's origin, use a Worker Custom Domain instead of a route. Do not point the route at the GitHub Pages origin hostname.
  5. Open the Cloudflare public hostname. Check the main page, favicon, a promo image, one guide HTML route, the support age screen, and the 404 route. After each GitHub upload, check the public Cloudflare route and refresh it.

The source code and this archive contain a placeholder hostname, no Cloudflare account credentials, and no domain. Nothing has been deployed. The Worker returns HTML error pages for configuration and upstream failures.

Update sequence and caching

Git-FED uploads the edited files to GitHub. GitHub Pages publishes the origin version. The Worker forwards the request to that origin. Then Git-FED opens the public Cloudflare hostname and checks the edited text and refresh persistence. If Cloudflare or the browser shows an old version, check the origin deployment first and then review caching and force-refresh the edge/browser copy. The Worker does not deliberately cache its subrequest responses.