← Home
HIFP · v4 Canonical Kit

Docs Hosting Runbook v1

Deploy sequence + operations reference · v1 · 2026-09-20 · Owner: brandonstauber@gmail.com

Version. v1 · 2026-09-20
Owner. Brandon Stauber
Status. Draft — deploy sequence pending Brandon execution
Companion. HIFP-poc-hosting-runbook-v1 — same pattern, same Cloudflare account + team

Mirror of the POC hosting pattern for the v4 canonical kit. Same Cloudflare account, same team (hifp on hifp.cloudflareaccess.com), same trio allowlist, separate Pages project + Access application.

§1 · Quick reference (at-a-glance)

ItemValue
Production URLhttps://hifp-docs.pages.dev (planned)
GitHub repohifp-docs (private, to be created)
Cloudflare Pages projecthifp-docs
Cloudflare Access applicationHIFP Docs
Access teamhifp.cloudflareaccess.com (existing, shared with POC)
Allowlist policyBrandon + Sindhu + Fatima (same emails as POC)
Session length24 hours (email OTP re-prompt after)
Site contentContents of ~/Desktop/HIFP/artifacts-v4/ at repo root
BuildNone — static HTML only
Deploy triggerGit push to main (Cloudflare auto-deploy)

§2 · Current stack

Runtime. Static HTML + CSS. No JavaScript build. No adapter. No environment variables. The entire site is served as-is from the repo root.

Files in repo (once created):

MD companions. Every canonical HTML artifact has a companion .md file in the same directory. These are served (Cloudflare Pages serves any file at its path), but render as plain text in a browser. HTML versions are what the index links to.

Cloudflare Pages Build Configuration (in dashboard, at project creation):

§3 · How to add a user

Same two-step pattern as POC (see POC runbook §3 for full detail):

Step 1 · Invite to Cloudflare account. Cloudflare dashboard → Manage Account → Members → Invite. Email + role: Analytics (or Administrator - Read Only for viewer-only).

Step 2 · Add to Access allowlist. Zero Trust → Access → Applications → HIFP Docs → Policies → edit the HIFP Docs Allowlist policy → add email to the Emails include selector.

Both steps required. The Access allowlist alone doesn't grant Cloudflare-account visibility; the Cloudflare-account invite alone doesn't add the user to the Access app.

§4 · Initial deploy sequence (one-time setup)

Prereqs. GitHub account with permission to create private repos. Cloudflare account + Zero Trust team hifp (existing, shared with POC).

4.1 · Create the GitHub repo

gh repo create hifp-docs --private --description "HIFP v4 canonical kit — private docs site"

4.2 · Prepare local git repo from artifacts-v4/

cd ~/Desktop/HIFP/artifacts-v4
git init
git branch -m main
git remote add origin git@github.com:<your-username>/hifp-docs.git
git add .
git commit -m "Initial commit — v4 canonical kit (2026-09-20 rebuild)"
git push -u origin main

4.3 · Create Cloudflare Pages project

  1. Cloudflare dashboard → Workers & Pages → Create → PagesConnect to Git
  2. Authorize the hifp-docs GitHub repo
  3. Project name: hifp-docs (produces hifp-docs.pages.dev)
  4. Production branch: main
  5. Framework preset: None; Build command: (empty); Build output directory: /
  6. Save + deploy

First deploy takes ~30–60 seconds. After it succeeds, the site is live at hifp-docs.pages.dev — but publicly accessible until Access is applied.

4.4 · Create Cloudflare Access application

  1. Cloudflare Zero Trust dashboard → Access → Applications → Add an applicationSelf-hosted
  2. Application name: HIFP Docs
  3. Session duration: 24 hours
  4. Application domain: hifp-docs.pages.dev
  5. Path: (leave empty — protect everything)
  6. Identity providers: One-time PIN (email OTP; enable Google / GitHub / Microsoft optionally)
  7. Save

4.5 · Add the allowlist policy

  1. In the HIFP Docs app, go to PoliciesAdd a policy
  2. Policy name: HIFP Docs Allowlist
  3. Action: Allow
  4. Include: Emails — list all three founder emails (same list as POC's HIFP POC Allowlist)
  5. Save
Verify. Load https://hifp-docs.pages.dev in an incognito window; you should see the Cloudflare Access email prompt, then land on the v4 index after entering an allowlisted email and its OTP.

§5 · Ongoing deploy cycle

5.1 · Edit → commit → push

Standard git flow. Edit any file in ~/Desktop/HIFP/artifacts-v4/, then:

cd ~/Desktop/HIFP/artifacts-v4
git add -A
git commit -m "<what changed>"
git push

Cloudflare auto-deploys within 30–60 seconds. Watch build logs at Cloudflare dashboard → Pages → hifp-docs → Deployments.

5.2 · Repo hygiene

.gitignore — excludes at minimum: .DS_Store, *.tmp, inputs/

README.md — repo purpose + link to this runbook + entry point (index.html). Present at repo root.

§6 · Environment variables

None. Static HTML has no runtime. If we ever add analytics (Plausible, Cloudflare Web Analytics), env vars would only be needed at build time — and this site has no build. Any analytics gets embedded directly in index.html.

§7 · Cloudflare Access details

Application configuration. As set up in §4.4.

Policy configuration. As set up in §4.5 — one Allow policy with the trio's emails.

Identity providers enabled. One-time PIN (email OTP) minimum. Optional: Google / GitHub / Microsoft.

Team domain. hifp.cloudflareaccess.com (existing, shared with POC).

Cloudflare Access pricing. Zero Trust free tier covers up to 50 users. Trio uses 3. POC + Docs together share the team's user count.

§8 · Known constraints + gotchas

Sub-path routing. Cloudflare Pages serves files at their repo path. hifp-docs.pages.dev/HIFP-investment-memo-v4.html works. No SPA routing needed since this is static.
.md files served as plain text. Cloudflare Pages serves .md files with content-type: text/plain, which renders as unformatted text. HTML versions are what the index links to.
Case sensitivity. Cloudflare Pages is case-sensitive on paths. HIFP-investment-memo-v4.html and hifp-investment-memo-v4.html are different URLs. The index and inter-artifact links use exact-case names throughout.
Preview URLs are public. Cloudflare gives every deploy a preview URL (https://<hash>.hifp-docs.pages.dev). These are NOT Access-protected by default. To protect: add *.hifp-docs.pages.dev as an additional application domain in Access.
Access domain change requires re-verify. If we change hifp-docs.pages.dev to a custom domain, the Access application's Application Domain must be updated to match, or Access will not intercept requests.

§9 · What lives in this site (content spec)

The v4 canonical kit at time of first deploy:

Cross-links. All internal links use relative paths. Links to ../artifacts-v3/* in the index rely on the artifacts-v3 directory being sibling-deployed OR being pruned to only what the docs site needs. Decision point: for first deploy, either (a) copy the referenced v3 artifacts into hifp-docs/reference/ and update the index paths, or (b) leave the reference-section links pointing at local file:// paths and accept that they don't resolve on the deployed site. Recommendation: (a), for a self-contained site.

§10 · Watch triggers (change events that need runbook update)

Version history