Backups

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

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

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.