Product

Backups

Stackap backs up every project database to a bucket you own, encrypts the backup before it leaves the server, and restores it into a new database to prove it works.

What it does

Each project's Postgres database is dumped from a single consistent snapshot, so the data and the row counts recorded alongside it describe the same instant. The dump is encrypted with AES-256-GCM using a key derived from the master key, and the object's own name is bound into the encryption so a backup cannot be swapped for another and still verify. It is then uploaded to a Cloudflare R2 bucket in your account.

A backup that has never been restored is a hope, not a backup. So once a week Stackap restores each backup into a fresh database and compares the table row counts with the manifest taken at dump time. A passing comparison sets a "restore verified" timestamp you can see. A failing one raises an alert.

Restores only ever go into new databases. There is deliberately no button that overwrites a live database with a backup, because the most dangerous moment in recovery is the one where the fix destroys what survived.

How it works

A background loop checks hourly and does the work that is due: a backup per database each day, a verification each week, and pruning of old backups under a retention rule. Three things are backed up beyond the application databases:

• The control plane's own database, which holds every project's configuration, encrypted environment variables and token hashes. It is backed up daily and restore-verified weekly.
• Git repositories, as encrypted git bundles, so the source of an app does not live only on the server.
• Object storage for projects that use it lives in R2 itself, and the storage schema in the database is included in the database backup.

If a backup fails or goes stale, the monitor reports it, and a Telegram alert repeats every six hours until it is resolved. Errors from a failed backup are redacted so a database password cannot leak into a log or an API response.

In practice

$ stackap status        # overall health plus each monitor check, including backups

Early-access scope

• Backups are daily, so a disaster can cost up to a day of data. There is no point-in-time recovery yet; it is on the roadmap.
• Restoring an off-box backup using only the bucket and the master key has been proven with a script on a separate machine, and rebuilding an entire fresh server from nothing is the next drill on the roadmap.
• Restore verification compares table row counts. It proves the data came back at the right size, not that every value is correct.
• Backups are only as independent as your bucket. They live in an R2 bucket in the same account the platform uses, so a lost Cloudflare account would lose them along with everything else you keep there.
• The command-line tool has no backup or restore commands yet. Listing backups and restoring one into a new database are HTTP API calls (POST /v1/projects/:slug/restore).

Questions

Last updated 2026-10-03.