Skip to main content

Developer portal — hosting & authentication (deferred)

Date: 2026-06-21 · Status: Decided — auth deferred (not a launch blocker)

Context

The developer portal (Docusaurus — developer docs + the design_system Widgetbook

  • the flow-test gallery) is live at developer.eldr-labs.duckdns.org, served by the local Caddy container → a host :8002 Python static server over the production app/test-gallery/build/ bundle. It is currently public (no auth) on both the LAN and the DuckDNS subdomain.

The content is internal-facing developer/design material — architecture notes, component reference, and flow-test screenshots rendered from a seeded demo household (no real user data, no secrets). So public exposure today is low-risk.

Decision

  1. Authentication / restricted external availability is NOT required to ship the app. It is explicitly deferred. The portal staying public for now is acceptable (no sensitive data on it).
  2. Long-term the portal moves to Cloudflare (consistent with the marketsite, already a CF Worker). Auth is added then, at the edge.
  3. Auth belongs at the edge, never inside Docusaurus. Docusaurus is a static site — any in-site "auth" is client-side only and does NOT protect content (the gated pages still ship in the downloaded bundle). Real protection is an identity-aware proxy in front of the static assets.

Options (for the eventual Cloudflare move)

OptionWhat it isFit
Cloudflare Access (Zero Trust)Identity-aware proxy at the edge; login before the request reaches the site; signed JWT cookie. Path-scoped policies; email OTP or Google/GitHub/Microsoft/OIDC SSO; free tier (~50 users).Recommended. No code in Docusaurus; gate the whole host OR just a path.
Cloudflare Pages (host) + AccessGit-connected static builds + preview deploys, with native Access integration.Recommended host for the static site.
Worker-managed authAuth logic in a Worker (validate a cookie/JWT, Basic Auth, or verify the Access JWT).Only if Access can't express the policy.
WAF custom rules / IP allow-listRestrict by IP/country at the edge — not real auth.Coarse; brittle for remote access.
Interim: Caddy basic_auth / forward_authWhile still on Caddy/DuckDNS, gate the subdomain or a path (the Caddyfile already declares order rate_limit before basic_auth).Quick win if a gate is needed before the CF migration.

Cloudflare Pages + Cloudflare Access, with a path-scoped policy on an internal subtree (e.g. /developer/internal/*) so the portal stays public but sensitive pages require login (email OTP → Google/GitHub SSO). On the Docusaurus side that's just a folder + _category_.json; on the CF side it's one Access application. Zero in-site code.

Consequences

  • Now: the portal is public on developer.eldr-labs.duckdns.org + LAN; no auth; not version-controlled at the proxy (the Caddy block + :8002 server live on disk only — see scripts/deploy-developer-gallery.sh).
  • Later: migrate to Cloudflare Pages, front it with Access, introduce the /developer/internal/ convention for anything that should be private.
  • Not a launch blocker — revisit at the Cloudflare migration, not before.