Updates and backups

Two operational jobs: keeping Gophenberg current, and being able to put it back after something goes wrong.

Updating

Your compose file pins an exact version, so nothing updates behind your back:

# 1. edit compose.yaml: change the image tag to the new version
docker compose pull
docker compose up -d

Migrations run automatically when the new version starts. While Gophenberg is below 1.0, read the release notes first, since a release can change behavior.

What to back up

The database, which holds everything you wrote:

docker compose exec -T db pg_dump -U postgres -Fc gophenberg > gophenberg.dump

The -T is required: without it Docker attaches a terminal that corrupts the binary dump, and you find out when the restore fails.

Your compose file and any .env beside it, the only place your configuration and passwords exist.

The media volume, which holds every file you uploaded. The database records what each file is called and where it lives, but never the file itself, so a lost volume leaves a library of broken pictures no dump can repair:

docker compose cp gophenberg:/media ./media-backup

Back it up whenever you back up the database. The two have to come back together, or the library and the files disagree.

The themes volume, if you upload themes in the admin. An uploaded theme exists only there, so a lost volume means re-uploading every theme:

docker compose cp gophenberg:/themes ./themes-backup

Which theme is active is stored in the database, not in the volume, so both have to come back for the site to look the same. Themes you install by hand need no backup, they are rebuilt from their source projects.

Restoring

Restore into a database Gophenberg has never started against, because startup creates tables that make the restore fail:

docker compose up -d db
docker compose exec -T db pg_restore -U postgres -d gophenberg < gophenberg.dump
docker compose up -d

Starting only the database first is what keeps Gophenberg out of the way until the restore is done.