DurinDoorUpgrading
Back up the active database, install a chosen release, verify inference, and recover if needed.
Upgrade after reading the release notes for compatibility and migration changes. Record the current package version or image digest and choose the version you intend to install.
Save a recovery copy
Stop DurinDoor and any watchdog that restarts it. Make a full data backup, including encryption keys, machine ID, and protected environment secrets. For PostgreSQL, also take and verify a database dump.
Startup migration copies are safety copies, not full backups. They retain only the newest three backup directories and can omit request details. SQLite timeline history has its own sidecar.
Install the selected version
Update the Compose image to your verified version or digest:
docker compose pull durindoor
docker compose up -d durindoorFor a standalone container, pull the chosen image, remove the stopped container, and recreate it with the same mount and private environment file. See Docker.
Keep JWT_SECRET, API_KEY_SECRET, and the data mount stable. Environment selectors still determine the database engine; packaged startup discards an empty DURINDOOR_PG_URL, while DURINDOOR_DATABASE_ENGINE=postgres remains explicit.
Migrations run forward on startup. Both database engines have migration 025 for proxy timeline storage; SQLite keeps its sidecar while PostgreSQL uses main-database tables. Preserve existing timeline history with the Postgres migration procedure. Restore a verified backup instead of editing SQLite files by hand.
After the bump
curl -fsS http://localhost:20128/api/healthThis endpoint checks liveness, not database readiness. Also request /v1/models, then exercise authenticated inference and confirm a new usage row in the selected database. For PostgreSQL-only deployments, verify that initialization errors do not create a live SQLite database.
Then open the dashboard and confirm providers, API keys, combos, and usage.
On PostgreSQL, check Settings → Database for the active engine, no initialization error, and no Serving SQLite fallback banner. Liveness alone does not prove database readiness.
If SQLite startup reports corruption, stop every writer and restore a verified backup. There is no automatic repair.
Roll back a failed upgrade
- Stop the upgraded app and its watchdog.
- Preserve the failed installation's data and logs for diagnosis.
- Restore the full pre-upgrade backup, including its matching secrets.
- Select the previous image, package version, or source tag.
- Start the app and repeat health, inference, and dashboard checks.
Starting an old binary against a migrated database does not undo migrations. For a PostgreSQL-to-SQLite rollback, Postgres also explains the loss of PostgreSQL-era writes and required environment changes.