backupd_

Convex backups, file storage included

backupd runs Convex’s own export on your schedule, file storage included, and keeps each snapshot encrypted to a key you hold. Restoring is one convex import away.

Start free trialSee pricing

Integrity check

marketing-site-2026-10-13-0300.zip.zst.age
Intact
Tables
5
Documents
54,054
Took
5s
Check
integrity
  1. Fetch the backup20 MB from storage1s
  2. DecryptUnlocked and checksum matched1s
  3. Test the ZIPEvery entry in the ZIP reads back2s
  4. Count documentsFrom each table in the export1s
Counts per table, backed up against restored
TableBacked upRestoredResult
pageViews48,21048,210match
posts3,9043,904match
authors1,2121,212match
comments640640match
settings8888match
Cloud + self-hosted
Convex Cloud and self-hosted backends.
Files included
Every export includes your file storage.
Per-table counts
Documents counted in every table.
Yours to open
Open the file with age, zstd and npx convex.

How a backup runs

  1. Export the deploymentWe run convex export with file storage included. The result is the same ZIP Convex itself produces.
  2. Compress and encryptThe ZIP is compressed with zstd and encrypted with age to backupd’s key and every key you add.
  3. Check and countThe ZIP is tested for integrity, and every table’s documents are counted from the export.

Backup

marketing-site-2026-10-16-0300.zip.zst.age
Succeeded
  1. Exportconvex export, file storage included
  2. StageStaged on the worker, then streamed
  3. Compresszstd, 64 MB to 20 MB
  4. Encryptage, to 3 keys
  5. CheckRead back, both checksums match

Took 38s · Scheduled

How it is checked

Every Convex backup gets an integrity check: the ZIP is tested end to end, and the documents in each table are counted from the export itself.

Those counts are stored in the backup’s encrypted manifest, so you can see what each snapshot held.

How restore tests work

What backupd needs

  • Convex Cloud: your deployment URL and a production deploy key, both under Settings → URL & Deploy Key in the Convex dashboard.
  • Self-hosted Convex: the backend URL (your CONVEX_SELF_HOSTED_URL) and an admin key made with generate_admin_key.sh.
  • The deployment must be reachable over HTTPS from the internet.

Add database

backupd connects over TLS. Use a read-only user.

Deployment URL

https://happy-otter-123.convex.cloud

Deploy key

prod:happy-otter-123|••••••••••••

Schedule

Daily at 03:00

Keep backups

30 days

CancelTest and add

Restore it yourself

Every backup is encrypted with age to your key as well as ours. Download it, and open it with free tools on your own machine:

Terminal

# Decrypt, decompress, then import into a deployment
$ age -d -i backupd.agekey app.zip.zst.age | zstd -d > snapshot.zip
npx convex import --replace-all snapshot.zip

Restoring without backupd

Not yet

  • There is no temporary Convex deployment to restore into, so Convex backups get an integrity check and per-table document counts instead of a full restore test.
  • The export is staged on our worker’s scratch disk before it is compressed and encrypted, unlike the other engines, which stream.
  • In-app restores go back into the deployment the backup came from.
  • Tables whose names start with an underscore are not counted.

Questions

Yes. Exports run with file storage included, so the ZIP holds your documents and your stored files.

Use a production deploy key. backupd uses it to run convex export, and convex data to list your tables when you connect.

The ZIP is tested for integrity and we count the documents in every table. Convex has no throwaway deployment we can restore into, so there is no full restore test for Convex yet.

Other engines

PostgreSQLPostgreSQL 9.2 through 18.MySQL and MariaDBMySQL 5.7+ and MariaDB 10.3+.MongoDBMongoDB 4.2 and later.

Back up Convex tonight

Paste a connection string, pick a schedule and add your key. Starter is free for 14 days.

Start free trialCompare plans