ARCHITECTURE / OFFSITEDB

How OffsiteDB backs up and proves Postgres restores

READ-ONLY IN · ENCRYPTED OUT · RESTORE-DRILLED BEFORE IT COUNTS

OffsiteDB is intentionally narrow: connect to Postgres with read-only access, create a standard dump, encrypt and ship it to object storage you control, then restore the same artifact into a disposable Postgres instance to prove it works. The system is designed so your bucket is the source of truth and OffsiteDB is the proof engine around it.

1. Source Postgres

Supabase, Neon, Railway, Render, RDS, or any reachable Postgres URL.
Read-only role recommended; write access is not needed for backup.
Connection is tested and credentials are encrypted at rest.

2. Backup worker

Runs pg_dump with provider-safe connection settings.
Streams the archive to avoid large memory spikes.
Seals the artifact with authenticated encryption.

3. Your storage bucket

AWS S3, Cloudflare R2, Backblaze B2, Wasabi, or compatible S3 storage.
Private bucket, least-privilege key, lifecycle/retention rules.
You keep the copy even if you stop using OffsiteDB.

4. Restore drill

Restores the artifact into disposable Postgres.
Counts tables and rows, records timing, flags failures.
Only proven snapshots appear as sealed in the ledger.

Data flow

Read-only Postgres URL
        │
        ▼
pg_dump worker ── encrypt/seal ──► your private S3/R2/B2 bucket
        │                                  │
        │                                  ▼
        └──────── restore drill ◄── same backup artifact
                   │
                   ▼
        drill ledger + alerts + monthly report

Trust boundaries

Database access: OffsiteDB needs read access for pg_dump, not write access.
Storage access: destination credentials should be scoped to one private bucket.
Artifact ownership: backup objects live in your storage account, not only in ours.
Restore environment: drill databases are temporary and used to measure restore success, table counts, and row counts.
Evidence layer: the app stores backup metadata, status, drill results, alerts, and reports.

Failure modes the architecture is built to catch

A backup job fails after credential rotation.
An uploaded file is corrupt, truncated, or not restorable.
A table suddenly shrinks after a bad deploy or accidental delete.
A migration is about to run without a fresh checkpoint.
A security review asks for tested restore evidence instead of promises.

What OffsiteDB is not

It is not a high-availability replica, not a replacement for provider-native PITR, and not a general server backup suite. Keep your platform-native backups on. OffsiteDB adds the missing independent layer: an off-site archive you own and evidence that it restores.

Security details Sample restore report Start free trial