Nextcloud ist mehr als ein Dateiserver und genau da beginnen die Probleme

Nextcloud ist längst kein Dateiserver mehr – und genau da fangen die Probleme an

Es gibt diese Sitzungen, in denen ein Administrator sagt: „Wir haben doch Nextcloud, wozu brauchen wir noch irgendwas anderes?“ Und dann kommt die Vertriebsleitung um die Ecke und will Kontakte, Angebote, Wiedervorlagen, eine Pipeline. Und plötzlich steht man vor der Frage, ob man die private Cloud zur eierlegenden Wollmilchsau ausbaut oder ob man daneben eine zweite, spezialisierte Software stellt. Genau an dieser Bruchstelle taucht in deutschen Rechenzentren immer wieder ein Name auf, den man in europäischen Open-Source-Kreisen eher selten hört: Really Simple Systems. Ein britisches CRM aus Hampshire, seit 2002 am Markt, klassisches SaaS, kein Quellcode zum Anfassen. Und irgendwie passt das so gar nicht zu einer Nextcloud-Installation, die man sich gerade mühsam aus der Abhängigkeit von US-Hyperscalern herausgebaut hat.

Dieser Text versucht, beide Welten zusammenzudenken. Nicht als Werbebroschüre, nicht als Abgesang, sondern als ehrliche Bestandsaufnahme für Menschen, die eine Entscheidung treffen müssen und dabei weder Zeit für Marketing-Prosa noch für religiöse Debatten haben.

Was Nextcloud heute tatsächlich ist

Wer die Plattform noch als „Dropbox-Klon, den man selbst hostet“ abtut, hat die vergangenen fünf Jahre verschlafen. Nextcloud hat sich schrittweise von einer Filesharing-Lösung zu einem Collaboration-Stack entwickelt, der im Kern aus mehreren Schichten besteht: dem eigentlichen Server (PHP, dazu eine Datenbank – MySQL/MariaDB oder PostgreSQL, im Unternehmensumfeld praktisch immer Letzteres), einem Dateispeicher, den man wahlweise lokal, auf NFS, Ceph oder direkt in einem S3-kompatiblen Object Store betreiben kann, und einer wachsenden Zahl von Anwendungen, die auf demselben Fundament sitzen.

Zur Grundausstattung gehören heute Groupware (Kalender, Kontakte, Mail über IMAP), Nextcloud Talk für Videokonferenzen und Chats, Nextcloud Office als Integration von Collabora Online für kollaboratives Bearbeiten von Textdokumenten, Tabellen und Präsentationen, die Pinnwand-App Deck für Kanban-Projekte, Forms für Umfragen und Formulare, Collectives als Wissensdatenbank für Teams sowie Tables, mit dem sich strukturierte Datenbanken im Browser bauen lassen. Dazu kommt eine Reihe von kleineren Werkzeugen: Notes, Tasks, Whiteboard, Photos mit Gesichtserkennung durch die App Recognize.

Interessant ist dabei weniger die schiere Menge als die Art, wie diese Bausteine miteinander verzahnt sind. Eine Datei ist nicht nur eine Datei, sie kann Kontext haben – ein Kommentar, ein Tag, eine Freigabe an eine Gruppe, eine automatische Weiterverarbeitung über Flow. Wenn jemand in Talk eine Bildschirmfreigabe startet, ist das derselbe Rechtekosmos wie das Filesharing. Das klingt banal, ist aber der eigentliche Grund, warum sich Nextcloud in vielen Häusern gegen Microsoft 365 durchsetzt: Es gibt genau eine Identität, ein Rollenmodell, eine Audit-Quelle. Kein Wildwuchs aus drei Mandanten und zwei Tenant-IDs.

Versionen, Kanäle und der Enterprise-Zweig

Seit einigen Jahren unterscheidet der Hersteller nicht mehr zwischen einer Community- und einer Enterprise-Edition im Code, sondern vermarktet den Funktionsstand als „Hub“ und verkauft Support-Subskriptionen für Unternehmen. Die Community-Version ist funktional nahezu identisch, was die Pflege angeht unterscheiden sich die Modelle aber deutlich: Enterprise-Kunden bekommen längere Wartungsfenster, zertifizierte Builds, frühen Zugriff auf Sicherheitspatches und eine rechtliche Zusicherung, dass bestimmte Fehler in definierter Zeit behoben werden.

Wer Nextcloud produktiv für mehrere hundert Beschäftigte betreibt, sollte sich über diesen Punkt keine Illusionen machen. Der Betrieb ist ohne Frage machbar – aber er ist Arbeit. Upgrades zwischen Major-Versionen sind nicht trivial, Apps brechen gelegentlich, und die Versuchung, produktiv einfach auf dem Stable-Kanal „mitzuschwimmen“, rächt sich irgendwann in Form eines ungeplanten Wartungsabends.

Betrieb: Wo die meisten Installationen an ihre Grenzen kommen

Eine Nextcloud für fünf Personen auf einem Root-Server bei einem deutschen Hoster aufzusetzen, dauert einen Nachmittag. Eine Instanz für 2.000 Nutzer mit mehreren Terabyte Daten und mobilen Clients in drei Zeitzonen ist ein Projekt. Dazwischen liegt der Graubereich, in dem die meisten Organisationen landen – und in dem die entscheidenden Fehler gemacht werden.

Die typischen Stolpersteine sind bekannt, werden aber erstaunlich oft ignoriert. PHP-FPM braucht ausreichend Worker und ein sauber dimensioniertes pm.max_children, sonst staut sich der Verkehr bei jedem größeren Sync-Vorgang. Redis als Memcache und als File-Locking-Backend ist Pflicht, ebenso APCu für den lokalen Cache. Die Datenbank sollte auf einem eigenen Host laufen, wenn es ernst wird, und braucht Indexpflege – die occ db:add-missing-indices-Routine der Administrationsoberfläche ist kein Vorschlag, sondern eine Hausaufgabe.

Viel wichtiger als jedes Tuning ist jedoch die Speicherarchitektur. Sobald die Datenmenge in den zweistelligen Terabyte-Bereich wächst, wird klassischer Block-Speicher zum Kostentreiber und zum Skalierungsproblem. S3-kompatibler Object Storage als primärer Speicher ist seit Version 18 möglich und inzwischen ausgereift; für kleinere Häuser genügt ein MinIO-Cluster, größere setzen auf Ceph mit RadosGW. Der Vorteil: Replikation, Erweiterung und Backup laufen auf der Speicherschicht, nicht mehr im Anwendungscode. Der Nachteil: Man braucht jemanden, der Ceph versteht. Und das ist nicht automatisch dieselbe Person, die Nextcloud administriert.

Externe Speicher und die Illusion der einen Wahrheit

Viele Häuser binden bestehende SMB-Freigaben oder SharePoint-Bibliotheken als externe Speicher an. Technisch funktioniert das, konzeptionell führt es in eine Falle. Sobald derselbe Inhalt an zwei Stellen mit unterschiedlichen Rechtekonzepten liegt, gewinnt der Pfad mit der schwächeren Kontrolle. Wer externen Speicher einsetzt, sollte sich ehrlich fragen, ob er ihn wegen der Migration oder wegen der Dauerlösung betreibt. Im ersten Fall gehört hinter das Projekt ein Enddatum, im zweiten sollte man über eine Umverteilung der Rechte nachdenken.

Sicherheit, Verschlüsselung und was von beidem wirklich schützt

Nextcloud bringt eine ganze Reihe von Sicherheitsmechanismen mit: Zwei-Faktor-Authentifizierung, App-Passwörter für Clients, Brute-Force-Schutz mit IP-Sperren, Verschlüsselung von Verbindungen über TLS, Server-seitige Verschlüsselung (SSE) des Speichers und Ende-zu-Ende-Verschlüsselung (E2EE) für ausgewählte Ordner.

Der entscheidende Punkt wird in Diskussionen oft verwechselt. Server-seitige Verschlüsselung schützt gegen gestohlene Festplatten, nicht gegen einen Administrator mit Zugriff auf die Instanz oder gegen einen Angreifer, der die Anwendung selbst übernommen hat. Nur die Ende-zu-Ende-Verschlüsselung nimmt dem Betreiber die Möglichkeit, Inhalte zu lesen – und kostet dafür Funktionen: Suche, serverseitige Vorschauen, Kollaboration in Echtzeit, Versionshistorie. Wer E2EE flächig ausrollt, verliert einen Gutteil dessen, wofür die Plattform eigentlich angeschafft wurde.

In der Praxis fährt man meist zweigleisig: E2EE für jene Ordner, in denen wirklich sensible Personenbezüge liegen – Personalakten, Mandantenkorrespondenz, Vorstandsunterlagen –, und normaler Betrieb für alles andere. Diese Trennung muss man organisatorisch durchhalten, sonst wandert genau die kritische Datei wieder in den unverschlüsselten Bereich, weil die Kollegin dort schneller suchen kann.

Für regulierte Umgebungen relevant ist der Nachweis, dass man es ernst meint. Nextcloud selbst lässt sich nicht „zertifizieren“ wie ein Rechenzentrum, aber die Betriebsumgebung kann es. ISO 27001, C5-Testate deutscher Cloud-Anbieter, BSI-Grundschutz-Bausteine – all das ist kombinierbar, wenn die Instanz sauber dokumentiert und überwacht wird. Logging gehört dazu, und zwar zentralisiert: Wer bei einer Anfrage der Aufsichtsbehörde erst anfangen muss, Logfiles von sechs Applikationsservern zusammenzusuchen, hat schon verloren.

Die Integrationsfrage: Wo Nextcloud endet und ein CRM beginnt

Und jetzt kommt der Punkt, an dem es interessant wird. Nextcloud ist eine hervorragende Plattform für Dateien, Kommunikation und Zusammenarbeit. Es ist kein Kundenbeziehungsmanagementsystem. Wer das versucht, biegt Tabellen zu Kontaktdatenbanken um und baut sich mit Deck eine Pipeline, die beim dritten Vertriebsmitarbeiter zusammenbricht.

Genau hier kommen spezialisierte Systeme ins Spiel. In Deutschland sind das häufig HubSpot, Salesforce, Pipedrive, Zoho oder – wenn es europäischer und günstiger sein soll – Really Simple Systems. Letzteres ist ein Name, der in hiesigen Ausschreibungen selten auftaucht und doch regelmäßig im Gespräch ist, wenn mittelständische Vertriebsteams eine schlanke Lösung suchen, die nicht sofort ein halbes Jahresbudget verschlingt.

Really Simple Systems: ein Kurzporträt

Das Unternehmen sitzt in Petersfield, Hampshire, und wurde 2002 von John Paterson gegründet. Die Positionierung ist klar umrissen: CRM für kleine und mittlere Unternehmen, mehrsprachig, browserbasiert, mit E-Mail-Integration, Marketing-Automatisierung, Ticketverwaltung und Vertriebs-Pipelines. Die Preisstaffelung richtet sich nach Nutzern und Funktionsumfang, grob zwischen zehn und vierzig Pfund pro Nutzer und Monat. Für ein Team von zwanzig Personen ist das eine Größenordnung, die man ohne Vorstandsentscheid beschließen kann.

Funktional deckt das System ab, was der klassische B2B-Vertrieb braucht: Firmen und Personen, Opportunities mit Phasen und Wahrscheinlichkeiten, Aufgaben und Wiedervorlagen, Angebotsversand, Kampagnen für E-Mail-Marketing, Fallbearbeitung im Support. Die Oberfläche ist bewusst schlicht gehalten – nüchterner als bei den amerikanischen Wettbewerbern, aber auch schneller zu erlernen. Die Datenbank sitzt in Großbritannien, eine EU-Instanz gibt es nach meinem Kenntnisstand nicht.

Die API ist REST-artig, liefert JSON und lässt sich mit einem API-Schlüssel ansteuern. Es existieren fertige Konnektoren für Zapier, Make und ähnliche Werkzeuge. Das ist für Integrationsprojekte wichtig, weil es die Einstiegshürde senkt: Man muss nicht zwingend eine eigene Middleware in Java schreiben.

Wie man Nextcloud und Really Simple Systems sinnvoll verbindet

Eine offizielle App für die Verbindung der beiden Welten gibt es nicht, jedenfalls nicht im Nextcloud App Store. Was es gibt, sind mehrere gangbare Wege, die sich je nach Aufwand, Wartbarkeit und Sicherheitsanspruch unterscheiden.

Weg eins: Dateien aus dem CRM in die Cloud spiegeln

Der häufigste Anwendungsfall ist banal: Ein Vertriebsmitarbeiter hängt im CRM ein Angebot an eine Opportunity. Später möchte er dieselbe Datei strukturiert in der Nextcloud ablegen, weil dort die Ordnerstruktur, die Freigaben und die Versionierung nach Unternehmensregeln liegen. Manuell ist das ein Klick zu viel, automatisiert ein Job von wenigen Zeilen.

Der technische Zugriff auf Nextcloud erfolgt über WebDAV. Der Endpunkt lautet üblicherweise https://cloud.example.com/remote.php/dav/files/BENUTZERNAME/Pfad/Zur/Datei. Authentifiziert wird mit einem App-Passwort, nicht mit dem persönlichen Kennwort – das ist ein Punkt, an dem viele Integrationen aus Unkenntnis scheitern. App-Passwörter lassen sich in den persönlichen Sicherheitseinstellungen erzeugen und einzeln widerrufen, was die Rotation enorm vereinfacht.

Auf der CRM-Seite liefert die API zu einer Opportunity die Dateianhänge. Eine kleine Middleware – in vielen Häusern ist das inzwischen n8n, gelegentlich Make, manchmal ein eigenes Python-Skript – holt die Datei ab und schiebt sie per PUT in die Cloud. Umgekehrt kann ein Webhook aus der Cloud, ausgelöst durch Nextcloud Flow bei neu hochgeladenen Dateien in einem bestimmten Ordner, einen Datensatz im CRM anlegen oder ergänzen.

Weg zwei: Kontaktdaten synchron halten

Hier wird es unangenehmer. CRM und Groupware haben unterschiedliche Vorstellungen davon, was ein Kontakt ist. Das CRM denkt in Firmen, Personen, Rollen, Beziehungen, Lebenszyklen. Die Groupware denkt in Adressbüchern und vCards. Ein bidirektionaler Abgleich klingt verlockend, ist aber eine der zuverlässigsten Arten, sich Datenmüll einzuhandeln.

In der Praxis hat sich ein einseitiger Fluss bewährt: Das CRM ist die führende Quelle, Nextcloud bekommt eine lesbare Kopie. So lassen sich Kontakte auch mobil und über CalDAV/CardDAV nutzen, ohne dass ein Anwender versehentlich im Smartphone-Telefonbuch die Firma eines Kunden löscht und damit einen Datensatz im Vertriebssystem beschädigt. Wer den umgekehrten Weg braucht, sollte mit Änderungszeitstempeln arbeiten und klar definierte Felder markieren, die überhaupt synchronisiert werden dürfen.

Weg drei: Die eigene Anwendung auf der Plattform

Seit der Version 28 bietet Nextcloud eine Schnittstelle namens AppAPI, mit der sich sogenannte ExApps betreiben lassen – Anwendungen, die nicht in PHP geschrieben sind, sondern als Container daneben laufen und über eine definierte Brücke mit der Instanz kommunizieren. Damit lässt sich ein CRM-Konnektor in Python oder Go bauen, der auf Augenhöhe mit der Plattform arbeitet: eigene Navigationseinträge, eigene Berechtigungen, Zugriff auf das Rollenmodell.

Das ist der eleganteste Weg, aber auch der aufwendigste. Er lohnt sich, wenn die Integration dauerhaft Bestand haben soll und mehrere Abteilungen davon abhängen. Für ein einzelnes Skript, das einmal pro Stunde Dateien kopiert, wäre das mit Kanonen auf Spatzen geschossen.

Weg vier: Kein Weg – die bewusste Trennung

Manchmal ist die ehrlichste Antwort: gar nicht integrieren. Wenn der Vertrieb sein CRM im Browser nutzt und die Dokumente im CRM selbst liegen, ist das für viele Organisationen völlig ausreichend. Jede zusätzliche Schnittstelle erzeugt Betriebslast, Sicherheitsfläche und Fehlerquellen. Eine Integration, die nur existiert, weil sie technisch machbar ist, ist keine Integration, sondern ein Wartungsvertrag mit sich selbst.

Der Datenschutz-Widerspruch, den man aushalten muss

Hier wird es ungemütlich, und zwar für beide Seiten. Wer Nextcloud selbst hostet, tut das in den meisten Fällen aus einem Grund: Datenhoheit. Die Überlegung lautet, dass personenbezogene Daten das eigene Rechenzentrum nicht verlassen sollen, dass kein Dritter Zugriff hat, dass Auftragsverarbeitung nach Artikel 28 DSGVO entweder entfällt oder auf einen vertrauenswürdigen Dienstleister beschränkt bleibt.

Ein SaaS-CRM aus dem Vereinigten Königreich durchkreuzt dieses Konzept. Es gibt eine Angemessenheitsentscheidung der EU-Kommission für das Vereinigte Königreich, aber sie ist befristet und wurde in der Vergangenheit verlängert, nicht dauerhaft erteilt. Wer heute eine mehrjährige CRM-Einführung plant, sollte diesen Punkt in der Risikobewertung ausdrücklich adressieren und nicht mit dem Hinweis „das passt schon“ abtun.

Konkret heißt das: Ein Auftragsverarbeitungsvertrag muss existieren. Ein Transfer Impact Assessment sollte dokumentiert sein, auch wenn viele Unternehmen es scheuen wie der Teufel das Weihwasser. Und man sollte wissen, welche Daten überhaupt hinüberfließen. Ein CRM, das nur Firmennamen und geschäftliche Telefonnummern enthält, ist datenschutzrechtlich erheblich harmloser als eines, in dem Support-Tickets mit Kundendaten, Gesundheitsangaben oder Beschwerdekorrespondenz liegen. Die Entscheidung ist also nicht binär, sondern abgestuft.

Nicht zuletzt gibt es einen zweiten Widerspruch, der selten offen angesprochen wird: Wenn Nextcloud die zentrale Plattform sein soll, aber die Vertriebsdaten in einer ausländischen SaaS-Umgebung liegen, entstehen zwei Wahrheiten. Der Vertrieb sieht in seinem Werkzeug etwas anderes als der Rest des Unternehmens in der Cloud. Über kurz oder lang führt das zu Diskussionen über Reports, die niemand mehr auflösen kann, weil die Zahlen in beiden Systemen unterschiedlich sind.

Alternativen, die den Widerspruch vermeiden

Wer konsequent bleiben will, findet im Open-Source-Umfeld mehrere CRM-Systeme, die sich selbst betreiben lassen und sich damit in dasselbe Betriebsmodell wie Nextcloud einfügen.

• EspoCRM – schlank, modern, PHP-basiert, mit einer sauberen REST-API. Für Vertriebsteams bis etwa fünfzig Personen eine sehr vernünftige Wahl. Der Funktionsumfang ist geringer als bei den großen Anbietern, dafür ist die Lernkurve flach und die Installation unkompliziert.
• SuiteCRM – der Fork von SugarCRM, funktional mächtig, aber technisch in die Jahre gekommen. Wer es betreibt, braucht Geduld und jemanden, der sich mit der Codebasis auskennt. Dafür ist die Anpassungstiefe enorm.
• Vtiger Open Source – ähnliche Liga wie SuiteCRM, größere Community in Indien und Südostasien, deutschsprachige Dokumentation eher dünn.
• Odoo – kein reines CRM, sondern eine ganze ERP-Suite. Wer ohnehin Buchhaltung, Lager und Personal planen muss, bekommt hier ein sehr integriertes Paket. Als reines CRM ist Odoo allerdings überdimensioniert und in der Community-Version funktional beschnitten.
• Twenty – ein jüngeres Projekt, das sich explizit als offene Alternative zu Salesforce und HubSpot positioniert. Technisch modern, aber noch nicht in jeder Hinsicht produktionsreif. Ein Blick lohnt sich, ein Umstieg auf breiter Front wäre derzeit ein Wagnis.

All diese Systeme haben eines gemeinsam: Sie brauchen jemanden, der sie betreibt. Updates, Backups, Sicherheitspatches, Skalierung – der Betriebsaufwand ist nicht null, nur weil die Lizenz null kostet. Das ist die eigentliche Rechnung, die man aufmachen muss: Ist die eigene IT in der Lage, ein weiteres System zu stemmen, oder überfordert das die vorhandene Mannschaft? Die Antwort ist nicht immer die ideologische.

Was ein sinnvoller Betriebsrahmen aussieht

Wer beide Welten kombinieren möchte, kommt um ein paar Grundsatzentscheidungen nicht herum.

Erstens: Klären, wo die führende Datenquelle liegt. Für Kunden- und Vertriebsdaten ist das in aller Regel das CRM. Für Dokumente, Freigaben und Zusammenarbeit ist es die Cloud. Doppelte Führerschaft in denselben Feldern führt zwangsläufig zu Konflikten.

Zweitens: Die Integration so einfach wie möglich halten. Ein Cronjob, der stündlich Dateien kopiert, ist robuster als eine ereignisgesteuerte Kette mit sechs beteiligten Diensten. Fehlerbehandlung bleibt überschaubar, und die Fehlersuche ist ein Blick in ein Logfile statt in einen verteilten Trace.

Drittens: Zugangsdaten sauber trennen. Eigene technische Nutzer im CRM und in der Cloud, jeweils mit minimalen Rechten, keine geteilten Kennwörter, Rotation mindestens jährlich. Das klingt nach Selbstverständlichkeit, ist es aber erstaunlich oft nicht. Wenn ein Integrationskonto gleichzeitig Administratorrechte auf allen Cloud-Ordnern hat, ist das eine Hintertür mit Vorhängeschloss dran.

Viertens: Monitoring von Anfang an. Wenn die nächtliche Synchronisation seit drei Wochen stillsteht, merkt das niemand, bis jemand eine Datei sucht, die „eigentlich da sein müsste“. Ein einfacher Heartbeat, der nach dem Lauf eine Zeile in ein Monitoring-System schreibt, reicht oft aus.

Fünftens: Dokumentieren, und zwar so, dass es jemand versteht, der nicht am Projekt beteiligt war. Die Person, die die Integration gebaut hat, ist in zwei Jahren vielleicht woanders. Ein Blatt mit Datenfluss, Zugangsdaten-Referenzen und Wiederanlaufschritten ist wertvoller als jede Architekturzeichnung in einem Wiki, das niemand pflegt.

Ein Blick nach vorn

Die Entwicklung in beiden Lagern läuft in unterschiedliche Richtungen. Nextcloud baut seine Plattform weiter aus – AppAPI, Nextcloud Assistant mit lokaler Sprachmodell-Anbindung, Context Chat, die Fähigkeit, KI-Funktionen auf eigener Hardware zu betreiben statt in einer fremden Cloud. Das ist konsequent gedacht: Wer Datenhoheit will, kann sie nicht an der Stelle aufgeben, wo die Auswertung beginnt.

Really Simple Systems wiederum optimiert sein klassisches SaaS-Modell, mit Blick auf Usability, Automatisierung und Integration in Werkzeuge wie Zapier. Die Frage, ob es jemals eine EU-Instanz geben wird, kann man aus der Ferne nicht beantworten. Strategisch wäre sie überfällig, denn der europäische Mittelstand ist genau die Zielgruppe, für die das Produkt gebaut ist – und diese Zielgruppe fragt inzwischen deutlich genauer nach, wohin die Daten gehen.

Für Administratoren und Entscheider heißt das: Es gibt keine allgemeingültige Antwort. Für manche Häuser ist die Kombination aus selbstgehosteter Nextcloud und einem schlanken britischen CRM völlig in Ordnung, solange die Datenklassifizierung stimmt und die Verträge sauber sind. Für andere ist schon der Gedanke daran inakzeptabel. Und für eine dritte Gruppe ist der Betrieb eines eigenen CRM-Systems schlicht nicht zu stemmen, ganz egal wie sehr man die Idee mag.

Interessant ist dabei weniger, welche Technik am Ende gewinnt, sondern wie sich die Begründungen verschieben. Vor fünf Jahren lautete das Argument für Self-Hosting meist „Kosten“. Heute lautet es „Kontrolle“. Und morgen wird es vielleicht lauten: „Wir müssen wissen, welches Modell mit unseren Daten trainiert wurde.“ Ob Nextcloud und ein britisches CRM dann noch als Gegensätze gelten, hängt davon ab, wie beide Seiten auf diese Frage antworten. Der Rest ist Betrieb.