Hub Access — Cloudflare Zero Trust

STATUS: ✅ LIVE since 18 Jul 2026. App NutriSync Builders Hub protects nutrisynccollective.com/hub with an Allow policy (Founders email allowlist) + One-time PIN, 24h sessions. The 123456 room code remains as an inner soft layer. Note: the pages.dev alias bypasses Access (different hostname) — it keeps only the soft gate. A www→root redirect rule closes the www side door. To manage access: Cloudflare → Zero Trust → Access → Applications → NutriSync Builders Hub (add/remove founder emails in the Founders policy).

How to replace the client-side 123456 room gate with real, server-side access control on the hub, for when the investor/builder material becomes sensitive.

Why

The 123456 gate is client-side — the code lives in the page bundle, so anyone who inspects the site can find it. Fine as a soft "team only" nudge, but it is not security. Cloudflare Access enforces access before any file is served, with an email allowlist and an audit log.

What gets protected: the real assets live under /hub/* — investor business case, admin MIS console, documentation, waitlist dashboard, translations and review tools. Gating /hub/* protects all of them. The marketing site at / stays public.

Cost: Cloudflare Zero Trust free plan covers up to 50 users — ample for investors + builders.

One-time setup

1 · Turn on Zero Trust

Cloudflare dashboard → Zero Trust → choose a team name (e.g. nutrisync) if prompted.

2 · Choose a login method

Zero Trust → Settings → Authentication → Login methods.

• One-time PIN is on by default — the user enters their email and gets a 6-digit code. No identity provider needed; simplest for investors.
• (Optional) add Google / Microsoft / GitHub SSO.

3 · Create the Access application

Zero Trust → Access → Applications → Add an application → Self-hosted.

• Name: NutriSync Hub
• Session duration: 24 hours
• Application domain: nutrisync-collective.pages.dev · Path: hub (covers /hub and everything under /hub/*; add the custom domain here too once F7 is done)

4 · Add the allow policy

• Policy name: Allowed viewers · Action: Allow
• Include → pick one:
• Emails — add each investor/builder address, or
• Emails ending in — @yourcompany.com for a whole domain, or
• Everyone + One-time PIN if you only need "must verify an email".
• Save the policy, then Save the application.

Done — any request to /hub/* now shows the Cloudflare Access login; only allowed emails get through. After one login the CF_Authorization cookie carries the whole session, including documents embedded in the room via iframes.

Notes & gotchas

• First hit prompts login; after that it's seamless for the session. If the room's iframed docs should load without a separate prompt, have users open any /hub/… URL once to get the cookie.
• The 123456 gate can stay or go — Access is the real lock; the on-screen code hint is already removed. Leave the gate as a harmless second step or ask Design to drop it.
• Admin data gets two layers — the Waitlist dashboard and Admin MIS console also require a Supabase admin login; Access sits in front of that.
• pages.dev works, but the cleanest setup is on the custom domain (F7) once configured — add that hostname to the same application.
• Revoking is instant — remove an email from the policy; their next request is blocked.
• Audit trail — Zero Trust → Logs → Access shows who viewed the hub and when (useful for an investor data room).

Implements backlog Epic H2 (hub access protection) and G1 (admin behind Zero Trust). Dashboard-only — no code or deploy needed.