GitHub Start for free

How do I upgrade a self-hosted RevenueDot?

Back up, pull, restart. The server applies any new database migrations when it starts, before it accepts requests, so there is no separate migration command. Your .env stays as it is.

Shell
cd revenuedot
docker compose exec -T db pg_dump -U revenuedot -Fc revenuedot > revenuedot-before-upgrade.dump   # 1. back up
docker compose pull                                                                             # 2. the new image
docker compose up -d                                                                            # 3. restart
curl -s http://localhost:8787/v1/health                                                         # 4. {"status":"ok"}

What happens during the restart#

  • The old container stops and the new one starts. Requests in between fail for a few seconds.
  • The SDKs handle this. A failed receipt post is kept on the device and retried, and customer info comes from the SDK's cache.
  • Stores retry. Apple and Google resend notifications that got no 2xx answer.
  • Webhooks wait. Pending deliveries stay in the database and go out after the restart.

For no downtime at all, run two or more replicas behind a load balancer and replace them one at a time: see High availability. Read the release notes first; they list any breaking change and the steps it needs.

If the new version does not start#

  1. Read the log: docker compose logs revenuedot --tail 100. A failed migration names the statement.
  2. Go back to the build that worked: set REVENUEDOT_IMAGE=ghcr.io/revenuedot/revenuedot:<date or commit tag> in .env and run docker compose up -d. The tags are listed on the package page.
  3. If a migration already ran, restore the backup as described in Backups, then start the previous version.

Keep up with changes#

  • Watch the server repository for commits and, later, releases.
  • The image is built from main on every change (tagged latest, by date and by commit) and on every release tag. Pin a date or commit tag in .env to choose when you upgrade.
  • Migrations live in packages/db/migrations. Each upgrade applies the ones your database has not seen, in order.
  • Accounts made by builds from before 2026-09-30 used 210,000 password-hashing iterations; newer builds use 100,000. Both verify on a self-hosted server, so nobody needs to reset a password.
Edit this page on GitHub ↗ View as Markdown Last updated