Updates
How Rezepte applies database migrations and how to update it
Every start of the binary applies any pending database migrations automatically — they are embedded in the binary itself (via goose), so there is nothing separate to run. There is no automatic downgrade: rolling back to an older version after migrations have already run is not supported.
Every version is listed on the GitHub releases page. Before updating, read the release's page in the Changelog. If the release needs anything from you, the page opens with Before you upgrade.
Back up the database before updating — see Data and backup. A migration that fails halfway is easier to recover from a backup than to fix in place.
Docker
docker compose pull
docker compose up -dThe container applies migrations on this restart, before it starts serving requests.
Binary
Download the new archive from the latest release, replace the installed binary, and restart it — systemctl restart rezepte for the systemd unit from Running the binary, or however it was started otherwise.
Confirm the new version is running
curl -s http://localhost:8060/healthzThe answer is {"status":"ok","version":"1.4.2"} — the version the running instance was built from. It needs no login, which is what makes it work for a container too: the image is distroless and has no shell, so this is the only way to read the version from outside it. With the binary, rezepte --version prints the same value.
Docker also watches that endpoint on its own. The image declares a healthcheck, so docker ps shows the container as healthy once it is serving, and as unhealthy if it stops answering:
docker ps
# STATUS
# Up 2 minutes (healthy)The first half-minute after a start counts as a grace period, because migrations — and, in demo mode, the sample data — run before the server answers.