Upgrade OpenD
Run the new image's migrations, then replace the web service and the worker. Both are stateless, so an upgrade is a redeploy.
About this task
Images are published to ghcr.io/desktopmachineshop/opend: edge and
sha-<commit> from main, and 1.2.3,
1.2 and latest from release tags. Pin a version in production.
-
Back up the database.
See Back up and restore.
- Read the release notes for changes to settings.
-
Run the migrations with the new image.
- Docker Compose:
git pull, thendocker compose -f deploy/docker-compose.yml up -d --build. Themigrateservice runs before the app and the worker start. - Railway: deploy as usual; the web service's pre-deploy command runs
node dist/bin.js migrate. - Elsewhere: run
opend-server migrateonce before starting the new version.
Migrations are applied in order and recorded in
schema_migrations. An advisory lock makes concurrent runs safe, and a migration that has already run is skipped. - Docker Compose:
- Replace the web service and the worker.
-
If the release notes say so, rebuild the search index with
opend-server reindex.The worker indexes every release it publishes. Releases published before an upgrade that changes the index (or before search indexing existed) are searched in memory, without stemming or prefix matching, until they are reindexed.
opend-server reindex --release <id>rebuilds one release; the ids are in/admin/api/repos/:id/releases. Readers are served throughout. -
Check
/healthzand the start-up log line of each service.
Results
Published releases keep working: the release snapshot format is versioned, and the docs are not rebuilt by an upgrade. To pick up rendering improvements in the build itself, push or trigger a build of each release ref.