Docs

Backups

Database dumps, volume archives, run history, and instance self-backup.

Destinations

S3-compatible buckets — anyone with the destinations.manage capability can add one
Local disk on the panel host — instance admin only, needs a name and nothing else
Archives are written write-then-rename, so a crash mid-write never leaves a truncated file that retention would count as a good backup
A lost host takes local backups with it: keep an off-host copy of anything you actually rely on

Database backups

Per-database schedules write to a destination on a cron. Passwords never land on argv (stdin or in-container), a failed dump fails the run instead of uploading an empty archive, and restores stream the stored object back into the container over stdin — so there is no size ceiling on a dump any more.

Run history and verification

Every dump, archive, instance export and verification is one run row: running first, then success with the object key and size, or error with a redacted message safe to show and to notify on
Each list badges its rows with the last run; the history icon opens the last 20 with status, trigger, duration, size and the stored object
Verify restores a stored dump into a throwaway container from the service's own image — no published ports, no network, no real credentials — runs a liveness query and removes it. It never touches the live database
A failed verification is visible in the history next to the dump it rejected

PostgreSQL recovery copies

Backups → Recovery copies restores a stored PostgreSQL dump into a new managed database in another accessible environment. It validates the archive before provisioning, uses the source's versioned image/server, generates fresh credentials, publishes no host port, and checks the restored table catalog before showing Ready. The source and stored dump are preserved.

Copies retain unsanitized data and consume normal service/storage resources until explicitly deleted. An admin needs backup, service creation/deployment and secret-write permissions. A failed restore keeps its incomplete target for inspection or deletion; an interrupted operation never shows success. Deletion checks the recorded original server and volume, refuses placement changes, and retains tracking when cleanup cannot be verified. This initial workflow does not upgrade versions or copy to another server. Verify application compatibility yourself.

Volume backups

Back up named volumes attached to applications or compose services on a cron — useful for CMS uploads, media libraries and anything a SQL dump does not cover.

Instance backup

Settings → Backup storage → Instance backups
Two artifacts per run: a pg_dump of Nixploy's own database and a tar of the config dir (Traefik config, acme.json, SSH keys)
Instance admin only to create, edit, run or delete — the dump captures every tenant's data
The config archive never includes /etc/nixploy/.env (ENCRYPTION_KEY, BETTER_AUTH_SECRET, DATABASE_URL) — shipping the key next to the data it protects would hand every tenant credential to anyone who can read the bucket
Restore is intentional and manual, onto a fresh host, with the same ENCRYPTION_KEY

Back up /etc/nixploy/.env yourself, somewhere the bucket reader cannot reach. A restore without the original ENCRYPTION_KEY cannot decrypt anything stored — env vars, database passwords, registry/git/SSH credentials, S3 keys and notification configs all have to be re-entered by hand.

Rehearse the restore

The first real restore should not be the first restore. tools/dr-restore-test.sh in the repository restores a dump into a throwaway Postgres container, restores a second time to prove the dump applies over a populated database, asserts the core tables, and can boot the panel image against the result. Run it monthly, after a Postgres major upgrade, and after changing a destination.

Also see the repository guides under docs/ · REST API reference