Architecture

TurboPanel splits documentation by concern:

• Development architecture — Multi-repo Vagrant layout, dev console orchestration, schema sync in dev, ports, and technology choices.
• The Compose contract — TurboPanel as a Compose implementation: one extension namespace (x-turbopanel), the canonical place for each concern, and the four-model compiler pipeline (authored → application → resolved → per-server deployment).
• Instance API — Versioned surfaces, routing modules, compose/deploy model with x-turbopanel server placement, secret envelopes (tpsecret at rest / tpdaemon at delivery), and how requests flow through the turbopanel instance repo.
• Daemon cell — SQLite-backed Durable Object cell, hibernation, billing model, and Redis parity for self-hosted mode.
• Server metrics — Shared host-metrics contract, Analytics Engine / DuckDB + Parquet storage, retention, and the dated Cloudflare cost model. What each console chart means: Server metrics glossary.
• Managed database ingress — Per-server ProxySQL (ports 15432/13306), org-CA TLS, bindings, private backends, and replica/failover semantics.
• TurboFabric path model — Six path states, direct-then-gateway-then-relay selection, and the allowRelay tightening-only policy.
• Storage architecture — The four storage workload classes, which backend serves each on TurboPanel High Availability and self-hosted, and why keyed objects, relational rows, and time-bucketed analytics stay separate.
• Deployment logs — The ExecutionLogStore contract, daemon spool durability, redaction before disk, append/offset reads, 90-day retention (the only log class TurboPanel stores), and the R2 / filesystem / S3 drivers.
• Container logs — Container logs are not retained: live tail via the daemon, no storage, and how to ship logs off-host yourself.

For deployment and production operations, see Deployment and Security.