Skip to content

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.

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.

  1. Back up the database.
  2. Read the release notes for changes to settings.
  3. Run the migrations with the new image.
    • Docker Compose: git pull, then docker compose -f deploy/docker-compose.yml up -d --build. The migrate service 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 migrate once 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.

  4. Replace the web service and the worker.
  5. 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.

  6. Check /healthz and the start-up log line of each service.

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.