For teams with a SOC 2, ISO 27001 or NIS2 audit

Prove your PostgreSQL backups actually restore.

Connect a read-only key and Verestore restores your newest backup into an isolated, single-use environment in the EU on a schedule, checks what matters and keeps countersigned evidence anyone can verify. Nothing to install; row data never leaves the run.

No account needed for the free check. Upload a dump up to 2 GB, get a link to the report by e-mail, the dump is deleted.

  • AWS S3
  • Azure Blob
  • Google Cloud Storage
  • Cloudflare R2
  • Backblaze B2
  • Wasabi
  • OVHcloud
  • DigitalOcean Spaces
  • Scaleway
  • MinIO

pg_dump files in any S3-compatible store, Azure Blob or Google Cloud Storage — from RDS, Cloud SQL, Supabase, Neon, Azure Backup exports or self-hosted Postgres.

Restore test · 7 Nov 2026
orders-db
passed

orders-db was restore-tested 90 times in the last 90 days with 0 failures; last evidence pack 9 November 2026.

  • Restore completed
    pass
  • Row counts within range
    within 25%
    pass
  • Checksum unchanged: public.orders
    pass
  • Orders exist
    value 50,000 (expected >= 1)
    pass
Signed by the runnerCountersignedVerify it yourself →
The coverage sentence on every target, here with a daily schedule: paste it into your SOC 2, ISO 27001 or NIS2 evidence.

Why Verestore

  1. Hosted, nothing to install

    Give us a read-only key to the bucket where your pg_dump files land: five minutes, no agent, no runner to operate.

  2. Evidence you can't forge

    Each run is signed in its sandbox and countersigned by Verestore, independently of you. Anyone can check a report at /verify.

  3. The deepest restore proof for PostgreSQL

    Not just "it restored": row-count drift, checksums of the tables you choose and your own SQL checks, all judged against a baseline.

  4. EU-hosted, audit-ready

    Runners, control plane and evidence in Paris. Evidence for SOC 2, ISO 27001 A.8.13 and NIS2 Article 21.

How it works

  1. 1

    Connect a read-only key

    Point us at the bucket or prefix where your pg_dump files land, with a key that can only list and read your backups. It is encrypted for the service that starts runs and can never be read back.

  2. 2

    Restore in an isolated sandbox

    On schedule, a fresh PostgreSQL of your major version is started in its own Kubernetes namespace under gVisor, with egress limited to your bucket. The newest backup is restored into it.

  3. 3

    Check what matters

    Restore completes, backup freshness and size, table inventory, row-count drift, checksums of chosen tables, and your own SQL checks, all judged against the last good run.

  4. 4

    Keep the evidence

    Every run produces a signed report, a countersigned verdict and a line for your auditor. The sandbox and the restored data are deleted when the run ends.

Provider snapshots die with your account

Managed backups and snapshots live inside the cloud account they protect: a closed account, a compromised admin or a deleted project takes them too. The copy that survives is a dump in storage you control, in another account or with another provider. Prove your off-site copy restores.

Verestore reads it from any S3-compatible store, Azure Blob or Google Cloud Storage, with a key that can only list and read your backups.

Connect your off-site backups

A real report

This is a real run of our hosted pipeline, for a sample orders database: every check against the previous good run, the backup's identity, and the hash and signatures that make it tamper-evident. Customers get one for every run, as HTML and PDF, and quarterly as an evidence pack.

Nothing on it is staged: the result hash, the runner's signature and our countersignature verify.

How isolation and signing work
Restore test report
orders-db
passed
Sat, 07 Nov 2026 13:35:08 GMT

orders-db was restore-tested 90 times in the last 90 days with 0 failures; last evidence pack 9 November 2026.

Backup orders-prod/latest.dump
Size 2.6 MB (pg_dump_custom)
Backup taken Sat, 07 Nov 2026 13:34:34 GMT
Restore time 0.6 s
PostgreSQL 16.15
Tables restored 12
Checks
CheckOutcomeDetail
Restore completed
restore_completes
passrestore completed
Backup is recent
backup_freshness
passage 0.0h (max 192h)
Backup size consistent
backup_size
passchanged 0.0% (max 30%)
Checksum unchanged: public.orders
checksums:public.orders
passunchanged
Version and extensions unchanged
extensions_and_version
passunchanged
Show all 11 checks
More checks
CheckOutcomeDetail
Restore time normal
restore_time
pass0.6s (max 2x median 0.7s)
Row counts within range
row_counts
passwithin 25%
All tables present
table_inventory
pass12 tables
No order items without an order
custom_sql:no_orphan_order_items
pass0 rows
Order currencies unchanged
custom_sql:order_currencies_unchanged
passresult matches baseline
Orders exist
custom_sql:orders_exist
passvalue 50,000 (expected >= 1)
result_hash: sha256:9d959e2663479d79bc8bf05df6990a61d8e80b3cca16e097767abf96ea298181
runner signature (Ed25519): bmKoToZg0eeH_XdGNUFMR87rIEiRJJ5I4mdjRERD…
control-plane countersignature: eyJhbGciOiJFZERTQSIsImtpZCI6ImV2aWRlbmNl…
run run_01M6V3G4GPY611ZQHWH03Y2DHB · verify this report at verestore.dev/verify

Every database, one screen

The dashboard of a demo organisation: each target's last verdict, its restore-time trend, the next scheduled run and the coverage sentence for your auditor.

Verestore dashboard with four targets: their status (passed, warned, inconclusive), restore-time trends, next runs and coverage sentences

Built to be trusted with production backups

No row data leaves a run
Results hold names, counts, hashes and durations. A JSON Schema enforced on upload forbids anything else.
Read-only, scoped keys
Copy-paste read-only policies for S3-compatible stores (AWS, Scaleway, Cloudflare R2, Backblaze B2, Wasabi, OVHcloud, DigitalOcean Spaces, MinIO), Azure Blob and Google Cloud Storage.
Setup guides
Signed, then countersigned
The runner signs each result with a per-run key; the control plane countersigns the verdict. Anyone can verify both.
Verify a report
EU hosting
Control plane and runners in Scaleway fr-par (Paris).
Deleted after every run
Namespace, scratch database and downloaded dump are removed on success, failure or timeout.
FAQ

Questions, answered plainly

Do I need to install anything?

No. Verestore is hosted: you give it a read-only key to the bucket or container where your pg_dump files land, which takes about five minutes with the copy-paste policies in the docs. There is no agent and no runner to operate on your side.

Can the evidence be forged?

Not without breaking a signature. Each result is signed inside its sandbox with a key minted for that run, and Verestore countersigns the verdict independently of the customer. Anyone can check a report at /verify, or offline with our published keys; changing one number breaks it.

Do you see my data?

No row data leaves the isolated run: what comes back is names, counts, hashes, durations and a scrubbed log excerpt, and a schema enforced on upload rejects anything else. The restored database and the downloaded dump are deleted when the run ends. Your key is read-only, limited to your backups (one prefix, or one bucket or container where the store cannot scope a prefix), and can never be read back.

Where can my backups live?

In any S3-compatible store (AWS S3, Scaleway, Cloudflare R2, Backblaze B2, Wasabi, OVHcloud, DigitalOcean Spaces, MinIO), in Azure Blob Storage, or in Google Cloud Storage. Provider snapshots die with your account, so keep a pg_dump copy in storage you control, ideally in another account or with another provider, and let us prove it restores.

What if my database is bigger than my plan?

Each plan has a per-restore limit on the stored backup size (shown on the pricing page). A larger backup is not downloaded: the run is marked inconclusive, never failed, and you can upgrade or, for Business, ask us for larger databases.

What happens to my dump in the free check?

You upload it over a pre-signed link straight into a quarantine bucket (2 GB at most). It is restored once, in the same isolated sandbox as customer runs, and deleted as soon as the run ends, and in any case within 24 hours of the upload, even if the check never runs. What you get by e-mail is a link to the report: names, counts, hashes and timings, never data. Your e-mail address and a salted hash of your IP address are kept 30 days to prevent abuse, then deleted.

How do I cancel?

An owner cancels from Billing → Manage subscription, which opens the customer portal of Paddle, our merchant of record. The plan stays active until the end of the period you paid for and you are not charged again; then the organisation moves to the Free plan and its limits apply. Your targets and past reports stay. Refunds are covered by the refund policy (14 days on a first purchase).

Do you support MySQL or MongoDB?

Not today. Verestore restores PostgreSQL 13 to 17 from pg_dump backups (custom or plain format). Other engines will come only when we can test them as thoroughly.

Can it run inside my infrastructure?

Not yet. An agent that runs restore tests on your own hardware, with no inbound port, is planned; today every test runs in our isolated hosted runners in Paris. The pricing page has a waitlist.

What happens if Verestore disappears?

Your backups are untouched: we only ever read them. Every report and evidence pack you downloaded stays verifiable offline: the hashes and Ed25519 signatures check against our published public keys, with no service needed.

Find out today whether your last dump restores

The free check runs the same engine as the product, on the same isolated infrastructure.

Launching shortly