Odyssie
Security model

Assume we get breached.
Your data still holds.

The useful question is not whether a vendor promises to behave. It is what an attacker gets when the vendor is the one compromised.

Encryption happens before upload

The agent streams your dump through gzip and then AES-256-GCM on your own host. The key is derived locally from a passphrase you choose, using PBKDF2-HMAC-SHA256 at 600,000 iterations with a fresh 16-byte salt for every backup.

That passphrase is never written to disk, never placed in a config file, and never sent to our API. There is no escrow, no recovery endpoint, and no support process that can retrieve it — because no such capability exists in the system.

Ciphertext is written in 1 MiB frames. Each frame's authentication tag covers the file header, the frame counter and a final-frame marker, so reordering, splicing or truncating an archive is detected at restore rather than discovered later.

Parameters

Cipher
AES-256-GCM
Frame size
1 MiB
KDF
PBKDF2-HMAC-SHA256
Iterations
600,000
Salt
16 bytes, per backup
Transport
TLS 1.2+, outbound only

Exactly what we hold

Zero-knowledge does not mean we store nothing. It means what we store cannot be turned back into your data.

What our servers hold

  • Ciphertext, which we cannot decrypt
  • Database names and engine types
  • Backup sizes, timestamps and durations
  • Success and failure status
  • Your account email and billing details

What we could not produce under subpoena

  • Your encryption passphrase
  • Any derived encryption key
  • Table names, schemas or column data
  • A single row of your database contents

This cuts both ways. If you lose your passphrase, your backups are unrecoverable. Not slow to recover, not expensive to recover — gone. Put it in a password manager before your first backup runs.

Storage that refuses deletes

Encryption protects confidentiality. It does nothing for availability — an attacker who cannot read your backups can still delete them, and for ransomware that is the whole plan.

Every object Odyssie writes carries an S3 Object Lock retention date, applied at upload time rather than swept in afterwards. Buckets are versioned, so an overwrite keeps its predecessor rather than replacing it.

Point-in-time recovery segments are locked on the same terms as full backups. Protecting the base backup while leaving the WAL stream deletable would leave recovery history trimmable, which defeats the purpose.

GOVERNANCE

Free · Starter · Pro

Retention is enforced, but an account administrator holding the bypass permission can remove an object early. Suitable when you need an escape hatch for erasure requests or runaway storage.

COMPLIANCE

Business · Enterprise

The retention clock cannot be shortened or bypassed by anyone, using any credential, including ours. Once written, the object exists until it expires. Choose this only if you can live with that.

Account and transport

TOTP two-factor

Authenticator-app MFA on every account, with single-use recovery codes.

Rotating sessions

Short-lived access tokens with rotating refresh tokens. Reuse of a retired token revokes the whole chain.

Outbound only

The agent opens connections to us. It needs no inbound firewall rule and no public listener.

Scoped agent keys

Each agent gets its own credential, scoped to its own databases, revocable on its own.

Found something?

We would genuinely rather hear it from you than read about it later. Report vulnerabilities to security@odyssie.net. We respond within two business days and will not pursue legal action against good-faith research.