Layer 2 — survival fallback on GitHub Pages

Every site static fallback to chirag127.github.io/site \ every push to main. If Cloudflare Pages dies, /work + /me + /legal still serve\ \ from github.io. Per the 100-year strategy \xA716."

Layer 2 — survival fallback on GitHub Pages

Concept

Every site mirrors a static fallback build to GitHub Pages so that the identity-critical pages survive a Cloudflare outage, account suspension, or pricing change. This is the §16 rule of the 100-year strategy: “primary host can die; the wiki, work history, and legal pages must not”.

How it works

• Per-site GitHub Action runs on push to main
• It builds a stripped-down static bundle and publishes to chirag127.github.io/<site-name>
• One custom domain per repo if needed (each site can attach its own subdomain)
• Quota: 100 GB/month bandwidth per site, 1 GB site cap — easily within reach for a degraded-mode mirror
• Static-only — no APIs, no functions, no client-side calls to the primary host. The fallback assumes the primary is down.
• Extension catalog landing pages can run on GitHub Pages full-time (not just as fallback) — see extension-distribution.md
• Allowed monetisation: AdSense + content + utility + portfolio. NOT allowed: e-commerce / SaaS-checkout primary intent.

Why this shape

Cloudflare Pages is excellent but is one company’s free tier. The survival rule is “if the primary disappears overnight, the recruiter clicking through to oriz.in/work tomorrow morning still sees a page”. GitHub Pages is the right second host because the source repos already live on GitHub — the publish workflow is a few-line YAML, no new account, no card.

Cross-refs

• Primary host ? layer-1-static-hosting.md
• Why git is canonical (same survival logic at the data layer) ? canonical-store-jsonl.md
• Extensions catalog hosting ? extension-distribution.md

Edit on GitHub · Back to index