© 2026 LyDos · Stop prompting. Start orchestrating.
LyDos is sovereign, not multi-region
Each customer gets a single isolated deployment with no cross-region replication and no shared control plane. We chose isolation over distribution because data residency matters more than CDN latency.
What sovereign means architecturally
13 sovereign engines, isolation-first by design
The sovereign stack — DPI, LocalSec, DPI-H, CC, FIN, LSSA, KSL, TUP, GCE, ASR, DSL, LSIA, GCI — is built around three invariants: KSL device-bound signing (KURAL 18), DSL settlement single-writer per tenant (KURAL 22), and GCI privacy-preserving federation that explicitly limits cross-node data sharing to hashed patterns only (KURAL 23). Multi-region active-activewith shared control plane fights these invariants.
Why we chose isolation over distribution
Big Cloud SaaS optimizes for global CDN-like ubiquity. We optimize for cryptographic provenance and per-deployment trust. A multi-regionactive-active deployment introduces split-brain failure modes, eventualconsistency edge cases, and consensus complexity our customers don't want. Customers in regulated industries (healthcare PHI, EU data residency, defense) actively prefer isolation — it simplifies their compliance story.
What we offer instead: deployment locality
Customer-chosen deployment region (Frankfurt, Virginia, Singapore VPS on demand). Today we run from Hetzner Helsinki; additional regions deploy when a customer requests them. Each customer is a single isolated sovereign deployment — no cross-region replication, no shared control plane, no GeoDNS routing for the same tenant across regions. Plus air-gapped and on-prem options (Sprint 4 PART A).
Honest disclosure: current production state
Production status: controlled_beta — limited audience, not full GA. We run a single-VPS deployment today (Hetzner Helsinki). The 13-engine sovereign stack is architecturally complete; the multi-nodequorum primitives in DPI and GCE are wired but exercised on a single node, so quorum guarantees are structural rather than empirically validated under multi-nodeload.
Q229 (Multi-Region Routing): planned for Q4 2026. The router source code exists but multi-region active-active is not deployed and we willnot ship it before its trust framework (cross-region attestation, RPO/RTO targets, data-residency proofs) is published. We disclose this here because Sprint 24's verification audit found two generic mentions of “multi-region”on this page without the explicit “planned” qualifier — that omission was a D7.1 underclaim and is fixed by this paragraph.
Big Cloud SaaS vs Sovereign LyDos
| Dimension | Big Cloud SaaS | Sovereign LyDos |
|---|---|---|
| Deployment topology | Multi-region active-active; shared control plane | Single isolated deployment per customer; deployment locality on demand |
| Data residency | Replicated across regions (eventual consistency; eventually-everywhere) | Single region per customer; data never leaves chosen jurisdiction |
| Control plane | Shared multi-tenant management plane | Per-customer sovereign deployment; no shared control surface |
| Failure mode | Cross-region split-brain risk under partition; consensus complexity | Single-deployment failure isolated to one customer; no cascade |
| Customer key custody | Provider-managed KMS (BYOK optional) | KSL device-bound signing — private key never leaves customer device |
| Audit chain | Provider audit logs (typically eventually-consistent) | Hash-chained ASR audit per deployment; cryptographically tamper-evident |
| Regulator alignment | Generic SOC 2; cross-region compliance complexity | Per-jurisdiction deployment fits EU data residency, HIPAA PHI residency, FedRAMP path |
| Roadmap commitment | Eventual everywhere | Customer-chosen region (Frankfurt, Virginia, Singapore on demand); no multi-region active-active |
Customer fit guide
We'd rather tell you up-front whether we're the right tool for your use case.
Decision rationale (full document)
This page is the public statement of an architectural decision recorded internally on 2026-05-05. The full decision document — including the three options considered (Q4 2026 commit / indefinite postponement / strategic pivot) and why we chose the sovereign-by-design path — is published with our audit artifacts.