Docs 6.0.0: yhub ersetzt Hocuspocus, Migration nötig
Docs 6.0.0 ersetzt Hocuspocus durch den Kollaborationsserver yhub. Wer selbst hostet, muss einen neuen Dienst, eine Datenbank und RSA-Schlüssel einrichten und alle Dokumente migrieren, sonst öffnen sie leer. Was Admins vor dem Update prüfen sollten.
Mit Docs 6.0.0 tauscht das Open-Source-Projekt der französischen La Suite numérique sein Herzstück aus: Der Kollaborationsserver Hocuspocus ist Geschichte, an seine Stelle tritt yhub. Das ist kein normales Versionsupdate. Der Inhalt der Dokumente liegt künftig nicht mehr als Datei im Objektspeicher, sondern im neuen Server. Wer die Instanz ohne die Migrationsschritte aktualisiert, sieht laut Upgrade-Anleitung alle Dokumente leer.
Betroffen sind alle selbst betriebenen Docs-Instanzen, ob per Helm-Chart oder per eigener Docker-Compose-Konfiguration. Nutzer der gehosteten Angebote müssen nichts tun. Für Admins gilt: Kein Update im laufenden Betrieb einspielen, sondern ein Wartungsfenster einplanen und zuerst ein Backup von Datenbank und Medienbucket ziehen.
Was ist passiert?
Das Projekt suitenumerique/docs hat Version 6.0.0 laut GitHub-Release-Seite am 9. Oktober 2026 veröffentlicht. Die Docker-Images auf Docker Hub wurden am selben Tag gebaut, für amd64 und arm64. In den Release-Notes heißt es, der Kollaborationsserver wechsle zu yhub. Das sei ein „significant change of stack“, die Upgrade-Anleitung solle vor dem Update gelesen werden.
yhub stammt von Kevin Jahns (GitHub: dmonad), dem Entwickler von Yjs, der Grundlage für die Echtzeitbearbeitung. Docs nutzt ihn über „yhub-server“, einen dünnen Wrapper für Docs. Laut Release-Notes soll das mehr Stabilität bringen und neue Funktionen ermöglichen. Bereits in 6.0.0 enthalten sind unter anderem ein lokaler Offline-Cache für Dokumente, ein HTTP-Polling-Fallback bei blockiertem Websocket, optionale Prometheus-Metriken und das Duplizieren von Dokumenten samt Unterseiten.
Die Upgrade-Datei trägt für 6.0.0 das Datum 5. Oktober 2026, veröffentlicht wurde das Release aber erst am 9. Oktober. Maßgeblich für die Verfügbarkeit ist das Release-Datum.
Für wen ist das relevant?
Relevant ist die Änderung für jede Instanz, die auf Version 5.7.0 oder älter läuft und aktualisiert werden soll. Die Upgrade-Anleitung verlangt, Minor- und Major-Versionen nicht zu überspringen. Wer noch auf einer deutlich älteren Version steht, braucht also zuerst die Zwischenschritte. Wer Docs nur über einen Dienstleister bezieht, sollte nachfragen, ob und wann die Migration geplant ist.
Besonders betroffen sind Setups mit eigenen Reverse-Proxy-Regeln für den Pfad /collaboration/, mit Integrationen über die Docs-API und mit aktiviertem Resource Server (OIDC_RESOURCE_SERVER_ENABLED).
Was ändert sich technisch?
Laut UPGRADE.md kommen zwei neue Abhängigkeiten ins Spiel: Der yhub-Server hält den Live-Zustand in Redis oder Valkey und speichert Dokumente in einer eigenen PostgreSQL-Datenbank. Beides muss bereitgestellt werden, es gibt keine Standardwerte.
| Komponente | Änderung in 6.0.0 |
|---|---|
| lasuite/impress-yhub | Neuer Dienst auf Port 3002, ersetzt den y-provider unter /collaboration/ |
| Redis oder Valkey und PostgreSQL | Per REDIS und POSTGRES konfigurieren, eigene Datenbank namens yhub |
| Datenbankschema | Wird nicht beim Start angelegt, sondern per yarn init-db (idempotent, nach jedem Upgrade erneut) |
| y-provider | Nur noch Konvertierungsdienst, liefert keinen Websocket mehr |
| Websocket-URL | COLLABORATION_WS_URL lautet wss://{domain}/collaboration/ws/v1/docs |
| Backend-Anbindung | YHUB_API_BASE_URL ist jetzt Pflicht |
| Schlüssel | Backend braucht JWT_PRIVATE_KEY, yhub einen eigenen YHUB_JWT_PRIVATE_KEY (je RSA) |
| COLLABORATION_SERVER_SECRET | Entfällt auf beiden Seiten |
Wie läuft die Datenmigration?
Die bisherigen Dokumente liegen im Medienbucket unter dem Schlüssel {Dokument-ID}/file. Der neue Server kennt sie zunächst nicht. Die Anleitung sieht zwei Schritte in fester Reihenfolge vor:
- SOFT_MIGRATION=true am yhub-Server setzen, bevor Nutzer Zugriff bekommen, und den Bucket über die LEGACY_S3_*-Variablen angeben. Ein Dokument wird dann beim ersten Öffnen aus dem alten Snapshot übernommen.
- Anschließend python manage.py migrate_documents ausführen. Der Befehl übergibt alle Dokumente samt vollständiger S3-Versionshistorie, ist begrenzbar, wiederholbar und kennt --dry-run sowie --retry-failed.
- SOFT_MIGRATION erst abschalten, wenn der Bestand vollständig migriert ist. Sonst öffnen nicht migrierte Dokumente leer.
- Die alten Objekte unter {Dokument-ID}/file samt Versionen nicht löschen, solange die Migration läuft. Die Anleitung nennt das ausdrücklich ohne Weg zurück.
Für den Bucket genügen laut Anleitung schreibgeschützte Zugangsdaten. Unter AWS wird zusätzlich s3:ListBucket benötigt, sonst erscheinen neue Dokumente als 403 statt 404 und lassen sich nicht öffnen.
Wie kritisch ist das?
Es handelt sich nicht um eine Sicherheitslücke, sondern um ein Update mit hohem Planungsaufwand. Das Risiko liegt in einem unvollständigen Umstieg: leere Dokumente, ausfallende Echtzeitbearbeitung oder zu offen veröffentlichte interne Routen. Die Anleitung warnt etwa davor, Pfade wie migrate, create-ydoc, reset-connections, restore-ydoc, reset-ydoc und prune öffentlich zu routen, da sonst Dokumentlöschung und Migration aus dem Internet erreichbar wären. Veröffentlicht werden sollen nur der Websocket, die Routen ydoc, activity, changeset, rollback und jwks.
Ein sicherheitsrelevanter Punkt steht in den Release-Notes: Nutzer mit reinem Lesezugriff teilen ihren Cursor nicht mehr. Hinzu kommen API-Änderungen:
| Entfernt oder verschoben | Folge für Integrationen |
|---|---|
| documents/{id}/content/ (GET und PATCH) | Entfällt, Inhalt läuft nur noch über den Kollaborationsserver |
| documents/{id}/can-edit/ | Entfällt samt Fähigkeit can_edit |
| documents/{id}/versions/ und versions/{version_id}/ | Entfallen, die Historie liefert yhub |
| JWKS des Resource Servers | Von /api/{version}/jwks nach /external_api/{version}/jwks verschoben |
Was sollten Admins jetzt tun?
- Installierte Version prüfen (Image-Tags von impress-backend, impress-frontend und impress-y-provider) und feststellen, ob Zwischenversionen fehlen.
- Vollständiges Backup anlegen: PostgreSQL-Datenbank von Docs und das Medienbucket inklusive Versionen. Eine Wiederherstellung testweise durchspielen.
- Redis/Valkey und eine PostgreSQL-Datenbank für yhub bereitstellen und yarn init-db ausführen.
- Zwei getrennte RSA-Schlüssel erzeugen (Backend und yhub) und als Datei einbinden, zum Beispiel über die _FILE-Variablen.
- Reverse-Proxy anpassen: neue Websocket-URL, Routing von /collaboration/ auf yhub, sticky-Annotation upstream-hash-by entfernen, interne Routen nicht freigeben.
- Zuerst eine Staging-Kopie migrieren, mit migrate_documents --dry-run beginnen und die Anzahl der migrierten Dokumente prüfen.
- Eigene Integrationen auf die entfernten Endpunkte durchsuchen und anpassen.
- COLLABORATION_SERVER_SECRET und nicht mehr gelesene Variablen aus der Konfiguration entfernen.
Einordnung für Unternehmen
Docs steht unter MIT-Lizenz und hat laut GitHub-Abruf am 11. Oktober 2026 rund 16.900 Sterne. Das Projekt wird aktiv gepflegt, der letzte Push liegt am 10. Oktober. Für kleine Teams mit einer einzelnen Instanz ist die Migration machbar, verlangt aber saubere Vorbereitung, weil zwei zusätzliche Dienste und neue Schlüssel zu betreiben sind. Der Betrieb wird komplexer, das Monitoring bekommt dafür neue optionale Prometheus-Metriken.
Ein belastbarer Rückweg ist vorab zu klären. Ein Zurückrollen nach produktiver Nutzung von yhub ist in den Quellen nicht beschrieben, neu angelegte Inhalte lägen nur im neuen Server. Daher gehört ein Snapshot von Datenbank und Bucket vor den Start, und der Wechsel sollte außerhalb der Arbeitszeit erfolgen. Die Angaben stützen sich auf die Upgrade-Anleitung, ein Praxistest auf eigener Infrastruktur wurde für diesen Beitrag nicht durchgeführt.
Passende Anleitungen auf S-EDV
- PostgreSQL sichern und migrieren mit pg_dump und pg_restore, passend zum Backup vor der Migration.
- Redis in Docker als In-Memory-Store betreiben, passend zum neuen Redis-Bedarf von yhub.
- Restore-Test-Routine für Backups etablieren, damit der Rückweg vor dem Update belegt ist.
