Nextcloud und Collabora Online: Wenn die eigene Cloud plötzlich ernst genommen wird

Es gibt diesen Moment in vielen IT-Abteilungen, in dem jemand eine Tabelle mit Lizenzkosten öffnet und danach erst einmal eine Weile auf den Bildschirm starrt. Nicht weil die Zahlen falsch wären, sondern weil sie so unspektakulär steigen. Pro Benutzer, pro Monat, pro Funktionspaket. Dazu kommen Speicher, der separat abgerechnet wird, und der eine Anbieter, der einen neuen Tarif einführt, in dem genau das Feature nicht mehr enthalten ist, das die Fachabteilung gerade schätzen gelernt hat. Es ist selten der eine große Schock, es ist die Summe aus vielen kleinen Rechnungen.

Genau an dieser Stelle setzt Nextcloud an, seit mittlerweile über einem Jahrzehnt. Die Plattform verspricht nichts Geringeres als die Rückkehr der Dateiablage in die eigene Verantwortung – mit Kalender, Kontakten, Chat und neuerdings auch Dokumentenbearbeitung im Browser. Was viele dabei übersehen: Nextcloud ist keine fertige Software, die man installiert und vergisst. Es ist eher ein Baukasten mit sehr guter Anleitung und einer aktiven Community, der man allerdings auch Arbeit schuldet. Wer das akzeptiert, bekommt eine erstaunlich flexible Kollaborationsplattform. Wer es ignoriert, bekommt einen Server, der nach achtzehn Monaten ungepatcht im Rack vor sich hin rostet.

Der zweite große Baustein, um den es hier gehen soll, ist die Frage der gemeinsamen Dokumentbearbeitung. Eine Dateiablage, in der man Dokumente nur herunterladen, ändern und wieder hochladen kann, ist 2025 nur noch die halbe Miete. Ohne gleichzeitiges Bearbeiten im Browser fehlt der Zauber, der Google Docs und Microsoft 365 so schwer angreifbar macht. Für Nextcloud gibt es dafür mehrere Wege – der bekannteste und in Europa am weitesten verbreitete heißt Collabora Online. Um dieses Duo, seine Architektur, seine Fallstricke und seine Grenzen soll es im Folgenden gehen.

Was Nextcloud ist – und was es ausdrücklich nicht ist

Die Geschichte beginnt 2016, als der damalige ownCloud-Gründer Frank Karlitschek mit einem großen Teil des Entwicklungsteams das Unternehmen verließ und den Fork Nextcloud aufsetzte. Das Modell war von Anfang an ein anderes: Die Software blieb konsequent unter einer freien Lizenz (AGPLv3 für den Server), während das Unternehmen Geld mit Support, Enterprise-Versionen und Managed Services verdient. Dieses Modell hat sich bis heute gehalten und ist einer der Gründe, warum Nextcloud im Vergleich zu mancher Konkurrenz erstaunlich wenige Lizenzbaustellen hat.

Technisch ist Nextcloud, nüchtern betrachtet, eine Webanwendung auf PHP-Basis mit einer relationalen Datenbank im Rücken und einem Dateisystem darunter. Das klingt unspektakulärer, als es ist, denn daraus ergibt sich eine ganze Reihe von Konsequenzen. Die wichtigste: Nextcloud ist ein Metadaten- und Zugriffssystem, kein Speichersystem. Die Dateien selbst liegen weiterhin auf Platten, in einem NAS, auf einem S3-kompatiblen Objektspeicher oder irgendwo dazwischen. Wer das versteht, plant seine Umgebung gleich ganz anders.

Was Nextcloud nicht ist: eine verschlüsselte Festplatte für Paranoiker. Die serverseitige Verschlüsselung schützt gegen die entwendete Festplatte, aber sie schützt nicht gegen den Betreiber, der die Schlüssel hält. Wer das braucht, muss die Ende-zu-Ende-Verschlüsselung aktivieren, die es für einzelne Ordner gibt – mit den bekannten Einschränkungen, dass sich verschlüsselte Ordner nicht durchsuchen lassen und einige Apps damit nichts anfangen können. Auch kein Ersatz für ein Backup ist Nextcloud, trotz Synchronisation. Ein versehentlich gelöschtes Dokument verschwindet auch im Client, und wer dann kein Backup hat, hat ein Problem, kein Sync-Problem.

Die Architektur verstehen, bevor man sie aufbaut

Eine Nextcloud-Instanz besteht aus mehr beweglichen Teilen, als die Startseite vermuten lässt. Da ist zunächst der Webserver. In der Praxis läuft man meist mit nginx oder Apache, wobei nginx in größeren Umgebungen die üblichere Wahl ist – nicht weil er schneller wäre in jedem Fall, sondern weil die Konfiguration klarer zu bändigen ist. Dahinter sitzt PHP, heute mindestens in Version 8.1, besser 8.3, ausgeliefert über PHP-FPM. Der alte mod_php-Weg ist praktisch tot, und das ist gut so.

Dann die Datenbank. MariaDB, MySQL oder PostgreSQL, jeweils in aktueller Version. SQLite funktioniert für einen Testaufbau, ist aber im Mehrbenutzerbetrieb ein sicherer Weg ins Unglück – nicht sofort, aber spätestens dann, wenn mehrere Clients gleichzeitig synchronisieren. Eine weitere Annahme ist der utf8mb4-Zeichensatz, weil sonst früher oder später Emojis oder asiatische Schriftzeichen die Synchronisation abbrechen.

Schließlich die Speicherschicht. Klassisch ist ein lokales Datenverzeichnis, das aus naheliegenden Gründen außerhalb des Webroots liegen sollte. Darüber hinaus gibt es die Möglichkeit, ein Objekt-Backend als Primary Storage zu verwenden. Das ist spannend, sobald die Datenmenge wächst, weil sich dann mehrere Nextcloud-Knoten einen Speicher teilen können. Der Preis dafür: Jeder Dateizugriff wird zu einem Netzwerkaufruf, und die Latenz des Objektspeichers wird zum bestimmenden Faktor für das subjektive Tempo der Oberfläche.

Pflichtprogramm bei jeder etwas ernsthafteren Installation sind zwei Dinge: ein richtiger Redis für die Verteilung von Sperren und Cache, und der Systemcron. Es ist erstaunlich, wie viele träge Instanzen am Ende auf falsch konfigurierte Hintergrundaufgaben zurückzuführen sind. Der AJAX-Cron, den mancher Hoster aus Bequemlichkeit laufen lässt, mag für eine Ein-Personen-Instanz genügen. Für alles darüber hinaus ist er ein Fehler, der sich täglich rächt – Audit-Logs werden nicht geschrieben, Vorschaubilder nicht erzeugt, und die Synchronisation der externen Speicher hinkt hinterher.

Installationswege: vom Einplatinenrechner bis zur geclusterten Umgebung

Wer heute eine Nextcloud aufsetzt, hat im Wesentlichen vier Wege zur Auswahl, und die Wahl sagt viel über den geplanten Einsatzzweck aus.

Manuelle Installation auf einem klassischen Linux (Debian, Ubuntu LTS, RHEL-Clone). Maximaler Kontrolle, geringster Overhead, aber auch die meiste Verantwortung. Für Umgebungen mit klaren Betriebsroutinen oft die beste Wahl.
Docker-Compose-Aufbau mit getrennten Containern für Webserver, PHP-FPM, Datenbank, Redis und gegebenenfalls Collabora. Sauber trennbar, gut reproduzierbar, aber man sollte verstehen, was in den Containern passiert.
Nextcloud All-in-One (AIO). Ein Master-Container steuert das gesamte Geflecht, inklusive Reverse Proxy, Talk-Signaling und Borg-Backup. Für kleinere Teams und Umgebungen ohne tiefe Linux-Kenntnisse eine ausgesprochen praktische Sache – vorausgesetzt, man akzeptiert die etwas opake Steuerungsschicht.
Managed Hosting. Anbieter wie Hetzner, IONOS, BSI-zertifizierte Rechenzentrumsbetreiber oder spezialisierte Nextcloud-Häuser übernehmen Updates und Betrieb. Sinnvoll, wenn die eigene IT keine Lust auf PHP-Upgrades hat – dafür sitzt man wieder bei einem Dienstleister in der Lieferkette.

Unabhängig vom Weg gilt ein Grundsatz, den die Dokumentation seit Jahren wiederholt und der trotzdem regelmäßig ignoriert wird: Das Datenverzeichnis gehört nicht in den Webspace. Wer data/ unterhalb des DocumentRoot ablegt, weil „es ja praktisch ist“, darf sich nicht wundern, wenn Vorschaubilder oder gar ganze Dateien über den Webserver abrufbar sind, sobald eine Regel in der Konfiguration fehlt. Die zweite Regel lautet: Kein Upgrade ohne Backup der Datenbank. Wer das schon einmal vergessen hat, vergisst es danach nicht mehr.

Leistung ist kein Zufall: Caching, Datenbank, Speicher

Nextcloud ist keine sonderlich anspruchsvolle Anwendung, aber sie ist gesprächig. Ein Aufruf der Dateiliste kann schnell ein paar Dutzend Datenbankabfragen auslösen, und die Dateisynchronisation beim ersten Anmelden erzeugt Last, die man erst versteht, wenn man sie sieht. Entsprechend wichtig sind ein paar Optimierungen, die wenig kosten und viel bringen.

Erstens: Redis. Nicht nur als Cache, sondern vor allem für das transaktionale Locking. Ohne dieses kann es passieren, dass zwei Benutzer gleichzeitig denselben Ordner umbenennen und die Metadaten danach nicht mehr stimmen. Die Dokumentation zu „Memory caching“ ist lesenswert, und sie ist kurz.

Zweitens: OPcache für PHP. Die Standardeinstellungen in manchen Distributionen sind konservativ, und ein opcache.memory_consumption von 128 MB ist für Nextcloud selten zu viel.

Drittens: Die Datenbank. Für MariaDB heißt das meist, den InnoDB-Buffer-Pool deutlich anzupassen – auf einer Maschine mit 32 GB RAM darf der gerne 8 GB bekommen, sofern die Datenbank der einzige große Verbraucher ist. Ebenso sinnvoll ist es, den query_cache abzuschalten, weil er in neueren Versionen ohnehin entfernt wurde und früher mehr Schaden als Nutzen brachte.

Viertens: Die Vorschaubilder. Nextcloud erzeugt für Bilder und Videos Miniaturansichten, und das kostet CPU. Auf großen Instanzen lohnt es sich, diese Aufgabe gezielt an einen separaten Worker zu geben oder die Vorschau-Erzeugung per occ preview:pre-generate über Nacht laufen zu lassen. Wer Videos unterstützt, sollte ffmpeg installieren, sonst bleibt von jedem Videoclip nur ein graues Kästchen.

Fünftens, und das wird oft übersehen: Die Latenz des Speichers. Eine Nextcloud auf einem NAS mit SMB-Einbindung mag im Testbetrieb flüssig erscheinen. Sobald zwanzig Clients gleichzeitig synchronisieren, ist die SMB-Schicht der Flaschenhals, und alle Optimierungen am PHP-Code helfen dann nichts. Nicht zuletzt deshalb ist lokaler NVMe-Speicher oder ein gut angebundener Objektspeicher die bessere Grundlage.

Sicherheit: unglamourös, aber entscheidend

Nextcloud wird regelmäßig unabhängigen Sicherheitsprüfungen unterzogen, und es gibt keine Erkenntnisse, die auf eine strukturelle Nachlässigkeit hindeuten. Der Feind ist fast nie die Software selbst, sondern die Umgebung, in der sie läuft. Drei Bereiche verdienen deshalb besondere Aufmerksamkeit.

Zum einen die Authentifizierung. Zwei-Faktor-Verfahren sind heute Pflicht, und Nextcloud unterstützt TOTP, WebAuthn sowie Hardware-Token. Wer eine zentrale Benutzerverwaltung hat, bindet Nextcloud über LDAP oder SAML an eine bestehende Identitätslösung an. Praktisch ist das für die Nutzer, weil ein Passwortwechsel sofort überall greift – und für die Administration, weil beim Offboarding niemand vergisst, den Nextcloud-Account separat zu löschen. Der LDAP-Anbindung liegt das bekannte Muster zugrunde, dass Nextcloud nur die Gruppen kennt, die man explizit freigibt; unbedacht hochgezogene Gruppenzuordnungen sind ein häufiger Fehler bei der Einführung.

Zum anderen die Netzwerkebene. Nextcloud sollte nie direkt am offenen Internet hängen, ohne dass ein Reverse Proxy davorsteht. Dieser übernimmt TLS-Terminierung, HTTP/2 oder HTTP/3, Sicherheitsheader wie HSTS, CSP und X-Frame-Options. Wichtig ist die Konfiguration der trusted_proxies in der config.php, weil Nextcloud sonst die IP-Adressen des Proxys für Klienten hält und der Brute-Force-Schutz faktisch wirkungslos wird. Dieses Detail hat schon viele Administratoren einen Nachmittag gekostet.

Und zum dritten die Datenhaltung. Nextcloud bietet serverseitige Verschlüsselung, lässt sich aber auch auf einem bereits verschlüsselten Volume betreiben (LUKS auf der Ebene des Betriebssystems), was in vielen Fällen die einfachere und robustere Lösung ist. Wichtig: Verschlüsselung nachträglich einzuschalten, wenn die Instanz schon voller Daten ist, kann dauern und will sorgfältig geplant sein. Wer sie braucht, schaltet sie vor dem ersten Upload ein.

Collabora Online: LibreOffice im Browser

Nun zum interessanteren Teil. Nextcloud bringt von Haus aus keinen eigenen Editor für Office-Dokumente mit, und das ist auch eine bewusste Entscheidung. Stattdessen gibt es eine Reihe von Integrations-Apps, die unterschiedliche Backends anbinden. Das bekannteste und in Europa am weitesten verbreitete ist Collabora Online, dahinter steht die britische Firma Collabora Productivity, die maßgeblich auch die Entwicklung des LibreOffice-Desktop-Pakets vorantreibt.

Technisch ist Collabora Online ein Webservice, der die LibreOffice-Codebasis auf dem Server ausführt und die Darstellung als Web-Oberfläche ausliefert. Man schreibt also im Browser in LibreOffice – nicht in einer nachgebauten Tabellenkalkulation, sondern im echten Renderer. Das erklärt sowohl die Stärke als auch die Eigenheiten des Systems. Die Formatkompatibilität zu Microsoft-Formaten ist dadurch deutlich besser als bei mancher selbstgebauten Lösung, und gleichzeitig bedeutet es, dass der Server tatsächlich ein vollständiges Office-Paket im Speicher hält.

Die Anbindung an Nextcloud erfolgt über zwei Komponenten: die App „Nextcloud Office“ (früher „Richdocuments“) auf der Nextcloud-Seite und den Collabora-Online-Dienst auf der anderen. Beide sprechen über das WOPI-Protokoll miteinander, einer Spezifikation, die ursprünglich aus dem Umfeld von Microsoft Office Online stammt und heute als offener Standard in vielen Dokumentenbearbeitungsumgebungen verwendet wird. WOPI sieht vor, dass der Editor dem Speicherdienst mitteilt, welche Datei geöffnet wurde, und der Speicherdienst umgekehrt prüft, ob der Benutzer darauf zugreifen darf. Das ist der Grund, warum Nextcloud und Collabora sich gegenseitig erreichen können müssen – und warum eine Firewall, die nur eingehenden HTTPS-Verkehr zulässt, die Integration ins Stocken bringt.

Was in der Praxis viele überrascht: Collabora ist nicht einfach ein Dienst, den man einmal startet. Für jedes geöffnete Dokument startet der Server einen eigenen Prozess, ein sogenanntes Kit. Das hat den Vorteil, dass ein Absturz in einem Dokument nicht die gesamte Instanz mitnimmt. Es bedeutet aber auch, dass der Speicherbedarf linear mit der Zahl der gleichzeitig bearbeiteten Dokumente steigt. Größenordnungen von 200 bis 400 MB pro Sitzung sind realistisch, bei komplexen Tabellen auch mehr. Wer eine Instanz für fünfhundert Nutzer plant, sollte für Collabora einen eigenen Server einplanen – nicht weil die Software ineffizient wäre, sondern weil Office-Engine und Webserver unterschiedliche Anforderungsprofile haben.

Collabora betreiben: Reverse Proxy, WOPI und die lieben Zertifikate

Die Einrichtung von Collabora Online gilt als eine der Stellen, an denen selbst erfahrene Administratoren ins Schwitzen kommen. Das hat weniger mit der Komplexität der Software zu tun als mit der Tatsache, dass hier zwei Systeme miteinander reden müssen, die beide eine korrekte TLS-Konfiguration und Erreichbarkeit voraussetzen.

Ein typischer Aufbau sieht so aus: Nextcloud läuft unter cloud.example.org, Collabora unter office.example.org. Beide Namen zeigen auf denselben Reverse Proxy, der die Anfragen entsprechend weiterleitet. Collabora erwartet dabei, dass auch der Weg vom Editor zurück zur Nextcloud funktioniert, und verifiziert die WOPI-Hosts, von denen es Anfragen annimmt. In der Konfiguration des Collabora-Containers finden sich entsprechend Einträge wie aliasgroup1 und WOPI_HOST. Wer hier beim Namen mit oder ohne Port, mit oder ohne https:// schludert, bekommt keine hilfreiche Fehlermeldung, sondern eine leere Seite im Editor.

Ebenfalls ein Klassiker: die Einstellung allow_frame_src im Reverse Proxy. Der Editor wird als iframe in die Nextcloud-Oberfläche geladen, und wer Content-Security-Policy hart gesetzt hat, ohne die Collabora-Domain aufzunehmen, sieht nur ein weißes Rechteck. Weniger häufig, aber ebenso ärgerlich, sind Zeitüberschreitungen: Collabora beendet Sitzungen nach einer konfigurierbaren Leerlaufzeit. Zu kurze Werte führen dazu, dass Nutzer mitten im Schreiben eines Absatzes aus dem Dokument fliegen.

Für den Betrieb haben sich ein paar Faustregeln etabliert. Collabora gehört in einen eigenen Container oder eine eigene virtuelle Maschine, nicht auf denselben Host wie die Nextcloud, wenn diese mehr als eine Handvoll Nutzer bedienen soll. Die Ressourcen sollten großzügig bemessen werden – CPU-Kerne sind hier wichtiger als Taktfrequenz, weil die Office-Engine bei Bedarf parallelisiert. Und schließlich: Versionen von Collabora und Nextcloud sollten kompatibel zueinander gewählt werden. Es gibt eine Matrix, sie steht in der Dokumentation, und es lohnt sich, sie vor einem Upgrade kurz zu prüfen.

Alternativen und der Zustand des Ökosystems

Collabora Online ist nicht konkurrenzlos. Die bekannteste Alternative ist OnlyOffice Document Server, eine Suite, die optisch näher an Microsoft 365 heranrückt und in manchen Punkten – etwa beim „perfekten“ Layout von Word-Dokumenten – als noch näher am Original gilt. Die Integration in Nextcloud funktioniert über eine eigene App und ist technisch etwas einfacher, weil OnlyOffice als einzelner Dienst mit etwas vorhersehbarerem Ressourcenprofil läuft. Dafür ist die Codebasis stärker proprietär geprägt, was in manchen Beschaffungsumgebungen ein Kriterium ist.

Historisch interessant ist die Geschichte von LibreOffice Online. Collabora entwickelte den Web-Ableger gemeinsam mit der Document Foundation, und 2020 brachten Collabora und IONOS eine Variante auf den Markt, um einem drohenden proprietären Fork zuvorzukommen. In der Folge wurde das upstream Projekt LibreOffice Online eingestellt; die Weiterentwicklung findet seither im Wesentlichen bei Collabora statt. Für Nutzer ist das wenig dramatisch, es erklärt aber, warum man in älteren Anleitungen noch auf Begriffe wie „CODE“ und „LibreOffice Online“ trifft, die heute beide Collabora meinen.

Im Jahr 2025 hat Nextcloud gemeinsam mit Partnern einen Fork der OnlyOffice-Suite unter dem Namen Euro-Office angekündigt, mit dem Ziel, die Abhängigkeit von einzelnen Anbietern zu reduzieren und die Entwicklung stärker in europäische Governance-Strukturen einzubetten. Wie sich das Projekt entwickelt, ist derzeit offen. Interessant ist die Ankündigung allemal, denn sie zeigt, wie sehr die Frage „Wem gehört der Code?“ inzwischen auch die Bürosoftware-Diskussion erreicht hat.

Daneben gibt es kleinere, spezialisiertere Ansätze: Cryptpad für kollaboratives Schreiben ohne Serververtrauen, Etherpad für reines Textcollaboration, oder die Einbettung externer Editoren. Für die allermeisten produktiven Umgebungen bleibt es aber bei der Wahl zwischen Collabora und OnlyOffice – und die Entscheidung fällt selten technisch, sondern meist nach Kriterien wie Vorlagenkompatibilität, Lizenzmodell und der Frage, welches Look-and-Feel die Anwender akzeptieren.

Integration in bestehende Infrastrukturen

Nextcloud entfaltet seinen Nutzen erst, wenn sie sich in die bestehende Landschaft einfügt. Drei Integrationspunkte spielen dabei regelmäßig die Hauptrolle.

Erstens die Identitätsverwaltung. Wer ein Active Directory oder einen LDAP-Server betreibt, bindet Nextcloud daran an und ordnet die relevanten Gruppen zu. Sichtbar werden nur die Gruppen, die man explizit freischaltet – ein Sicherheitsmerkmal, das in der Praxis allerdings gerne zu Verwirrung führt, wenn ein Benutzer zwar angelegt, aber in keiner sichtbaren Gruppe ist. Für Single-Sign-on bieten sich SAML oder OIDC über Apps wie user_saml an, womit sich Anmeldung und Abmeldung zentral steuern lassen.

Zweitens die Dateiablage. Externe Speicher wie SMB-Freigaben, WebDAV oder S3-Buckets lassen sich einbinden, und mit der Groupfolders-App kommen echte Abteilungsverzeichnisse hinzu, die nicht an einen einzelnen Benutzer gebunden sind. In Umgebungen mit bestehenden Fileservern ist das häufig der pragmatische Weg: Man lässt die Altdaten liegen und legt nur neue Projekte in der Nextcloud an, statt eine monatelange Migration anzugehen.

Drittens die Groupware. Kalender und Kontakte laufen über CalDAV und CardDAV, was bedeutet, dass sich Thunderbird, der Apple-Kalender und mobile Clients ohne Zusatzsoftware anbinden lassen. Nextcloud Talk ergänzt das um Chats und Videokonferenzen, wobei für größere Installationen der High-Performance-Backend-Signalserver empfohlen wird. Ohne ihn funktionieren Gruppengespräche nur eingeschränkt, weil jede Verbindung über den PHP-Backend läuft – ein Konstrukt, das bei mehr als einer Handvoll Teilnehmern schnell an seine Grenzen kommt.

Backup, Updates und der Alltag

Wer eine Nextcloud betreibt, betreibt auch ein Stück Infrastruktur, das gepflegt werden will. Die unangenehmste Aufgabe ist dabei ausgerechnet die wichtigste: das Backup. Es reicht nicht, das Datenverzeichnis zu kopieren. Man braucht einen konsistenten Stand von Datenverzeichnis, Datenbank und Konfiguration, und der entsteht am besten, indem man die Instanz in den Wartungsmodus versetzt, dann alle drei Teile sichert und anschließend wieder freigibt. Wer auf Storage-Ebene mit Snapshots arbeitet – ZFS, Ceph, ein SAN – kann sich das ersparen, sollte dann aber ebenfalls darauf achten, dass Datenbank und Dateien aus demselben konsistenten Zeitpunkt stammen.

Was viele unterschätzen: Ein Backup ist erst dann ein Backup, wenn man es einmal vollständig zurückgespielt hat. Es gibt wenig Peinlicheres als den Moment, in dem man im Ernstfall feststellt, dass die Sicherung syntaktisch korrekt ist, aber die Datenbank nicht mehr zur Datenversion passt. Der Aufwand für einen jährlichen Restore-Test auf einer Testmaschine ist gering im Vergleich zum Risiko.

Bei den Updates gilt eine Regel, die man nicht umgehen kann: Nextcloud unterstützt keine Sprünge über mehrere Major-Versionen. Wer von Version 28 kommt, muss über 29 und 30, bevor 31 installiert werden kann. Die Wartungsfenster sind deshalb kleiner, aber häufiger. Bei Collabora ist die Lage entspannter, dort sind Sprünge meist unproblematisch, solange die Kompatibilität zur Nextcloud-Version stimmt.

Und dann ist da noch das, was man den sozialen Teil des Betriebs nennen könnte. Eine Nextcloud, die einfach nur bereitgestellt wird, wird oft nicht angenommen. Ein paar Schulungseinheiten, eine klare Ansage, wo Dateien künftig zu liegen haben, und vor allem ein sichtbares Engagement der Führungsebene wirken Wunder. Es klingt banal, ist aber in der Praxis der Unterschied zwischen einer Instanz mit zwanzig aktiven Nutzern und einer mit hundert.

Datenschutz, Betreiberpflichten und die Frage der Verantwortung

Der häufigste Grund für den Umstieg auf Nextcloud ist der Wunsch nach mehr Kontrolle über die eigenen Daten, oft getrieben durch datenschutzrechtliche Anforderungen. Dabei wird gerne übersehen, dass der Betrieb einer eigenen Plattform die Verantwortung nicht auflöst, sondern verschiebt. Aus einem Auftragsverarbeitungsverhältnis mit einem Cloud-Anbieter wird ein Eigenbetrieb – und die Pflichten aus der DSGVO bleiben bestehen, nur trägt man sie jetzt selbst.

Das bedeutet konkret: technische und organisatorische Maßnahmen müssen dokumentiert werden. Zugriffe müssen nachvollziehbar sein, was Nextcloud mit der Audit-Log-App und dem Admin-Audit-Log leistet. Löschfristen müssen umgesetzt werden, was mit der App für automatisierte Aufbewahrungsfristen möglich ist. Bei Behörden kommt die Frage der Auftragsverarbeitung bei Managed-Hosting-Anbietern hinzu, die sich vertraglich sauber klären lässt, aber eben geklärt werden muss.

Interessant ist in diesem Zusammenhang, wie sehr sich die Argumentation verschoben hat. Vor fünf Jahren war der Haupttreiber der Wunsch, Daten nicht in US-Rechenzentren zu halten. Heute geht es stärker um Souveränität im weiteren Sinne: Wer kann Updates einspielen, wer kann Funktionen abschalten, wer entscheidet über das Geschäftsmodell? Die Enshittification-Debatte, die inzwischen auch die Bürosoftware erreicht hat, ist ein Ausdruck davon. Open-Source-Plattformen sind keine Garantie gegen schlechte Entscheidungen, aber sie sind eine Versicherung gegen die Unmöglichkeit, sie zu korrigieren.

KI, Föderation und die nächsten Baustellen

Wer heute über Collaboration-Plattformen schreibt, kommt an einem Thema nicht vorbei: der künstlichen Intelligenz. Nextcloud hat früh eine Strategie formuliert, die auf lokale oder selbst gehostete Modelle setzt, statt Anfragen an externe Anbieter weiterzuleiten. Der Assistant lässt sich an Ollama, LocalAI oder vergleichbare Endpunkte anbinden. Sinnvoll ist das vor allem dort, wo Inhalte das Haus nicht verlassen dürfen. Der Preis ist, dass man sich die Modelle selbst um die Ohren schlägt – Hardware, Wartung, Aktualisierungen. Ein mitlaufender Inferenzserver ist kein Selbstläufer.

Spannend ist auch die Föderation. Nextcloud unterstützt das Open Cloud Mesh, mit dem sich Instanzen unterschiedlicher Organisationen gegenseitig Dateien und Kalender freigeben können, ohne dass eine zentrale Stelle dazwischensteht. In der Praxis ist das bislang eine Nischenfunktion, technisch aber eine der interessantesten Eigenschaften des Systems, weil sie ein Gegenmodell zum Plattformkapitalismus beschreibt – mehrere kleine Instanzen, die miteinander reden, statt einer zentralen Wolke.

Offen bleiben die bekannten Baustellen. Die PHP-Basis ist für manche Anwendungsfälle ein Limit, das sich nicht wegdiskutieren lässt. Die Performance bei sehr großen Installationen mit Millionen von Dateien erfordert Erfahrung und gelegentlich Handarbeit an der Datenbank. Und die Update-Disziplin, die das System verlangt, ist in kleinen IT-Abteilungen nicht immer leicht durchzuhalten.

Fazit

Nextcloud und Collabora Online sind zusammen eine der überzeugendsten Antworten auf die Frage, wie man Dokumente, Dateien und Kommunikation selbst betreiben kann, ohne auf Komfort zu verzichten. Die Kombination ist ausgereift, sie ist in Behörden und Unternehmen angekommen, und sie funktioniert auch jenseits von Pilotprojekten. Aber sie verlangt etwas zurück: Aufmerksamkeit, Betriebsdisziplin und die Bereitschaft, sich mit der eigenen Architektur auseinanderzusetzen. Wer diese Bereitschaft mitbringt, bekommt eine Plattform, die sich über Jahre weiterentwickeln lässt, ohne dass ein Anbieter einem die Regeln ändert. Wer sie nicht mitbringt, sollte besser zu einer verwalteten Lösung greifen – oder gleich bei einem der großen Anbieter bleiben, zumindest ehrlicherweise. Denn eine schlecht betriebene selbstgehostete Cloud ist am Ende nichts anderes als eine langsamere Variante der Cloud, die man eigentlich verlassen wollte.

Nextcloud und Collabora Online wenn die eigene Cloud ernst wird