Nextcloud Rich Documents: Wenn der eigene Server zum Büro wird

Es gibt diese Momente in Projekten, in denen sich die ganze Diskussion um Souveränität, Datenschutz und digitale Infrastruktur plötzlich auf eine einzige, sehr praktische Frage zuspitzt: Kann ich in einer Tabelle eigentlich genauso arbeiten wie bisher? Nicht abstrakt, nicht als Grundsatzdebatte, sondern ganz konkret – Formel eintippen, Zelle ziehen, Kommentar hinterlassen, gleichzeitig mit zwei Kolleginnen im selben Dokument. Wer Nextcloud als Kollaborationsplattform betreibt, kommt an dieser Frage nicht vorbei. Und die Antwort heißt seit einigen Jahren immer öfter: Nextcloud Rich Documents, heute offiziell als Nextcloud Office vermarktet.

Dahinter steckt mehr, als der sperrige Name vermuten lässt. Denn im Kern geht es nicht um einen einzelnen Editor, sondern um ein Zusammenspiel aus Dateiverwaltung, Berechtigungskonzept, einem separaten Office-Server und einem Protokoll, das ursprünglich aus dem Hause Microsoft stammt. Wer das versteht, versteht auch, warum die Einrichtung manchmal zickt, warum eine eigene Subdomain Pflicht ist und warum ein einzelner Container für ein kleines Team völlig reicht – für zweihundert Nutzer aber nicht mehr.

Ein Name, drei Bedeutungen: das übliche Wirrwarr

Zunächst ein wenig Aufräumarbeit, denn die Begriffe werden in Foren, Blogs und nicht selten auch in Herstellerunterlagen munter durcheinandergeworfen. „Rich Documents“ ist der interne Name der Nextcloud-App, deren App-Store-Kennung bis heute richdocuments lautet. In der Benutzeroberfläche heißt das Ganze seit Nextcloud 21 „Nextcloud Office“. Gemeint ist jedes Mal dasselbe: die Server-Integration, die aus der Nextcloud-Dateiübersicht heraus einen vollwertigen Editor startet.

Der Editor selbst kommt nicht von Nextcloud. Er heißt Collabora Online und basiert auf der Codebasis von LibreOffice. Das ist ein wichtiger Punkt, denn es bedeutet: Die Formel-Engine, die Zeichensetzung, die Filter für DOCX und XLSX – all das stammt aus jahrelanger Arbeit an einem Büropaket, das auf dem Desktop seit Jahrzehnten gegen Word & Co. antritt. Collabora gießt diesen Unterbau in einen Serverprozess, der Dokumente im Browser darstellt, und nennt ihn coolwsd – früher loolwsd.

Nicht zu verwechseln ist das mit Nextcloud Text. Diese App ist ein schlanker Markdown-Editor für Notizen, Kollektivseiten und kurze Entwürfe. Sie hat ihre Berechtigung, ist aber kein Ersatz für eine Tabellenkalkulation. Und auch nicht mit ONLYOFFICE, das als eigenständiger Connector existiert und einen komplett anderen Dokumentenserver mitbringt. Dazu später mehr.

Wie das technische Innenleben tickt

Die entscheidende Frage lautet: Wie kommt ein Dokument von der Nextcloud in den Browser, ohne dass jemand eine Datei herunterlädt, lokal bearbeitet und wieder hochlädt? Die Antwort ist ein Protokoll namens WOPI – Web Application Open Platform Interface. Ursprünglich von Microsoft für Office Online Server spezifiziert, hat es sich als Quasi-Standard für genau diese Art der Anbindung etabliert.

Im WOPI-Modell gibt es zwei Rollen. Die Nextcloud ist der WOPI Host: Sie verwaltet die Dateien, kennt die Berechtigungen, vergibt Versionen und entscheidet, wer was darf. Collabora Online ist der WOPI Client: Er holt sich das Dokument über eine HTTP-Schnittstelle ab, rendert es im Browser und schickt Änderungen zurück. Klingt unspektakulär, ist aber der Grund, warum Collabora selbst keinerlei Dateien speichert. Es gibt keine zweite Datenhaltung, keine Schattenkopie, keinen Sync-Konflikt. Der Speicher bleibt da, wo er hingehört.

Der Ablauf im Detail sieht dann so aus: Ein Nutzer klickt in der Nextcloud auf eine ODT-Datei. Die App richdocuments erzeugt einen Zugriffstoken und leitet den Browser auf die Collabora-Instanz um – in der Regel unter einer eigenen Subdomain wie office.example.org. Dort startet coolwsd für dieses eine Dokument einen eigenen Kit-Prozess. Der Kit ist eine abgespeckte LibreOffice-Instanz, die das Dokument lädt, in Zeichenbefehle umwandelt und an den Browser schickt. Jede Tastatureingabe, jeder Mausklick geht als Nachricht zurück, wird angewendet und an die anderen Teilnehmer der Sitzung verteilt.

Genau hier wird es architektonisch interessant. Collabora arbeitet nicht mit einem großen Editorprozess, in dem alle Dokumente aller Nutzer liegen, sondern mit einem Prozess pro Dokument. Das ist gut für die Isolation – ein Absturz reißt nicht die gesamte Instanz mit – und schlecht für den Speicherbedarf. Dazu später mehr, denn das ist der Punkt, an dem viele Kapazitätsplanungen scheitern.

Zwischen Browser und coolwsd läuft eine WebSocket-Verbindung. Ohne die geht gar nichts, und deshalb ist die Konfiguration des vorgeschalteten Reverse Proxy der zweithäufigste Grund für weiße Seiten und Fehlermeldungen wie „Failed to load document“. Der Proxy muss Upgrade-Header durchreichen, ausreichend lange Timeouts haben und – das ist der Klassiker – die Subdomain sauber von der Hauptdomain trennen.

Warum die getrennte Domain kein Selbstzweck ist

Immer wieder hört man den Vorschlag, Collabora doch einfach unter cloud.example.org/collabora mitlaufen zu lassen. Technisch ist das möglich, praktisch ist es eine schlechte Idee. Denn Nextcloud und Collabora setzen beide Cookies, beide haben eigene Content-Security-Policies, und beide gehen von einem eigenen Origin aus. Werden sie unter derselben Domain betrieben, kann es zu Konflikten kommen, die sich nur schwer nachvollziehen lassen – plötzlich fehlt die Session, oder die CSP blockiert Skripte, die der Editor braucht.

Die saubere Lösung ist eine eigene Subdomain mit gültigem TLS-Zertifikat. Das kostet nichts außer einem DNS-Eintrag und einem Zertifikat, spart aber Stunden Fehlersuche. In der Praxis hat sich ein Aufbau bewährt, bei dem ein zentraler Reverse Proxy (nginx, Apache, Caddy, Traefik – was auch immer im Haus üblich ist) beide Domains terminiert und die internen Dienste auf getrennten Ports anspricht. Collabora selbst lauscht dann nur auf dem internen Netz auf Port 9980 und ist von außen gar nicht erreichbar.

Ein interessanter Aspekt dabei: Die Nextcloud muss die Collabora-Instanz nicht nur erreichen können, sondern auch umgekehrt. Denn der WOPI-Client ruft den Host auf, um Dateien zu laden und zu speichern. In containerisierten Umgebungen führt das gern zu dem Problem, dass die Nextcloud intern unter einem Docker-Hostnamen erreichbar ist, Collabora aber eine öffentlich auflösbare URL braucht. Nextcloud löst das über zwei Konfigurationswerte – eine interne und eine öffentliche WOPI-URL. Wer das nicht sauber trennt, bekommt Fehler, die nur im Zusammenspiel sichtbar werden.

Betriebsmodelle: von der Spielwiese zur Produktion

Für den Einstieg gibt es die Collabora Online Development Edition, kurz CODE. Sie ist kostenlos, quelloffen unter AGPLv3 und als Containerimage collabora/code verfügbar. Wer Nextcloud schon containerisiert betreibt, hat sie in einer Viertelstunde am Laufen. Die Einschränkungen sind überschaubar, aber vorhanden: CODE ist ausdrücklich für Entwicklung und kleine Umgebungen gedacht, bekommt keine offiziellen Sicherheitsupdates in derselben Taktung wie die Enterprise-Variante und ist in der Zahl gleichzeitiger Bearbeitungssitzungen limitiert.

Für Produktivumgebungen mit Supportanspruch führt der Weg zur kommerziellen Collabora Online oder zu einem Nextcloud-Office-Abonnement. Beide Modelle sind lizenzrechtlich ähnlich aufgebaut: Be­zahlt wird in der Regel nach gleichzeitigen Verbindungen beziehungsweise nach Nutzern, nicht nach Installation. Das ist ein Modell, das gerade für Behörden und mittelständische Betriebe attraktiv ist, weil die Kosten skalieren, ohne dass man für Gelegenheitsnutzer zahlen muss.

Seit einigen Versionen gibt es außerdem den Nextcloud All-in-One-Installer, der Collabora als optionalen Container gleich mitbringt. Das ist für kleinere Installationen eine durchaus vernünftige Lösung – die Konfiguration von Proxy, Zertifikat und WOPI-URL übernimmt der Installer. Man sollte sich allerdings im Klaren darüber sein, dass man damit eine Blackbox betreibt. Wer die Zusammenhänge verstehen will, sollte einmal eine manuelle Installation durchlaufen haben.

Jenseits davon existiert die Variante, Collabora auf Kubernetes zu betreiben. Collabora liefert dafür Helm-Charts, und der Ansatz ist technisch reizvoll, weil sich Instanzen horizontal skalieren lassen. Die Praxis zeigt aber: Der Betrieb mehrerer coolwsd-Instanzen hinter einem Load Balancer erfordert Sticky Routing oder ein sauberes Session-Konzept, denn eine laufende Bearbeitungssitzung ist an die Instanz gebunden, auf der sie gestartet wurde. Wer es einfach halten will, fährt eine ausreichend dimensionierte Instanz und skaliert vertikal.

Was im Alltag tatsächlich passiert

Die eigentliche Stärke von Nextcloud Office zeigt sich nicht in der Feature-Liste, sondern im Zusammenspiel. Ein Dokument wird geteilt, jemand öffnet es, bearbeitet es, die Änderungen landen als neue Version in der Nextcloud. Das Aktivitätenprotokoll vermerkt, wer wann geschrieben hat. Kommentare im Dokument landen in der Seitenleiste und tauchen in den Benachrichtigungen auf. Wer in einem Talk-Anruf sitzt, kann ein Dokument direkt im Anruf öffnen und gemeinsam daran arbeiten – ein Feature, das von vielen unterschätzt wird und in der Praxis erstaunlich gut funktioniert.

Auch die Ordnerfreigaben spielen mit. Gruppenordner, Team-Ressourcen, externe Speicher – solange die Berechtigungen sitzen, funktioniert das Öffnen aus jeder Ansicht heraus. Interessant ist der Umgang mit öffentlichen Links: Ein Freigabelink mit Schreibrechten erlaubt tatsächlich die Bearbeitung ohne Login, sofern der Administrator das nicht unterbunden hat. Für Formulare, Protokolle oder gemeinsame Listen ist das praktisch, sicherheitstechnisch aber ein Punkt, den man bewusst entscheiden sollte.

Ein weniger bekannter Baustein sind die Dokumentvorlagen. Im Administrationseinstellungen lassen sich eigene ODT-, ODS- oder ODP-Dateien hinterlegen, aus denen Nutzer neue Dokumente erzeugen. Seit Nextcloud 27 sind diese Vorlagen auch gruppenbezogen möglich – die Buchhaltung bekommt also ein anderes Tabellenlayout als die Entwicklungsabteilung. Das klingt nach Detail, spart in der Praxis aber erheblich Reibung, weil sich Formatvorgaben so zentral durchsetzen lassen.

Und dann ist da noch die Frage der Schriftarten. Nichts sorgt in Office-Umgebungen für mehr Verwirrung als verschobene Zeilenumbrüche, weil ein Font fehlt. Nextcloud bietet inzwischen eine Schriftartenverwaltung, über die sich eigene Fonts in die Collabora-Instanz einspielen lassen. Wer mit Corporate Design arbeitet, kommt daran nicht vorbei.

Sicherheit: mehr als nur ein Container

Wer einen Dienst bereitstellt, der Dokumente beliebigen Inhalts rendert, sollte sich über die Angriffsfläche im Klaren sein. Ein Office-Parser ist historisch betrachtet ein dankbares Ziel – obskure Dateiformate, komplexe Makro-Unterstützung, jahrzehntelang gewachsene Codebasen. Collabora begegnet dem mit mehreren Schichten.

Zum einen läuft der Kit-Prozess in einer sandboxed Umgebung. Unter Linux kommen seccomp-Filter und eine reduzierte Capability-Menge zum Einsatz, sodass selbst ein kompromittierter Kit-Prozess nur begrenzten Schaden anrichten kann. Zum anderen ist der Prozess pro Dokument getrennt, was verhindert, dass eine Schwachstelle den gesamten Server übernimmt. Wer den Container zusätzlich mit einem eigenen Nutzer, read-only gemounteten Verzeichnissen und begrenzten Ressourcen betreibt, hat bereits sehr viel erreicht.

Ein zweiter Bereich betrifft die Zugriffskontrolle. Collabora sollte niemals direkt aus dem Internet erreichbar sein, sondern immer hinter dem Proxy. Der Zugriff auf Dokumente läuft ausschließlich über WOPI und damit über Token, die die Nextcloud ausstellt. Technisch kann man die Kommunikation zusätzlich mit JWT absichern, sodass nur der Proxy oder die Nextcloud überhaupt Anfragen an coolwsd stellen darf. In der Standardkonfiguration vieler Anleitungen fehlt das – und das ist eine Lücke, die man nicht offen lassen sollte.

Schließlich die Makrofrage. Collabora kann Basic-Makros ausführen, standardmäßig ist das aber deaktiviert. Das ist gut so. Sobald Makros erlaubt sind, öffnet man einen Kanal, der sich nur schwer kontrollieren lässt. Wer darauf angewiesen ist – etwa wegen alter Excel-Dateien – sollte sich sehr genau überlegen, ob das Risiko zum Nutzen passt.

Erwähnen sollte man an dieser Stelle, dass Ende-zu-Ende-Verschlüsselung und serverseitige Bearbeitung nicht zusammenpassen. Das ist keine Schwäche von Nextcloud, sondern eine logische Konsequenz: Der Server muss das Dokument im Klartext sehen, um es rendern zu können. Wer E2E-Verschlüsselung nutzt, muss für Office-Dateien auf eine Ausnahme umschalten oder auf den Browser-Editor verzichten. Das sollte man wissen, bevor man beides gleichzeitig einplant.

Ressourcen: rechnen statt raten

Die häufigste Fehleinschätzung beim Betrieb von Collabora betrifft den Speicherbedarf. Der Kit-Prozess pro Dokument ist nicht gerade zimperlich. Je nach Dateigröße und Komplexität sind 50 bis 150 Megabyte pro geöffneter Datei realistisch, bei großen Tabellen mit vielen Formeln auch mehr. Zehn gleichzeitig bearbeitete Dokumente bedeuten also schnell ein bis anderthalb Gigabyte, bevor überhaupt das Betriebssystem, die Datenbank und die Nextcloud selbst gerechnet sind.

Für eine mittlere Arbeitsgruppe mit zwanzig bis dreißig aktiven Personen, von denen vielleicht ein Drittel gleichzeitig in Dokumenten arbeitet, sind vier bis acht CPU-Kerne und acht bis sechzehn Gigabyte Arbeitsspeicher eine vernünftige Ausgangsbasis. Wichtig ist, den Container nicht mit zu engen Speicherlimits zu betreiben, sonst sterben Kit-Prozesse unter Last ab – und die Nutzer sehen einen Editor, der beim Speichern einfach stehenbleibt.

Ein weiterer Punkt ist die Konfiguration der Sitzungszeiten. Standardmäßig werden Dokumente nach einer gewissen Zeit der Inaktivität geschlossen und gespeichert. Wer sehr große Tabellen bearbeitet und zwischendurch telefonieren muss, ärgert sich über zu kurze Zeitfenster. Hier lohnt ein Blick in die Optionen für Idle-Save- und Idle-Close-Zeiten. Umgekehrt gilt: Zu lange offene Sitzungen halten Speicher, ohne dass jemand arbeitet.

Auf der Nextcloud-Seite ist Redis als Sperr-Backend praktisch zwingend. Collabora schreibt Änderungen in kurzen Intervallen zurück, und ohne sauberes File-Locking entstehen Race Conditions, bei denen Versionen sich überschreiben. Das transaktionale Sperren von Nextcloud über Redis ist deshalb nicht nur eine Empfehlung für größere Installationen, sondern gehört zumindest bei allem oberhalb einer Handvoll Nutzer zur Grundausstattung.

Formate: nah dran, aber nicht identisch

Die Gretchenfrage in jedem Migrationsprojekt lautet: Öffnet das Ding meine Dateien so, wie Word es tut? Die ehrliche Antwort lautet: meistens ja, manchmal fast, und in Ausnahmefällen nein. Das liegt in der Natur der Sache. OOXML ist ein extrem komplexes Format, dessen Spezifikation viele Interpretationsspielräume lässt. Während Microsoft das Format mit jeder Office-Version weiterentwickelt, wandert LibreOffice hinterher.

Für den Alltag – Textdokumente mit Formatierungen, Tabellen mit gängigen Funktionen, Präsentationen mit einfachen Animationen – ist die Kompatibilität inzwischen sehr gut. Schwierig wird es bei sehr neuen Excel-Funktionen, bei komplexen Pivot-Tabellen, bei Word-Dokumenten mit aufwendigen Verweisstrukturen und bei allem, was tief in die VBA-Welt hineinreicht. Wer hier Anforderungen hat, sollte vor der Umstellung mit echten Dateien testen und nicht mit Beispieldokumenten aus der Marketingabteilung.

Wichtig ist die Unterscheidung zwischen ODF und OOXML. ODF, also ODT, ODS und ODP, ist das native Format und wird verlustfrei verarbeitet. Wer neu anfängt und die Wahl hat, fährt mit ODF besser – technisch sauberer, herstellerunabhängig, langfristig stabiler. Wer mit Unternehmen und Behörden zusammenarbeitet, wird trotzdem DOCX und XLSX verschicken, und das funktioniert auch. Aber es bleibt eine Formatkonvertierung, und Konvertierungen kosten immer ein paar Prozent Originaltreue.

PDF ist als Ausgabeformat selbstverständlich verfügbar, und auch das Öffnen und Kommentieren von PDFs funktioniert – ein Feature, das viele gar nicht auf dem Schirm haben. Echte PDF-Bearbeitung ist über den Draw-Unterbau möglich, aber fummelig. Wer regelmäßig PDF-Formulare ausfüllen oder Layouts anpassen muss, sollte sich nach spezialisierten Werkzeugen umsehen.

Wo die Grenzen liegen

Man tut dem Produkt keinen Gefallen, wenn man es überzeichnet. Es gibt Dinge, die Nextcloud Office schlicht nicht kann. Da ist zuerst die Tiefe der Microsoft-Integration. Wer Power Query nutzt, Excel-Makros pflegt oder mit Power BI arbeitet, wird feststellen, dass diese Funktionen fehlen oder nur eingeschränkt vorhanden sind. Gleiches gilt für sehr spezialisierte Outlook-Funktionen und alles rund um das Microsoft-365-Ökosystem.

Zweitens: Die gleichzeitige Bearbeitung funktioniert, ist aber nicht immer so geschmeidig wie bei Google Docs. Bei vielen Teilnehmern und großen Dokumenten kann es zu spürbaren Verzögerungen kommen. Wer große Redaktionsteams in einem einzigen Manuskript arbeiten lässt, wird die Grenzen kennenlernen.

Drittens: Die Einbindung in föderierte Freigaben ist historisch gewachsen und war lange eingeschränkt. Wenn Instanzen Dokumente untereinander teilen sollen, funktioniert das nicht in allen Kombinationen reibungslos. Das ist einer der Bereiche, in denen ich mir mehr Konsistenz wünschen würde – nicht zuletzt, weil Nextcloud die Föderation sonst so prominent bewirbt.

Und viertens, weniger technisch: Die Bedienung ist anders. Wer jahrelang mit der Menübandlogik von Microsoft Office gearbeitet hat, findet sich zurecht, aber nicht sofort. Das ist ein Schulungsthema, kein technisches. Wer das unterschätzt, produziert Frust, der am Ende dem Projekt angelastet wird.

Die Alternativen im Blick behalten

Es wäre unredlich, so zu tun, als wäre Collabora die einzige Option. ONLYOFFICE ist der prominenteste Mitbewerber. Der Document Server ist funktional stark, die Kompatibilität zu OOXML gilt teilweise als besser, und die Oberfläche erinnert stärker an das, was viele gewohnt sind. Allerdings ist die Lizenzlage komplizierter, die Integration in Nextcloud läuft über einen separaten Connector, und die Entwicklung steht unter der Kontrolle eines einzelnen Unternehmens mit entsprechenden Interessen.

Genau daraus ist 2025 eine interessante Entwicklung entstanden: Euro-Office, ein Community-Fork, an dem auch Nextcloud beteiligt ist. Die Grundidee ist, die technische Basis von ONLYOFFICE weiterzuentwickeln, ohne von einer einzelnen Firmenstrategie abhängig zu sein. Ob sich das durchsetzt, ist derzeit offen, aber für Betreiber, die langfristige Planungssicherheit suchen, ist es ein Faktor, den man beobachten sollte.

Daneben existieren Nischenlösungen wie CryptPad für kollaboratives Bearbeiten mit Ende-zu-Ende-Verschlüsselung – mit anderen Kompromissen bei den Formaten – oder Etherpad für reine Textkollaboration. Für bestimmte Anwendungsfälle sind das sinnvolle Ergänzungen, keine Ersätze.

Und natürlich bleibt die Option, ganz auf serverseitige Bearbeitung zu verzichten und weiterhin Desktop-Office mit synchronisierten Dateien zu nutzen. Das ist nicht rückständig, sondern eine bewusste Architekturentscheidung mit eigenen Vor- und Nachteilen. Nur: Dann braucht man kein Rich Documents, und die Diskussion hat sich erledigt.

Der Praxisteil: was beim Debuggen hilft

Wenn es nicht läuft – und am Anfang läuft es selten sofort – hilft ein systematisches Vorgehen. Der erste Blick gilt immer dem Browser: Öffnet die Entwicklerkonsole, und wenn dort WebSocket-Fehler auftauchen, liegt es fast immer am Proxy. Fehlende Upgrade-Header, fehlendes proxy_read_timeout, falsche Weiterleitung – das sind die Klassiker.

Der zweite Blick gilt den Logs. Collabora schreibt in den Container beziehungsweise nach /var/log, und die Ausgabe ist gesprächig. Ein Blick in die Admin-Konsole von coolwsd, erreichbar über einen eigenen Pfad, zeigt laufende Dokumente, Speicherverbrauch und aktive Verbindungen. Das ist erstaunlich hilfreich, wenn man wissen will, ob eine Sitzung überhaupt zustande gekommen ist.

Der dritte Blick gilt der Verbindung zwischen den beiden Systemen. Kann die Nextcloud die Collabora-Instanz erreichen? Kann Collabora die Nextcloud erreichen? Stimmen die URLs, inklusive Port und Schema? Der häufigste Fehler in containerisierten Umgebungen ist eine öffentliche URL, die intern nicht auflösbar ist – oder umgekehrt. Hier lohnt es, sich Zeit zu nehmen und die Konfiguration sauber zu dokumentieren, statt später im Fehlerfall zu raten.

Und ein vierter Punkt, der oft unterschätzt wird: Versionen. Nextcloud-Apps und Collabora-Builds müssen halbwegs zueinander passen. Wer Collabora aktualisiert, sollte die Nextcloud-App im Blick behalten und umgekehrt. Ein Blick in die Release Notes vor dem Update ist keine Pedanterie, sondern spart im Zweifel einen Abend.

Ausblick: wohin die Reise geht

Die Richtung ist klar erkennbar. Serverseitige Office-Bearbeitung ist kein Nischenfeature mehr, sondern gehört zum Standardumfang einer Kollaborationsplattform. Wer heute eine Nextcloud aufsetzt und die Bearbeitung nicht mitdenkt, baut an den Bedürfnissen der Nutzer vorbei. Entsprechend investieren sowohl Nextcloud als auch Collabora in diesen Bereich.

Zwei Entwicklungen sind dabei besonders spannend. Zum einen die Frage der Unabhängigkeit von einzelnen Herstellern. Die Diskussion um Euro-Office hat gezeigt, dass es ein Bewusstsein dafür gibt, wie verletzlich eine Infrastruktur wird, wenn sie auf einem einzigen Anbieter aufsetzt. Zum anderen die zunehmende Bedeutung von KI-Funktionen direkt im Editor – Textzusammenfassungen, Formelvorschläge, Übersetzungen. Hier wird sich entscheiden, ob diese Funktionen lokal betrieben werden können oder ob sie eine Rückkehr zu Cloud-Diensten erzwingen. Für viele Betreiber ist das die eigentliche Gretchenfrage der nächsten Jahre.

Fazit

Nextcloud Rich Documents ist kein Microsoft-Ersatz für jeden Anwendungsfall, aber es ist ein ernst zu nehmendes Werkzeug. Es funktioniert dann gut, wenn man versteht, wie es aufgebaut ist: Nextcloud als Datendrehscheibe, Collabora als Renderer, WOPI als Bindeglied, ein sauber konfigurierter Proxy als Voraussetzung. Wer sich die Mühe macht, die Architektur zu durchdringen, statt einfach ein Containerimage zu starten, wird mit einer Lösung belohnt, die Datensouveränität und Alltagstauglichkeit unter einen Hut bringt.

Und wer die Grenzen kennt, kann sie offen kommunizieren – an die Nutzer, an die Geschäftsführung, an die Kolleginnen in der Verwaltung. Das ist am Ende die eigentliche Voraussetzung dafür, dass ein solches Projekt gelingt. Nicht die technische Installation ist die Herausforderung, sondern die ehrliche Einschätzung dessen, was man von der eigenen Infrastruktur erwarten kann. Genau dort entscheidet sich, ob aus einem Pilotprojekt ein dauerhafter Betrieb wird.