WF-6.11 — Website Infrastructure Decision

Type: Vendor / architecture decision Value Driver: VD6 Financial Operations (data + delivery infrastructure) → consumers across VD1–VD5 Version: 1.0 Date: 2026-05-13 Decision owner: Roger Thompson Status: Approved — Roger Thompson, 2026-05-13 Parallel to: WF-6.7 Warehouse Engine Decision, WF-6.9 Dashboard Tool Decision (same lens applied to the delivery layer)

Summary

Recommendation: Adopt Astro + Cloudflare Pages + Cloudflare Access as the website and access layer for Cedarfell. One codebase serves two sites under different access policies:

• cedarfell-logistics.com — public external site (customers, vendors, careers, about)
• portal.cedarfell-logistics.com — protected internal portal (dashboards, SOPs, KPIs, decisions, handbook) gated by Cloudflare Access against the Google identity directory Cedarfell already runs

Reject Next.js + Vercel on Vercel cost trajectory + over-build for static content; reject Hugo and Eleventy on Astro’s superior content-collection ergonomics for the SOP + KPI markdown corpus; reject Docusaurus on documentation-site framing (it’s narrower than what the portal needs); reject WordPress, Framer, Webflow, Wix, Bubble on operator-burden + git-versioning + replicability grounds. Reject Auth0, Clerk, and Supabase Auth on the basis that Cloudflare Access against Google Workspace + Cloud Identity is zero-config, $0 at our scale, and removes a vendor.

One-line rationale: Astro renders the /VD*/Workflows/*.md SOP corpus directly with zero content conversion; Cloudflare Pages hosts both sites for $0 at our scale; Cloudflare Access against the existing Google directory authenticates Roger + Vincent + Brandon + Aaliyah (all @cedarfell-logistics.com) with no third-party identity vendor; the entire stack is git-versioned, replicable per CSA in a half-day, and removes ~$2K–$5K/year of incumbent SaaS spend that competing stacks would impose.

Three-year TCO advantage over Next.js + Vercel + Auth0 (the second-most-defensible stack): approximately $10K – $25K at 1 CSA growing to $40K – $120K at 10-CSA scale, before counting Roger’s avoided operator time.

Background

Trigger. Three forces converged in the 2026-05-12 session:

1. Data layer is ahead of consumer layer. As of 2026-05-12, 47 gold/silver views are live in MotherDuck — 15+ beyond what WF-6.8 v1.0 specified. The warehouse runs; the team can’t see it.
2. Tool fragmentation has reached a point. The team’s daily knowledge artifacts live across /VD*/Workflows/*.md files in Cowork, scorecard xlsx workbooks in /Templates/, MotherDuck SQL views, Metabase Cloud (pending), Slack, GroundCloud, FRO, MBA, MyGroundBiz, Gusto, Tensor, and email. A BC starting the day must context-switch across six tools to ask “what should I do this morning.”
3. External presence is a real business surface. VD1 recruiting funnel needs a /careers page (Vincent’s Q19 self-ask); Swan Island Fleet Hub needs /customers and /vendors marketing surfaces; the MBO 2035 exit narrative benefits from Cedarfell looking like a modern operator to a future buyer.

The website infrastructure decision answers: what does the team open in the morning, and what does the outside world see?

Use case. Build one codebase that serves:

• Internal portal (portal.cedarfell-logistics.com) — single bookmark for the team. Routes: /, /dashboards, /sops, /kpis, /decisions, /handbook. Embeds Metabase dashboards as iframes. Renders the existing /VD*/Workflows/*.md corpus as readable web pages. Access-gated by Cloudflare Access against the Google directory.
• External site (cedarfell-logistics.com) — public marketing. Routes: /, /customers, /vendors, /careers, /about. Static, SEO-indexable, fast.

Both sites ship from the same git repo. Cloudflare Pages handles deployment; Cloudflare Access enforces the access boundary on the portal subdomain only.

Operator profile (unchanged from WF-6.7 / WF-6.9). Sole owner-operator (Roger) with a corporate management background; two BCs running daily ops; one Tensor bookkeeper (Jana) + one offshore bookkeeper (Sheryl); one HR/Fleet coordinator (Aaliyah, migrating to Swan Island). No internal frontend developer, no DevOps engineer, no full-stack developer — and the operating model isn’t going to support hiring one. The website infrastructure choice must let one technical builder (Roger, occasionally Claude) produce a site the non-technical team consumes without training.

Strategic constraints.

• Replicability. STR.EXIT.04 (Playbook replicability score) and STR.EXIT.06 (Data warehouse maturity) extend to the portal. A new CSA owner must clone the repo, repoint content, and deploy without specialized web skills.
• MBO 2035 exit. The stack will be in place ~9 years. Stability and lock-in tolerance matter more than novelty.
• Lock-in tolerance. Same rule as WF-6.7 and WF-6.9. Content must be portable (markdown is the universal solvent); dashboards must be portable (SQL queries against the warehouse are the source of truth); auth must be portable (we use the Google directory, not a proprietary user database).
• Cost discipline. Cedarfell is in the corrective phase and targeting 18–22% net margin. Run-rate must be sub-$1K/yr at 1 CSA. The Metabase Cloud subscription is the only line item the stack can justifiably add.

Domain + auth context (resolved 2026-05-12).

• Domain: cedarfell-logistics.com (Roger owns).
• Google directory: Cedarfell already runs Google Workspace (Roger, Vincent, Brandon) and Google Cloud Identity (Aaliyah) on the domain. All four authenticate against the same Google directory.
• Subdomain pattern: external site at apex, internal portal at portal. subdomain. Cleaner Cloudflare Access policy boundary than path-based separation.
• Cross-org access: Jana + Sheryl at Tensor will be granted portal access via Cloudflare Access exception list (their external Tensor email addresses), confirmed 2026-05-13.

Site scale (today → 2035 MBO horizon).

This is static-site scale at every horizon. Cloudflare Pages’ free tier covers 500 builds/month and unlimited bandwidth/requests. The architecture decision isn’t gated by traffic — it’s gated by content authoring ergonomics, replicability, and access boundary cleanliness.

Options evaluated

Frontend framework / static-site generator

Option A — Astro + Cloudflare Pages (recommended)

Architecture. Astro is a static-first web framework with native markdown content collections, MDX support, and an “islands” architecture (ships zero JS by default; interactive components hydrate on demand). Built by the Snowpack / Skypack team; v1.0 shipped 2022; stable v4 (2024) and v5 (2025). Cloudflare Pages is a managed static-host + edge functions platform with free-tier unlimited bandwidth and 500 builds/month.

Stack.

• Astro (open source, MIT) — content rendering + routing
• Cloudflare Pages — hosting + CDN + CI/CD
• Cloudflare Access — auth boundary (separate decision below)
• astro:content collections — schema-validated markdown ingest
• Optional: Tailwind CSS via Astro integration; React/Svelte/Vue islands if needed (not required for v1.0)

Operator fit. Excellent for the SOP corpus — markdown files in /VD*/Workflows/*.md become portal pages directly. New SOP authored in Cowork → drop in folder → next build deploys it. No CMS to operate, no database to back up.

Option B — Next.js + Vercel (or Cloudflare Pages)

Architecture. Next.js is React-based, ships with MDX support, integrates with Vercel (the company that builds Next.js) for first-class deployment. Mature ecosystem; very heavily used in 2026.

Stack.

• Next.js (open source, MIT) — full-stack React framework
• Vercel — hosting (Next.js’s home), or Cloudflare Pages with Next-on-Pages adapter
• MDX, Tailwind, etc.

Operator fit. More than we need. Next.js shines for server-rendered React apps with dynamic data; the portal is a static-rendered SOP corpus plus iframe-embedded dashboards. Next.js’s complexity (App Router, Server Components, edge runtime nuances) is operator burden Cedarfell doesn’t need.

Option C — Hugo

Architecture. Go-based static site generator. Famously fast builds. Mature ecosystem since 2014.

Stack.

• Hugo (open source, Apache 2.0)
• Same hosting options as A/B

Operator fit. Good for traditional blog/docs sites. Content authoring ergonomics weaker than Astro for our shape — Astro’s content collections + schema validation catch errors at build time (e.g., a SOP that’s missing its owner front matter fails the build). Hugo handles this via shortcodes and partials, less elegantly. Hugo’s templating language (Go templates) has a steeper learning curve than Astro’s component syntax for anyone who might collaborate later.

Option D — Eleventy (11ty)

Architecture. Node-based, “the unframework,” 2017. Embraces simplicity; multi-templating-engine support.

Stack.

• Eleventy (open source, MIT)
• Same hosting options as A/B/C

Operator fit. Minimalist by design. Less ecosystem momentum than Astro post-2023 — Astro overtook Eleventy as the default static-first framework choice. Eleventy still ships and is well-maintained, but the community + plugin density favors Astro for any non-trivial site.

Option E — Docusaurus

Architecture. Meta/Facebook-built, React-based, designed specifically for documentation sites.

Stack.

• Docusaurus (open source, MIT)
• Hosting same as A/B/C/D

Operator fit. Excellent for documentation; too narrowly scoped for the portal we need. Docusaurus assumes “this site IS the docs.” We need the portal to be docs + dashboards + decisions + handbook + landing pages — five different surface types with shared navigation. Astro flexes across all five.

Option F — WordPress

Architecture. PHP + MySQL CMS. Powers ~40% of the web. Mature, plugin-rich.

Stack.

• WordPress.org self-hosted, or WordPress.com managed
• Theme + plugins
• Plus separate auth for the protected portal

Operator fit. Wrong shape for Cedarfell. WordPress is a content management system with database-backed posts and pages — content authoring happens inside WordPress, not in git. Our SOPs already live in markdown in Cowork. Importing them into WordPress means losing the git audit trail, the Cowork edit workflow, and the Claude/AI assistance pattern. Plus WordPress requires database hosting, plugin update vigilance, and security hardening — operator burden Cedarfell can’t carry.

Option G — Framer / Webflow

Architecture. Visual site builders. Drag-and-drop design, managed hosting, internal CMS.

Stack.

• Framer (recently expanded with CMS + auth in 2024) or Webflow
• Optional code injection but core is visual

Operator fit. Great for design-led marketing sites; wrong for SOP corpus. Cedarfell’s SOPs are written content that should remain in markdown. A visual builder loses the markdown source-of-truth and the git workflow. Either tool would work for the external site alone, but maintaining two stacks (one for external, one for internal) doubles operator burden and breaks the replicability story.

Option H — Wix

Architecture. Hosted visual site builder, opinionated, mass-market.

Stack.

• Wix
• Optional Velo (JS) for advanced

Operator fit. Bottom-tier fit. Wix is for small businesses with no developer and no content workflow. Cedarfell has a content workflow (Cowork → markdown → git) and benefits from version control on every change. Wix would force re-authoring SOPs inside Wix’s editor. Hard pass.

Option I — Bubble

Architecture. No-code application builder. Database + workflows + UI all visual.

Stack.

• Bubble platform
• Plugins for custom integrations

Operator fit. Wrong category. Bubble is for building applications, not content sites. We have an application layer (Metabase, the warehouse, the parsers); we need a content + delivery layer. Bubble overlaps zero with the actual need.

Hosting (separate axis)

Option α — Cloudflare Pages (recommended)

Pricing. Free tier: 500 builds/month, unlimited bandwidth + requests, unlimited collaborators on the free plan, custom domains, automatic HTTPS, preview deployments per branch. Workers Paid plan ($5/mo) adds more build minutes and Workers compute if needed.

Operator fit. Excellent — and integrates natively with Cloudflare Access, which is the auth boundary we want anyway. One vendor for hosting + auth + CDN + DNS (if we move nameservers).

Option β — Vercel

Pricing. Hobby tier free for personal use only; commercial use requires Pro at $20/user/mo. Bandwidth metering kicks in: 1 TB included on Pro, ~$0.15/GB overage. At Cedarfell’s scale today bandwidth is moot, but at 25-CSA scale Vercel could become a $1K–$3K/yr line item.

Operator fit. Best Next.js experience by far (Vercel = Next.js’s creators). Excellent DX. Cost trajectory is the concern — Vercel’s growth-stage pricing pressure has been documented in 2024–2026; Cloudflare Pages stays free at our scale.

Option γ — Netlify

Pricing. Free tier covers small projects; Pro $19/user/mo; bandwidth metered at 100 GB free, $55/100 GB after. Build minutes capped on free tier.

Operator fit. Good. Cost trajectory same concern as Vercel — bandwidth-and-seats pricing model penalizes growth.

Option δ — AWS S3 + CloudFront

Pricing. S3 ~$0.023/GB + CloudFront ~$0.085/GB outbound at typical tiers. At 100 GB/mo (25-CSA scale) ~$10/mo. Sub-$5/mo at 1 CSA.

Operator fit. Cheapest at scale; highest operator burden. Requires AWS IAM, S3 bucket policies, CloudFront distribution config, cache invalidation discipline, OAI / OAC setup for private access. Same DevOps burden penalty WF-6.7 applied to Redshift. Hard pass on consistency grounds.

Option ε — GitHub Pages

Pricing. Free.

Operator fit. No native auth boundary — GitHub Pages serves public sites only. To protect the portal we’d need to deploy private content separately or front it with Cloudflare Access via a workaround. Better to use Cloudflare Pages directly and skip the workaround.

Authentication (separate axis)

Option I — Cloudflare Access + Google IdP (recommended)

Architecture. Cloudflare Access (part of Cloudflare’s Zero Trust platform) gates any Cloudflare-fronted domain or subdomain. Configure once: identity provider = Google; allowed = @cedarfell-logistics.com plus an exception list of explicit external emails. Users hitting portal.cedarfell-logistics.com see a Google sign-in prompt, then the portal. Sessions are JWT-based, configurable duration (default 24 hours).

Pricing. Free tier covers up to 50 users. Beyond 50 users: $7/user/mo on Zero Trust Pay-As-You-Go. At Cedarfell’s 1-CSA scale: $0. At 10-CSA scale with ~30 users: $0 (still under 50). At 25-CSA scale with ~75 users: ~$200/mo = $2,400/yr.

Operator fit. Zero-config integration with Google Workspace + Cloud Identity. Both Workspace and Cloud Identity users authenticate via the same Google OIDC flow. Aaliyah’s Cloud Identity is treated identically to Roger’s Workspace identity. Exception list (Jana, Sheryl) is two clicks in the Cloudflare dashboard.

Why this beats every third-party auth tool for Cedarfell: the identity directory already exists (Google Workspace + Cloud Identity), Cloudflare already gates the domain (Cloudflare Pages hosts the portal), and the integration is OIDC-standard. Adding Auth0/Clerk/Supabase Auth would mean (a) a new vendor relationship, (b) a new user-management UI to maintain, (c) duplicate identity records, and (d) a per-user cost trajectory that worsens as Cedarfell grows.

Option II — Auth0

Architecture. Okta-owned managed identity platform. Industry standard for SaaS.

Pricing. Free tier covers 7,500 active users (B2C plan) — generous on raw numbers but enterprise SSO features that we’d want (custom domains, advanced policies) start at the Essentials plan ~$240/mo at 1,000 users. B2B SSO plans escalate quickly.

Operator fit. Excellent product. Wrong product for this use case — we don’t need Auth0’s customer identity capabilities; we need to verify “this person belongs to Cedarfell.” Cloudflare Access already does that against the existing Google directory for $0.

Option III — Clerk

Architecture. Developer-friendly auth-as-a-service. Pre-built UI components; React-first.

Pricing. Free tier 10,000 monthly active users; Pro $25/mo + per-user fees beyond included tier.

Operator fit. Good for SaaS apps with end-user signup flows. Same wrong-shape problem as Auth0 — Cedarfell doesn’t have a user signup flow; users are pre-defined Cedarfell employees + Tensor bookkeepers.

Option IV — Supabase Auth

Architecture. Open-source Firebase alternative. Auth is one component of a larger Postgres-backed platform.

Pricing. Free tier covers 50,000 monthly active users; Pro $25/mo.

Operator fit. Pulls Cedarfell into the Supabase ecosystem (database, storage, edge functions). Over-build for an auth-only need. If we ever need a real backend application (we don’t), Supabase becomes interesting. For website auth: redundant with Cloudflare Access.

Option V — NextAuth.js / Auth.js (self-host)

Architecture. Open-source auth library, framework-integrated.

Pricing. $0.

Operator fit. Requires building + maintaining the auth wiring. Cloudflare Access is configuration, not code. Hard skip.

Cost analysis (Total Cost of Ownership)

All figures USD/year unless noted. Mid-range vendor pricing as of 2026-05.

TCO at 1 CSA (today)

TCO at 5 CSAs (portfolio, ~2030)

TCO at 10 CSAs (~2031)

TCO at 25 CSAs (MBO 2035 exit)

Cumulative 2026–2035 (delta retained as margin vs. Next.js + Vercel + Auth0)

Mid-case projection weighted by likely CSA trajectory:

• Option A+α+I (Recommended) cumulative: ~$15K – $30K
• Option B+β+II (Next.js stack) cumulative: ~$100K – $200K
• Option F (WordPress) cumulative: ~$120K – $250K
• Margin retained by going A+α+I vs B+β+II: ~$85K – $170K over ten years
• Margin retained by going A+α+I vs F: ~$105K – $220K over ten years

The savings compound because each new CSA adds zero hosting cost and zero auth cost on the recommended stack until we cross ~50 users (~10 CSAs).

Risk assessment

Aggregate risk. Option A+α+I presents the lowest aggregate risk of any combination evaluated. The only meaningful risks are #3 (auth misconfiguration, mitigated by staged rollout) and #7 (BC adoption, mitigated by portal-first sequencing). Both are operational risks the team can manage.

Performance considerations

Page load. Cloudflare Pages serves static HTML from edge POPs globally. Time-to-first-byte under 100 ms in North America. Astro ships zero JavaScript by default — page loads are HTML + CSS only unless an interactive component is on the page. Average portal page load: < 1 second.

Build times. Astro builds ~50 pages in under 10 seconds locally; production build on Cloudflare Pages typically ~30–90 seconds for the size of corpus we’ll have. 500 builds/month free tier covers ~16 deploys/day — more than enough headroom.

Dashboard latency. Iframe-embedded Metabase dashboards load from cedarfell.metabaseapp.com (or the custom domain we configure later). Latency is whatever Metabase Cloud delivers (~1–3 seconds for a typical Daily BC dashboard page per WF-6.9). Cloudflare doesn’t gate the iframe load — Metabase serves the dashboard directly to the browser, sharing the user’s session.

Auth latency. Cloudflare Access redirects unauthenticated users to Google sign-in (~500 ms round trip) and then back to the portal. After sign-in, the JWT cookie persists for 24 hours by default — subsequent page loads have no auth latency. Acceptable for the morning-bookmark use case.

Mobile. Astro renders the same HTML to mobile and desktop. Tailwind (if adopted) makes responsive layouts trivial. BCs checking the portal from phones at the belt — supported.

Strengths and concerns per option

Option A — Astro + Cloudflare Pages + Cloudflare Access (Recommended)

Strengths

• Markdown-native — /VD*/Workflows/*.md files become portal pages with zero conversion
• Zero JS shipped by default — portal stays fast and accessible
• One vendor for hosting + auth + DNS + CDN — Cloudflare consolidates four bills into zero
• Auth runs on the identity directory Cedarfell already pays for (Google Workspace + Cloud Identity)
• Replicable per CSA in literally minutes (git clone + Cloudflare Pages connect + Cloudflare Access policy)
• Open source — escape hatch if Cloudflare changes terms (move to any static host)
• Excellent DX for the Roger / Claude workflow (markdown + git + simple component model)
• Schema validation on content collections catches SOP authoring errors at build time
• Stable, well-maintained, growing ecosystem in 2026

Concerns

• Astro v5 is current; framework will continue evolving (mitigated by content portability)
• One vendor risk concentrated on Cloudflare for hosting + auth + DNS (mitigated by each component being independently replaceable)
• BCs need to learn one new URL (portal.cedarfell-logistics.com) — minor

Option B — Next.js + Vercel + Auth0

Strengths

• Best-in-class React DX
• Mature ecosystem with strong talent pool
• Auth0 is industry standard for SSO

Concerns

• Cost trajectory penalizes growth (Vercel seats, Auth0 tiers)
• Server-rendered React is over-build for static SOP content
• Auth0 ecosystem lock-in for user management
• Next.js complexity (App Router, Server Components) is operator burden

Option C — Hugo + Netlify + Clerk

Strengths

• Hugo is mature and very fast
• Netlify has good DX

Concerns

• Hugo’s Go templates are clunkier than Astro components
• Less ecosystem momentum than Astro since 2023
• Three vendors instead of one

Option D — Eleventy

Strengths

• Simplest possible static-site approach
• Mature

Concerns

• Smaller community than Astro
• Less feature density for content collections, MDX, etc.

Option E — Docusaurus

Strengths

• Excellent for pure docs sites

Concerns

• Docs-site shape doesn’t fit the portal’s five surface types

Option F — WordPress

Strengths

• Mature CMS
• Vast plugin ecosystem

Concerns

• Database + plugin maintenance burden
• Content lives in WordPress, not git — breaks the Cowork workflow
• Security exposure (WP is the #1 attacked platform on the web)
• Hosting costs add up at multi-CSA scale

Option G — Framer / Webflow

Strengths

• Beautiful design output
• No-code authoring

Concerns

• Wrong shape for SOP corpus
• Doesn’t integrate with git workflow
• Maintaining two stacks (one for external, one for internal) doubles operator burden

Option H — Wix

Strengths

• Easiest possible setup

Concerns

• Wrong product for any business with a content workflow

Option I — Bubble

Strengths

• Powerful no-code app builder

Concerns

• Wrong category — we need content + delivery, not application

Recommendation

Proceed with Option A + α + I — Astro + Cloudflare Pages + Cloudflare Access (Google IdP).

This decision optimizes for what matters at Cedarfell’s scale and trajectory: markdown-native authoring (preserves the Cowork workflow and the existing SOP corpus), zero-config auth against the identity directory we already pay for, $0 hosting at our scale, replicable per CSA without specialized skills, and lock-in shape that’s configuration-level rather than code-level. Open-source escape hatches limit Cloudflare-specific risk to near-zero.

Reject Options B (Next.js + Vercel + Auth0), C (Hugo + Netlify + Clerk), D (Eleventy), E (Docusaurus) as competent but over-built or under-fitted relative to Astro for our specific content shape and operator profile.

Reject Options F (WordPress), G (Framer/Webflow), H (Wix), I (Bubble) on operator-burden + git-workflow + cost-trajectory grounds.

Reject Auth0, Clerk, Supabase Auth, NextAuth as redundant with Cloudflare Access against the Google directory Cedarfell already maintains.

Negotiation points (Cloudflare + Google specifically)

When subscribing to / configuring these vendors:

1. Cloudflare free tier headroom. Confirm Pages free tier covers 500 builds/month, unlimited bandwidth, unlimited collaborators. Cedarfell stays inside the free tier through 10-CSA scale.
2. Cloudflare Access free tier headroom. Confirm 50-user free tier. At 75+ users (likely past 15-CSA scale), Zero Trust Pay-As-You-Go at $7/user/mo is the next tier.
3. Cloudflare Registrar. If we move the domain to Cloudflare Registrar, we get at-cost domain renewal (no markup over wholesale). Migration is one-time and saves $5–15/yr vs typical retail registrars.
4. Google Workspace seat audit. Confirm Vincent + Brandon are on Workspace (likely $6/user/mo Business Starter) vs Cloud Identity (free). If they’re on Workspace and only need email + identity, downgrade-to-Cloud-Identity is worth ~$144/yr savings — but Workspace’s other features (Drive, Calendar, Meet) may be worth keeping.
5. Aaliyah Cloud Identity status. Confirm she’s on Cloud Identity Free (no cost) or Cloud Identity Premium ($6/user/mo). Free is sufficient for our auth use case.
6. Cloudflare Access bypass token. Configure a break-glass access path (e.g., Roger’s home IP allowlisted + a service token for emergency access) before launch. Documented in WF-6.12.
7. Cloudflare SOC 2 attestation. Available under NDA. Request before any future buyer or contract review (MBO 2035 narrative).

Implementation impact

The following artifacts will be created or updated based on this decision:

The dev repo (cedarfell-warehouse) doesn’t change from this decision — the warehouse layer is unaffected. The portal is a new repo (cedarfell-portal working name) that lives separately and embeds Metabase dashboards by URL.

Decision and sign-off

Cross-references

• WF-6.4 Scorecard Data Acquisition Plan — /VD6 - Financial Operations/Workflows/
• WF-6.7 Warehouse Engine Decision — /VD6 - Financial Operations/Workflows/ (sibling decision; engine layer)
• WF-6.8 Gold View Map — /VD6 - Financial Operations/Workflows/ (data layer the portal consumes via Metabase)
• WF-6.9 Dashboard Tool Decision — /VD6 - Financial Operations/Workflows/ (sibling decision; BI tool that embeds inside portal)
• WF-6.10 Dashboard Layer Plan (proposed) — per-dashboard scope
• WF-6.12 Internal Portal Build Plan (proposed) — implementation of this decision
• KPI Taxonomy v1.1 — /Strategic/ (metric definitions surfaced in portal /kpis route)
• Decision Catalogue — /VD6 - Financial Operations/Data/ (rendered as portal /decisions route)
• Scorecard Templates v1.0 — /Templates/ (target layouts for dashboards)
• Decisions-Log.md — entry dated 2026-05-13 for this decision

Change log

Appendix A — Reference architecture (target state)

                              ┌──────────────────────────────────────────────┐
                              │   GIT REPOSITORY  `cedarfell-portal`         │
                              │   (one repo, both sites)                     │
                              │   ─────────────────                          │
                              │   src/content/                               │
                              │     sops/         ← reads /VD*/Workflows/    │
                              │     kpis/         ← reads /Strategic/        │
                              │     decisions/    ← reads /VD*/Data/         │
                              │     handbook/                                │
                              │   src/pages/                                 │
                              │     index.astro                              │
                              │     dashboards.astro  ← Metabase iframes     │
                              │     customers.astro    (external)            │
                              │     vendors.astro      (external)            │
                              │     careers.astro      (external)            │
                              │     about.astro        (external)            │
                              │   astro.config.mjs                           │
                              │   src/content/config.ts                      │
                              └──────────┬───────────────────────────────────┘
                                         │ git push → Cloudflare Pages build
                                         ▼
                              ┌──────────────────────────────────────────────┐
                              │   CLOUDFLARE PAGES                           │
                              │   ────────────────                           │
                              │   Auto-build on push                         │
                              │   Static asset CDN (global edge)             │
                              │   Custom domain wiring                       │
                              └──────────┬───────────────────────────────────┘
                                         │
                ┌────────────────────────┴──────────────────────────┐
                ▼                                                   ▼
   ┌──────────────────────────────────┐         ┌────────────────────────────────────┐
   │  cedarfell-logistics.com         │         │  portal.cedarfell-logistics.com    │
   │  (PUBLIC external site)          │         │  (PROTECTED internal portal)       │
   │                                  │         │   ↑                                │
   │  /         landing               │         │   │ Cloudflare Access              │
   │  /customers                      │         │   │   ─────────────                │
   │  /vendors                        │         │   │  Identity Provider:            │
   │  /careers   (lead capture)       │         │   │    Google Workspace            │
   │  /about                          │         │   │    Google Cloud Identity       │
   │                                  │         │   │  Policy:                       │
   │  No auth                         │         │   │    Allow @cedarfell-logistics  │
   │  SEO-indexable                   │         │   │    + jana@tensor + sheryl@tensor│
   │                                  │         │   ▼                                │
   │                                  │         │  /          team home              │
   │                                  │         │  /dashboards   (Metabase iframes) │
   │                                  │         │  /sops                             │
   │                                  │         │  /kpis                             │
   │                                  │         │  /decisions                        │
   │                                  │         │  /handbook                         │
   └──────────────────────────────────┘         └────────────────────────────────────┘
                                                              │
                                                              │ iframe embed
                                                              ▼
                                                  ┌─────────────────────────┐
                                                  │  METABASE CLOUD         │
                                                  │  ────────────           │
                                                  │  Dashboards (per WF-6.9)│
                                                  │  Queries against        │
                                                  │  MotherDuck (WF-6.7)    │
                                                  └─────────────────────────┘

Appendix B — Per-CSA replication pattern

A new CSA owner buying into the Cedarfell playbook gets a working portal in under half a day:

1. Clone repo. git clone cedarfell-portal csa-name-portal
2. Repoint content. Update src/content/config.ts glob paths to read from their own /VD*/Workflows/*.md. Update astro.config.mjs site URL.
3. Create Cloudflare Pages project. Connect to GitHub; auto-deploy main branch. ~5 minutes.
4. Add custom domains. Add csa-name.com apex + portal.csa-name.com subdomain in Cloudflare Pages dashboard. ~5 minutes.
5. Configure Cloudflare Access policy. Add the portal subdomain as a protected application. Identity provider = Google. Allowed = @csa-name.com directory + any exception list emails. ~10 minutes.
6. Connect Metabase Cloud. Either share existing Metabase Pro workspace via a CSA-scoped collection, or subscribe to a new Metabase Cloud Starter for that CSA. Embed dashboard URLs in /dashboards.astro. ~30 minutes.
7. DNS. Point the new domain’s nameservers at Cloudflare. ~10 minutes (plus propagation).
8. Test. Visit portal subdomain → auth flow works → SOPs render → dashboards load. ~30 minutes.

Total per-CSA setup: half a day. Total per-CSA cost: $0 hosting + $0 auth (until 50-user threshold) + Metabase Cloud subscription (~$1K/yr per WF-6.9).

This directly satisfies STR.EXIT.04 (Playbook replicability score) — every CSA has the same portal architecture, the same auth model, and the same dashboards.

Appendix C — Vendor financial stability snapshot

Concentration risk note. Cloudflare is the consolidated dependency in the recommended stack (Pages + Access + DNS). The mitigation: each component is replaceable independently. Hosting can move to any static host in a day. Auth can move to any OIDC provider in an afternoon. DNS can move to any registrar in an hour. The data layer (MotherDuck, per WF-6.7) and the BI layer (Metabase Cloud, per WF-6.9) sit entirely outside Cloudflare and aren’t affected by any Cloudflare-side event.