modules
Deployment Topology
Your data stays where your lawyers say it must — with proof on every request.
Regulated operators don't get to shrug about where data lives — and auditors have learned to ask. Deployment Topology makes residency an attribute stamped on every request, audit event, and metric instead of a diagram nobody can verify. Self-hosted, cloud, hybrid, air-gapped, or edge: you choose per site, and the system proves compliance continuously.
Why topology is a runtime attribute
Regulated operators do not get to shrug about where data lives. A pharmaceutical plant, a defense supplier, and a retailer have different answers — sometimes for different sites of the same company. XRP records the chosen topology per deployment and stamps it on every request, audit event, and metric, so residency questions get answered from attributes instead of architecture diagrams.
data Viz
data View
section: thesis
Topology options
- Self-hosted and BYOC
- Data and runtime stay in your environment under your controls
- Managed dedicated and SaaS
- Babadook-operated infrastructure with hard tenant isolation
- Hybrid
- Local primary with cloud overflow or disaster recovery, cutover proven
- Air-gapped and edge
- Signed bundles, local trust roots, no public-network dependency
- section
- capabilities
Who answers for Deployment
Four roles, four anxieties, one topology record answering each.
data Viz
data View
section: personas
Section 1
col Title: CIO
col Cont: Residency proven per request instead of asserted per diagram. Mixed estates — SaaS headquarters, air-gapped plants — run one product with attributes intact.
Section 2
col Title: CFO
col Cont: Infrastructure spend matches control needs: SaaS where commodity, self-hosted where strategic, edge where operations demand it. No blanket premium for control needed in one corner.
Section 3
col Title: COO
col Cont: Plants keep running through outages with local trust roots and queued evidence. Connectivity is a sync schedule, not a survival requirement.
Section 4
col Title: Compliance Leader
col Cont: Data-residency answers come from request attributes, not architecture reviews. Examiners get continuous proof instead of annual attestations.
From hosting anxiety to proven residency
subtitle: What each stage feels like after adoption.
layout: alternating
enable Slideshow: false
slideshow Interval: 5000
Topologies declared
date: Phase 1
status: in-progress
Each site records its model with residency attributes stamped per request.
has Learn More: false
Edge goes independent
date: Phase 2
status: upcoming
Disconnected sites run on local trust with evidence queued for sync.
has Learn More: false
DR stops being theoretical
date: Phase 3
status: upcoming
Failover proves before it switches, with lineage intact across the cut.
has Learn More: false
Examiners query, not tour
date: Phase 4
status: upcoming
Residency and continuity evidence arrives as queries, not site visits.
has Learn More: false
Deployment sub-modules
subtitle: Topology chosen, performance proven.
data View: deployment-topology:sub-modules
Performance Substrate
desc: Tiered compute with receipts at every tier.
link: /sub-modules/performance-substrate
Topologies in practice
Each model below runs the same product with different residency and connectivity contracts — chosen per deployment, stamped on every request.
data Viz
data View
section: applications
Self-hosted and BYOC
Your servers or your cloud account with your controls. Upgrades on your schedule, data never leaving your boundary, full audit access to the runtime.
Managed and SaaS
Babadook-operated infrastructure with hard tenant isolation. Dedicated tenants get single-customer runtimes; shared SaaS gets row-level enforcement with the same guarantees.
Hybrid and DR
Local primary with cloud overflow or standby recovery. Replication carries evidence lineage so failover never forks the truth — cutover proves before it switches.
Air-gapped and Edge
Signed offline bundles with local trust roots for disconnected plants, vessels, and field sites. Ruggedized edge hardware runs the full ledger; evidence syncs when connectivity returns.
Deployment questions
Section 1
Can air-gapped sites still audit centrally?
Yes. Evidence bundles export with signatures and lineage for later verification without requiring a live connection.
Section 2
Can different sites use different topologies?
Yes. Topology is per deployment, so a headquarters SaaS tenant and an air-gapped plant operate under one product with their residency attributes intact.
Section 3
What happens when connectivity drops mid-shift?
Edge and offline-capable deployments keep validating against local trust roots and queue evidence for sync. No work stops waiting for the network.
Section 4
Are we locked into Babadook's cloud if we start SaaS?
No. The same product runs self-hosted with your data exportable with lineage. Topology changes are migrations with evidence, not re-implementations.
Section 5
When was DR last actually tested?
Continuously: replication carries lineage and cutover proves before switching, so the answer is always the last successful proof — not last year's tabletop exercise.
data View
section: faqs
content section
value: You choose where the runtime and data live — self-hosted, your cloud, managed dedicated, shared SaaS, hybrid, air-gapped, or ruggedized edge. Compliance and ownership ride every request as explicit attributes, not assumptions buried in a hosting contract.
Section 9
Seven deployment models from shared SaaS to air-gapped edge
Section 10
Customer-owned runtime with explicit data-residency attributes
Section 11
Signed offline bundles with local trust roots for disconnected sites
Section 12
Hybrid overflow and disaster-recovery patterns with proven cutover
Section 13
Ruggedized edge operation without public-network dependency
Section 14
Per-request topology attributes on audits, events, and metrics
Section 15
Managed dedicated isolation alongside self-hosted control
Section 16
Evidence export for central review from disconnected deployments