Backup and restore

The server's state lives in two places: the tenant directory and the container volumes. Back up both. No other path on the host holds state.

What to back up

1. The tenant directory — <base-dir>/tenants/<tenant>/ (for example /opt/sfp-server/tenants/my-app/). This holds the tenant's configuration:

Path	Contents
.env	tenant environment configuration
config/	service configuration (reverse proxy, collector config)
secrets/	locally stored secrets, when not using an external secrets provider
docker-compose.yml	the rendered stack definition

These are plain files; any file-level backup tool works. Treat .env and secrets/ as sensitive — encrypt backups at rest.

2. The container volumes — every volume belonging to the tenant's compose project. List them on your host:

docker volume ls --format '{{.Name}}' | grep -E '^<tenant>[-_]|^(supabase|hatchet|verdaccio|victoria)'

Volume names are prefixed with the tenant name on current deployments (my-app-supabase-db-data; older deployments used my-app_supabase-db-data or the bare base names such as supabase-db-data), which is why the listing matches on both forms. On a host running more than one tenant, confirm that bare-name matches belong to this tenant before including them. The set includes the application database (supabase-db-data), the task-queue database (hatchet-db-data), file storage (supabase-storage-data), the package registry storage (verdaccio-data — packages and the registry database, not a disposable cache), and the configuration volumes (hatchet-config, hatchet-certs, verdaccio-config, supabase-db-config). Back up the full set the listing returns rather than a hand-picked subset. The metrics and log history volumes (victoriametrics-data, victorialogs-data) are rebuildable; include them only if you need the history.

Back up databases with a consistent method: either stop the tenant first and snapshot the volumes, or take an online dump (pg_dump against the database containers) on a schedule. A file copy of a running database volume is not a reliable backup.

sfp server update additionally snapshots .env, config/Caddyfile, and secrets/ to tenants/<tenant>/backups/update-<timestamp>/ before an update (unless --skip-backup is passed) — this covers the update path only; it does not back up the volumes.

Verify

Periodically restore the database dump into a scratch container and confirm it loads, and confirm the tenant-directory archive contains .env, config/, and secrets/.

Restore

1. Provision a host that meets the prerequisites and install the sfp CLI.
2. Restore the tenant directory into <base-dir>/tenants/<tenant>/.
3. Restore the volumes (or load the database dumps) before first start.
4. sfp server start --tenant <tenant> --base-dir <base-dir>, then sfp server health --detailed.

All state is in the tenant directory and the volumes, so a restore onto a fresh machine recovers the deployment.

Troubleshooting common failures