Skip to main content
Your collection lives in a Postgres database inside the Docker stack. There are two ways to back it up: a PostgreSQL dump (full fidelity, required for proper restores) and the CSV archive export in the app (great for a human-readable copy you can open in a spreadsheet). Always back up before upgrading.

​
Quick backup from the app

Go to Settings → Data management → Export and download the ZIP archive. This is a CSV export — it’s human-readable and can be imported back into plamotrack. For a complete database backup that preserves sessions, access tokens, and MCP client links, use the pg_dump method below. A script can fetch the same archive with a personal access token; read-only is enough:
The archive is read from a single database snapshot, so an export taken while an assistant is adding an order gives you the collection as it stood when the export began, never a mix of before and after. It never carries credentials, so it is safe to keep anywhere, and it still opens in a future version whose schema has moved on — though it restores more slowly than a dump. Restored into an empty instance, it keeps every record’s ID. Merged into one that already has your retailers, catalog items or orders, it reuses those instead of creating copies. Keep both: the dump is what you restore from on Sunday; the archive is what still opens in three years. See Import & Export for the format.

​
Database backup with pg_dump

Run the following command from your plamotrack directory. The dump file is a portable Postgres archive.
The quoted variables are expanded inside the database container, so the command follows the POSTGRES_USER and POSTGRES_DB values in your .env rather than assuming the defaults. The restore below does the same.
A backup is two things: the dump file and your .env. Keep them together. The .env holds the secrets (your database password and, in OIDC mode, MCP_OAUTH_SIGNING_KEY) that make the backup fully restorable.

​
Restoring a dump

Restore into an empty database — pg_restore will not merge cleanly into a populated one.
1

Tear down the current stack (removes the database volume)

docker compose down -v deletes the db-data volume, which is your collection. Without -v the volume survives and down is safe. Take a backup first regardless.
2

Start the database and wait for it to be ready

--wait returns only once the real server is listening, so the restore cannot land while the image is still running its first-start setup.
3

Restore the dump

4

Start everything back up

​
What survives a restore

What comes back depends on which half of the backup you restore and which .env you pair it with. Sessions and tokens survive a changed .env because they are stored as digests, not signatures; only the OAuth state is encrypted under MCP_OAUTH_SIGNING_KEY. Restoring without the original .env at all — a fresh one with a new database password — still works: the password only matters when the volume is first created, which the restore does, and the second row then applies.
Never run docker compose down -v unless you intend to delete the database. The -v flag deletes Docker volumes including your Postgres data. Running docker compose down without -v is safe — the volume survives.