Dispatch follows semantic versioning. Minor and patch releases can be applied directly. Major releases may need manual steps, which are listed below and in the release notes.
Database migrations run automatically when the new version starts. They're idempotent and guarded by a Postgres advisory lock, so the app and worker never run them twice.
- Read the release notes for every version between yours and the target.
- Take a backup of the database and the data directory.
- Check the running version:
curl -s https://<your-domain>/api/health.
cd /opt/dispatch # the directory with docker-compose.yml
docker compose pull # fetch the new images
docker compose up -d # recreate app + worker; migrations run on start
docker compose logs -f app # watch the migration and startupTo stay on a specific release, pin it in .env and change it when you upgrade:
# .env
DOMAIN=mail.example.com
DISPATCH_VERSION=1.0.0Image tags:
| Tag | Meaning |
|---|---|
latest |
Latest stable release |
1, 1.0, 1.0.0 |
Latest release within a major / minor line, or an exact release |
main |
Latest commit on main. Unreleased, for testing only |
sha-<commit> |
A specific commit |
Also refresh docker-compose.yml from the repository when a release note says so:
curl -fsSLO https://raw.githubusercontent.com/codextde/dispatch/main/docker-compose.ymlChange DISPATCH_VERSION and redeploy. See Coolify → Updating.
Migrations only move forward. To roll back to an older version after a release that changed the database schema, restore the backup you took before upgrading, then start the older image tag.
The bundled database is postgres:17-alpine. Postgres can't open a data directory from another major version. Don't change the image tag to postgres:18 on an existing installation. Upgrade with a dump and restore instead:
pg_dumpthe database (Backup).docker compose down, then remove thedispatch-dbvolume (docker volume rm <project>_dispatch-db).- Change the
dbimage,docker compose up -d db, and restore the dump.
Initial release. Nothing to migrate.