Business Continuity
& Disaster Recovery
Architecture, backup strategy, recovery targets, and the honest state of multi-region capability. Public summary — full operational runbook available to enterprise customers under NDA.
1. Architecture & Primary Region
1.1 Current production architecture
CloakAPI currently operates from a single primary region: Hetzner Cloud, Nuremberg (nbg1), Germany (EU). This is an independently certified, audited Tier III-equivalent facility operated by Hetzner Online GmbH, subject to German and EU law.
- Primary compute: CX43 instance (8 vCPU, 16 GB RAM)
- DNS: Cloudflare (DNS-only / grey-cloud). No third-party CDN, WAF or edge proxy is in front of the origin today; TLS terminates at our own nginx on the box.
- Database: PostgreSQL on the primary host
- Artefacts: stored on the primary host and included in the off-site backup set
- Network ingress: public traffic reaches the origin nginx directly over TLS
1.2 Single-region risk acknowledgement
We acknowledge that a single-region architecture creates a regional failure risk. This is a deliberate current-state trade-off for a pre-enterprise-revenue product. The mitigation strategy is the backup and recovery architecture described in Section 2, which limits data loss exposure to the RPO window. Multi-region failover is on the roadmap (Section 5).
2. Backup Strategy
2.1 Backup schedule
All persistent data is backed up every 6 hours. Backups run at 00:00, 06:00, 12:00, and 18:00 UTC.
2.2 Backup architecture
- Pull model: An off-site backup host initiates all backup transfers. The production host cannot push or delete backup data. This means a compromised production host cannot destroy backups.
- Encryption: All backup archives are encrypted with
age(X25519 recipient key) before leaving the production network. Backup destination has no access to decryption keys. - Destination: Off-site backup host on a separate provider from primary infrastructure, connected via Tailscale VPN.
- Retention: 30 days of rolling snapshots. Daily backups retained for 30 days; older snapshots are purged.
2.3 Backup scope
- PostgreSQL database: full pg_dump snapshot each cycle
- Application configuration (non-secret): full snapshot
- Cryptographic signing keys: held under Shamir split custody and backed up separately, encrypted, off-host
- Object storage artefacts: replicated to backup destination
2.4 Backup testing
Restore procedures are documented and exercised on a target quarterly cadence: a full restore to a temporary environment with data-integrity verification, logged, with any failure investigated before the next backup cycle. This is our intended cadence as we build operating history; we will not claim a completed test record we do not yet have.
3. Recovery Targets
3.1 RTO basis
The 4-hour RTO assumes: infrastructure can be provisioned on a new host within 30–60 minutes; backup decryption and restore requires 30–90 minutes for typical data volumes; application deployment and smoke-test requires 30–60 minutes; DNS propagation and health checks require up to 30 minutes. The 4-hour figure provides margin above these estimates.
3.2 RPO basis
The 6-hour RPO reflects the backup interval — the maximum window of data created between snapshots that could be lost in a total-loss event. The 6-hour figure is the conservative target commitment. (Continuous WAL archiving, which would tighten the effective window to minutes, is on the roadmap and not yet enabled.)
4. Disaster Scenario Coverage
5. Multi-Region Roadmap
Multi-region active-active or active-standby failover is not yet implemented. It is on the technical roadmap and will be prioritised when the first enterprise customer with a contractual multi-region requirement engages. We will not commit to a calendar date for this capability that does not reflect genuine delivery intent.
The planned architecture for multi-region uses a second Hetzner location (Helsinki or Falkenstein) with synchronous database replication and Cloudflare for traffic routing, with a target RTO of < 15 minutes and RPO of < 1 minute in active-standby mode.
6. Annual DR Drill Commitment
CloakAPI commits to performing a full end-to-end DR drill at least annually. The drill covers:
- Simulated primary host failure
- Full restore from encrypted off-site backup
- Application startup and health-check verification
- DNS failover test
- Measurement of actual RTO achieved vs. target
- Post-drill report documenting findings and remediation actions
Once the first drill is completed, its report will be available to enterprise customers on request to trust@cloakapi.io. We will not publish drill results before a drill has run.
7. Customer Communication During an Outage
All incidents are communicated via status.cloakapi.io. Major incidents (SEV-1/SEV-2) also trigger email notification to billing contacts.
8. Document Review
This BCP summary is reviewed annually, or after any significant architectural change or DR drill that identifies material gaps. The next scheduled review is 2027-05-01.