Technical Reference
System Architecture
MP-OPT deliberately separates local planning from published distribution. The desktop project database is not the server database, and publishing is an explicit data transfer.
From a planning idea to everyone's calendar
Planning stays local until you deliberately publish a finished schedule.
Desktop app
Define, optimise, review, and finalise
MP-OPT Server
Private masterplan and public General Schedule
Google Calendar
Personal calendar distribution
Light A4 portrait schedule with printable task details
People and organisers
Browser, installed web app, or calendar
Complete MP-OPT ecosystem
Planning, authenticated access, public access, delivery, availability and evidence remain separate domains.
Desktop App
Local planning, optimisation, publishing and event-scoped processor signing
External recovery storage
Encrypted exported snapshots; private AGE identity stays with the operator
Self-hosted Server
Node A
Caddy, frontend, API and PostgreSQL
Node B (HA)
Verified peer recovery point and failover target
Cloudflare
DNS, load balancer and bounded witness
Evidence repository
Append-only public verification material
Browser and phone/PWA
Passkey-authenticated Masterplan or bearer Public Schedule
SMTP and Google Calendar
Optional controller-declared delivery and calendar providers
Desktop boundary
The packaged desktop application uses Electron as its shell. It starts the Next.js interface and one local FastAPI backend. The optimisation API is mounted into that backend under /compute; it is not a separately operated network service.
Planning data is stored in a local SQLite database. Electron generates a new high-entropy backend token for each launch and injects it into local requests. Integration secrets are stored through the operating system credential store rather than portable project exports.
Published server boundary
The server deployment places Caddy in front of FastAPI and PostgreSQL. Browsers and the desktop publisher use HTTPS. Caddy terminates TLS and applies the public request boundary; FastAPI authenticates, authorises, validates, audits, and persists server data.
The server holds only data deliberately published or created through the web application. Private masterplan data requires authenticated access. A General Schedule or public schedule link exposes only the intentionally public representation.
External dependencies
Network and service dependencies
Public, authority, replication, and notification traffic use separate paths and credentials.
Browsers and desktop publisher
Public HTTPS only
Cloudflare load balancer
HTTPS and /ha/ready checks in HA
Caddy and FastAPI
TLS boundary, API, authentication, and authorisation
Local PostgreSQL
Not exposed as a public service
Witness
Outbound lease, heartbeat, and permit traffic
Peer VPS
Authenticated SSH replication
Optional providers
Outbound SMTP, web push, and Google APIs
| Dependency | Purpose | If unavailable |
|---|---|---|
| Google Calendar | Optional distribution target | Local planning and MP-OPT Server publishing remain independent |
| SMTP and web push | Optional invitations and notifications | Core stored schedules remain available |
| Cloudflare | HA writer witness and public load balancing | In HA, the last holder may serve reads but writes fail closed when authority cannot be proven |
| External snapshot storage | Independent disaster-recovery copy | The live service may continue, but total-site recovery is no longer assured |
Continue with the data lifecycle or the security model.