Skip to content
Documentation

Platform Architecture Overview

The RCS web platform consists of two Astro applications that share a pnpm workspace and Docker-based developer workflow. This page captures the current-state architecture so engineers, stakeholders, and auditors understand how the pieces interact today and where we plan to grow.

Core Components

Section titled “Core Components”
  • Public Website (apps/site) — Astro 6.0.0-beta.3 experience for external audiences. Serves marketing content, launch announcements, and static assets.
  • Internal Documentation (apps/docs) — Astro 5.16.15 with Starlight 0.37.4. Houses architecture, security, and operational guidance for internal teams only.
  • Docker Developer Environment — Provides consistent tooling (Node, pnpm, D2 WASM via client-side libraries) and exposes ports 4321 (site) and 4322 (docs).
  • Cloudflare Pages (future) — Static hosting for both applications. Docs will be gated by Cloudflare Access once implemented.

Boundaries & Trust Zones

Section titled “Boundaries & Trust Zones”
  • Public Boundary — External users interact only with the marketing site. No internal APIs are exposed.
  • Internal Boundary — Documentation app, ADRs, and security narratives are restricted to authenticated staff. Access controls will be enforced when deployed.
  • Local Boundary — Docker isolates dependencies and prevents host-level pollution. Developers still treat their machines as untrusted; secrets stay out of the repo.

Refer to the System Context diagram and the Deployment topology for visual breakdowns.

Platform Goals

Section titled “Platform Goals”
  1. Maintain a static-first deployment path to minimise operational overhead.
  2. Keep internal knowledge authoritative and tightly controlled.
  3. Allow marketing to iterate quickly on Astro 6 while the docs site maintains Starlight compatibility.
  4. Prepare for Cloudflare Workers and supplementary services without committing until requirements harden.

Future Considerations

Section titled “Future Considerations”
  • Expand the architecture workspace once backend services come online (e.g., Worker-based BFF, analytics pipelines).
  • Review CDN configuration and security headers ahead of the first Cloudflare deployment.
  • Revisit architecture quarterly to confirm diagrams and documentation remain accurate.