Orimora aktualisieren

Orimora wird als einzelnes Container-Image ausgeliefert, ghcr.io/orimora-app/orimora:<version>, in der Pre-1.0-Beta versioniert als 0.1.0-beta.N. Eine Instanz zu aktualisieren bedeutet, ein neueres Image zu ziehen und die Datenbank beim Start migrieren zu lassen. Dieser Guide beschreibt den sicheren Upgrade-Pfad und das Rollback.

1. Release-Notes lesen

Jede Version ist in CHANGELOG.md und auf der GitHub-Releases-Seite dokumentiert.

Sieh dir vor dem Upgrade den Eintrag der Zielversion an — besonders den Abschnitt Migration notes, der alles auflistet, was ein Self-Hoster wissen muss: neue oder geänderte Umgebungsvariablen, Verhaltens-Standardänderungen und die Migrationen, die laufen werden. Mehrere Versionen auf einmal zu überspringen wird unterstützt (Migrationen sind kumulativ), aber lies die Migration-Notes jedes Zwischeneintrags.

2. Zuerst die Datenbank sichern

Eine Schema-Migration lässt sich ohne Backup schwer rückgängig machen. Nimm vor jedem Upgrade eines:

Wenn du den eingebauten Backup-Service nutzt, löse ein manuelles Backup aus (siehe Backup & Restore).
Andernfalls pg_dump die Datenbank selbst.

Orimora nimmt zusätzlich einen automatischen Pre-Migration-Snapshot, wenn BACKUP_PRE_MIGRATION=1 gesetzt ist (in Produktion empfohlen) — aber ein explizites, von dir kontrolliertes Backup ist das Sicherheitsnetz. Die vollständige Wiederherstellungs-Prozedur steht unter Disaster Recovery.

3. Neue Version ziehen und neu starten

Auf den neuen Image-Tag zeigen. Pinne eine konkrete Version (empfohlen) statt eines gleitenden Tags, damit Upgrades bewusst geschehen:
docker-compose.prod.yml
```
services:
    app:
        image: ghcr.io/orimora-app/orimora:0.1.0-beta.22
```

App-Container ziehen und neu erstellen:

docker compose -f docker-compose.prod.yml pull app
docker compose -f docker-compose.prod.yml up -d app

4. Migrationen laufen automatisch (fail-closed)

Beim Start führt der Entrypoint des Containers die Datenbank-Migrationen (node run-migrations.mjs) aus, bevor der Server Traffic annimmt — und das fail-closed: Schlägt eine Migration fehl, beendet sich der Container mit einem Fehlercode und der Server startet nicht mit einer un- oder halbmigrierten Datenbank. Mit BACKUP_PRE_MIGRATION=1 wird vor der Migration ein verifizierter Snapshot gezogen.

Du musst yarn db:migrate nicht manuell gegen eine deployte Instanz ausführen — dieser Befehl ist nur für die lokale Entwicklung.

5. Coolify

Auf Coolify ist ein Upgrade ein Redeploy des App-Service, nachdem sich der Image-Tag geändert hat:

Nach Änderung des Image-Tags oder einer Umgebungsvariable Force Rebuild nutzen (nicht nur Restart), damit die neue Konfiguration übernommen wird.
Datenbank und Redis sind eigene Coolify-Ressourcen und werden von einem App-Redeploy nicht angefasst.
Beim Redeploy wartet Docker bis zu ~70 s, bis laufende Jobs (E-Mails, Webhooks) fertig sind, bevor der Container ersetzt wird.

Das vollständige Deployment-Modell steht unter Coolify-Setup.

6. Upgrade verifizieren

Readiness: curl -f https://<dein-host>/api/ready sollte 200 liefern (prüft Datenbank und Redis). /api/live ist ein reiner Liveness-Check, der Abhängigkeiten ignoriert.
Version: Prüfe, dass die laufende Version dem entspricht, was du deployt hast (Footer / Über, oder der Image-Tag).
Smoke-Test: anmelden, ein Dokument öffnen, eine Suche ausführen.

7. Rollback

Anwendung: den vorherigen Image-Tag neu deployen (genau dafür ist das Pinnen eines exakten Tags wichtig).
Datenbank: falls das fehlgeschlagene Upgrade bereits eine Migration angewandt hatte, den Pre-Migration-Snapshot oder dein manuelles Backup wiederherstellen — ein neueres Schema ist mit einer älteren App-Version in der Regel nicht kompatibel. Siehe Disaster Recovery.