Trust center

What perseus runs on, who touches your data, and what happens when something breaks.

Subprocessors, hosting, backups, and the uptime target we're actually operating against, not the one that sounds best in a deck.

Subprocessors

Everything that can see or touch your data, and why it's there:

SubprocessorPurposeData
Hosting VPS (Coolify-managed)Runs the app, database, and backupsEverything: event data, account data, evidence chain
OpenTimestampsExternal Bitcoin-anchored proof-of-existence for daily Merkle rootsA SHA-256 digest only, never event content
Plunk (self-hosted, our own instance)Transactional email: alerts, weekly reports, password resetsRecipient email address + message content
GitHub (optional, per deployment)Public append-only anchor log, when GitHub anchor mode is enabledSigned Merkle root + signature, no event content

Notably absent: no third-party analytics, ad tech, or session-replay tool runs on perseus itself. The email subprocessor is a Plunk instance we operate ourselves.

Data residency

Regions
Single region today. We do not yet offer EU-only or multi-region hosting.
Database
SQLite, one file, one host, inside the same persistent volume as the application.
Multi-tenant model
Shared database, site_key-scoped rows. See /security for the isolation model and the documented trigger for moving off it.
If EU-only residency is a hard requirement for your deal, tell us. It's a scoped, deferred item on our roadmap (see our changelog).

Backup & disaster recovery

Backup method
Nightly consistent snapshot via SQLite's VACUUM INTO (not a raw file copy, so a snapshot mid-write can't corrupt the backup).
Retention
Last 7 nightly backups kept; older ones are pruned automatically.
Storage location
Same host/volume as the primary database today. Off-host and cross-region replication don't exist yet. This is the single biggest gap in our current DR posture, and we're not going to dress it up as anything else.
RTO / RPO
No formally tested target yet. Worst case today, in writing: up to ~24 hours of data loss (the gap since the last nightly backup) if the primary volume is lost entirely.
Restore testing
Not yet on a recurring schedule. Planned before this becomes a hard gate for a named enterprise deal.

Uptime target

We're targeting 99.9% monthly uptime for the ingest and dashboard endpoints. There is no published SLA with credits yet. See /status for the live health check and incident history once we have enough history to publish. A formal SLA is an Enterprise-tier commitment (see pricing).

The Evidence Record

The mechanism behind every "verified" claim on this site is documented in full on /security: hash-chained events, a daily signed Merkle root, and external anchoring via OpenTimestamps (Bitcoin) or a public GitHub log. That page also covers what "declared-only" means and why it's excluded from verified totals.