Operational Architecture

Operational Architecture

Sardine is where the site is managed; the public site is served elsewhere. Publication is a cycle, never a one-off export: edit in the panel → build → publish to the configured destination → the destination serves the public site → further changes republish to the same destination.

flowchart LR
    A[Admin panel<br/>editors, workflow, preview] --> B[(Editorial storage<br/>SQLite / PostgreSQL / MySQL / MSSQL)]
    B --> C[Deterministic build<br/>same content, same bytes]
    C --> D[Deployment target / provider<br/>host extras + transport]
    D --> E[Public hosting<br/>SWA, Nginx, S3, Pages, Netlify, …]
    E -.->|readers| F((Public site))
    A -->|republish after every change| C

Loading

The five pieces

Piece	Role	Notes
Admin panel	Where content is created, edited, reviewed and published	Never needs to serve the public site; can live on a laptop or private network
Editorial storage	The working store behind the panel	Four engines, one conformance-tested contract; the portable JSON/Markdown export stays the source of truth
Build	Editorial state → static artifact	Deterministic: same content + same clock → identical bytes; validation gates publication
Deployment target / provider	Shapes and (with #152) transports the artifact	swa, nginx, generic bundled; extensions add destinations (sardine-target-<name>)
Public hosting	Serves the site	Azure Static Web Apps, your own Nginx, S3/CloudFront, GitHub Pages, Netlify, any static host

Provider phases

Generation (✅ shipped) → Transport → Activation → Health check → Rollback (🔜 #152 brings the last four into the panel; today the transport leg is your pipeline or the host's CLI). Details and host-specific examples: the repository's docs/DEPLOYMENT.md.