Nextcloud und Dolibarr: Wenn Dateiablage und Warenwirtschaft dieselbe Datenhoheit teilen

Es fängt meist harmlos an. Ein Betrieb sucht eine Alternative zu Dropbox, weil die Belegschaft die Ablage im Ausland nicht mehr mitmachen will. Zwei Quartale später kommt der Wunsch nach einer Rechnungssoftware dazu, bei der nicht pro Sitzplatz abgerechnet wird. Und irgendwann stehen dann zwei Open-Source-Anwendungen auf demselben Server – Nextcloud und Dolibarr – und die Frage ist nicht mehr, ob das funktioniert, sondern wie viel man den beiden zumuten darf.

Beide Projekte haben auf den ersten Blick wenig gemeinsam. Nextcloud ist Groupware, Dateiablage, Kollaborationsplattform. Dolibarr ist ERP und CRM, also kaufmännische Software für Angebote, Aufträge, Rechnungen, Lager, Projekte und Personal. Der eine versteht sich als Arbeitsumgebung, der andere als Buchhaltungsmaschine. Und doch treffen sie sich an einer Stelle, die in der Praxis erstaunlich wichtig ist: bei den Dokumenten. Denn eine Rechnung, ein Lieferschein oder ein Vertrag ist immer beides – ein kaufmännischer Vorgang und eine Datei.

Nextcloud: mehr als ein Dateiaustausch

Wer Nextcloud zum ersten Mal installiert, unterschätzt häufig, wie weit das Projekt inzwischen gewachsen ist. Der Kern ist nach wie vor die Dateiverwaltung: Synchronisation über Desktop-Clients, Weboberfläche, mobile Apps, Teilen über Links, öffentliche Upload-Ordner, Versionshistorie, Papierkorb. Darüber liegt aber ein ganzer Baukasten. Kalender und Kontakte nach CalDAV beziehungsweise CardDAV, eine Weboberfläche für E-Mail, Videokonferenzen mit Talk, Aufgaben- und Kanban-Boards mit Deck, Formulare, Tabellen, und mit Collabora Online oder OnlyOffice ein vollwertiger Office-Editor, der im Browser läuft und die Dateien trotzdem im eigenen Speicher belässt.

Das Entscheidende daran: Nextcloud wird nicht fertig ausgeliefert, sondern zusammengesetzt. Der App-Store ist Fluch und Segen zugleich. Es gibt hervorragend gepflegte Apps, aber eben auch solche, die seit zwei Jahren keine Aktualisierung mehr gesehen haben. Wer eine Instanz für einen Betrieb verantwortet, sollte sich angewöhnen, vor jeder Installation zu prüfen, wer die App pflegt, wie häufig Releases kommen und ob sie überhaupt für die eigene Version freigegeben ist. Der Hinweis auf inkompatible Apps ist im Adminbereich kein Ziertext.

Die Architektur hinter der Oberfläche

Nextcloud ist klassisch LAMP beziehungsweise LEMP: PHP-Anwendung, Webserver, relationale Datenbank, dazu ein Dateisystem oder Objektspeicher. Als Datenbanken kommen MariaDB, MySQL oder PostgreSQL in Frage, SQLite ist für den Dauerbetrieb mit mehr als zwei Nutzern keine Option – das ist eine der wenigen Aussagen, bei denen es in der Community praktisch keine Diskussion gibt. Als Webserver haben sich nginx und Apache etabliert, wobei nginx in Kombination mit PHP-FPM die schlankere und wartungsärmere Variante ist.

Zwei Komponenten sollte man von Anfang an mitdenken, weil sie später schmerzhaft nachzurüsten sind: Redis als verteilter Cache und als Sperrmechanismus für Dateizugriffe, sowie APCu für den lokalen Cache. Ohne Redis kommt es bei mehreren gleichzeitigen Schreibzugriffen auf dieselbe Datei früher oder später zu Konflikten, die sich als unerklärliche Synchronisationsfehler äußern. Bewährt hat sich folgende Aufteilung: APCu als Memcache für den lokalen Prozessspeicher, Redis für Sperren (transactional locking) und für die dateibezogene Zwischenspeicherung. Wer das sauber konfiguriert, merkt den Unterschied bereits bei zwanzig aktiven Nutzern deutlich.

Für Einsteiger gibt es fertige Wege: das All-in-One-Container-Image, das die wesentlichen Komponenten mitbringt und über eine Verwaltungsoberfläche steuert, oder klassische Distributionen wie NextcloudPi. Man kann darüber streiten, wie sinnvoll das Snap-Paket ist – in produktiven Umgebungen mit eigenem Datenverzeichnis auf separatem Volume hat es sich bei vielen Admins nicht durchgesetzt. Der Grund ist wenig überraschend: Snap kapselt zu viel weg, und genau diese Transparenz braucht man im Fehlerfall.

Was im Betrieb wirklich passiert

Die tägliche Arbeit mit Nextcloud spielt sich zu einem großen Teil auf der Kommandozeile ab. Das Werkzeug heißt occ, und man sollte es lieben lernen. occ status zeigt den Zustand, occ files:scan --all liest neu hinzugefügte Dateien ein, die von außen ins Datenverzeichnis gelegt wurden, occ db:add-missing-indices ergänzt fehlende Datenbankindizes nach einem Update, und occ maintenance:mode --on schaltet die Instanz für Wartungsarbeiten in einen read-only-Zustand. Letzteres ist übrigens der einzige saubere Weg, eine Datenbanksicherung zu erstellen, solange die Instanz läuft.

Ein Punkt, der immer wieder unterschätzt wird: Hintergrundaufgaben. Nextcloud verteilt viel Arbeit auf Cron-Jobs – Vorschaubilder, Papierkorbbereinigung, Dateiscans, Verschlüsselung. Der Standardweg über AJAX, bei dem Aufgaben erst beim Aufruf einer Seite loslaufen, ist im Dauerbetrieb eine Zumutung. Wer es ernst meint, richtet einen System-Cron ein, der alle fünf Minuten cron.php als Webserver-Benutzer aufruft, und aktiviert in den Grundeinstellungen den Cron-Modus. Das ist eine Kleinigkeit mit großer Wirkung.

Auch die Skalierung folgt keinem Geheimrezept. Solange alles auf einer Maschine läuft, limitiert die PHP-FPM-Konfiguration. Zu viele Worker fressen Speicher, zu wenige lassen Anfragen in die Warteschlange laufen. Dazu kommt OPcache – aktiviert man ihn, sollte man unbedingt die Standardgrößen anpassen, denn die voreingestellten Werte sind für kleine Anwendungen gedacht, nicht für ein Framework mit tausenden Dateien. Ab einer gewissen Größenordnung trennt man dann Datenbank, Redis und Webserver auf eigene Maschinen oder Container und stellt den Objektspeicher auf S3-kompatiblen Storage um – die Dateien liegen dann nicht mehr im lokalen data-Verzeichnis, sondern in einem Bucket. Das ist keine Spielerei, sondern der übliche Weg, wenn die Datenmenge in den zweistelligen Terabyte-Bereich wächst.

Sicherheit ist kein Feature, sondern eine Haltung

Bei selbstgehosteten Systemen ist der Betreiber der Sicherheitsverantwortliche. Klingt banal, ist aber der Knackpunkt vieler Projekte. Die Werkzeugkiste für Nextcloud ist gut gefüllt: Zwei-Faktor-Authentifizierung per TOTP oder WebAuthn, App-Passwörter für Clients, die kein zweites Faktorverfahren beherrschen, Brute-Force-Schutz auf Anwendungsebene, Passwortrichtlinien, Audit-Log, Dateizugriffskontrolle über ACLs und Gruppenordner.

Verschlüsselung will differenziert betrachtet werden. Serverseitige Verschlüsselung schützt die Daten auf dem Speichermedium, aber nicht vor jemandem, der Zugriff auf den Server hat – die Schlüssel liegen dort, wo die Anwendung sie lesen kann. Ende-zu-Ende-Verschlüsselung für einzelne Ordner ist deutlich strenger, bringt aber Einschränkungen mit: keine serverseitige Vorschauerzeugung, keine Volltextsuche im Klartext, kein bedenkenloses Teilen an Gruppen. Wer heute generative Suchfunktionen oder Office-Bearbeitung im Browser nutzen will, muss sehr genau prüfen, was mit E2E noch geht. Hier hilft nur Ausprobieren, nicht Nachlesen.

Zur Grundhygiene gehört außerdem der Netzwerkrand: ein Reverse Proxy mit TLS, HSTS, sinnvollen Security-Headern, Rate Limiting und – dringend empfohlen – einer CrowdSec- oder Fail2ban-Instanz, die auffällige Quellen früh aussperrt. In der Nextcloud-Konfiguration müssen trusted_proxies und die Overwrite-Parameter gesetzt sein, sonst generiert die Anwendung falsche Links, und die Clients laufen in Zertifikats- oder Weiterleitungsfehler. Ein klassischer Anfängerfehler, der regelmäßig zu Support-Threads führt.

Dolibarr: ERP ohne Lizenzmodell

Dolibarr ist der pragmatische Gegenentwurf zu schwergewichtigen ERP-Suiten. Die Software kommt aus Frankreich, steht unter GPLv3 und deckt einen erstaunlich breiten kaufmännischen Bereich ab: Stammdaten von Kunden und Lieferanten, Angebote, Aufträge, Rechnungen, Zahlungen, Produkte und Dienstleistungen, Lagerhaltung, Projekte mit Zeiterfassung, Personalverwaltung mit Urlaubsanträgen und Spesen, Agenda, Spendenverwaltung, Kassensystem, E-Mail-Versand und mit einem zusätzlichen Modul sogar doppelte Buchführung.

Das Konzept ist modular, und das ist wörtlich gemeint. Bei der Installation sind fast alle Funktionen zunächst deaktiviert. Der Administrator entscheidet Modul für Modul, was gebraucht wird. Ein Handwerksbetrieb aktiviert Aufträge, Rechnungen und Projekte. Ein Verein braucht Mitgliederverwaltung und Spenden. Ein kleines Handelsunternehmen schaltet Lager und Kassensystem dazu. Diese Zurückhaltung macht die Oberfläche überschaubar, auch wenn sie dadurch nicht automatisch schön wird.

Denn ja: Dolibarrs Benutzeroberfläche ist funktional, aber nüchtern. Wer aus modernen SaaS-Produkten kommt, wird die Menüführung und das Formularlayout als gewöhnungsbedürftig empfinden. Dafür ist die Lernkurve nach den ersten Tagen überraschend flach, und die Datenstruktur ist konsistent – ein Vorteil, den man erst merkt, wenn man Berichte oder Auswertungen bauen will.

Technischer Aufbau und Betrieb

Unter der Haube ist Dolibarr eine PHP-Anwendung mit MariaDB oder MySQL, seit einigen Versionen auch mit PostgreSQL-Unterstützung. Die Installation ist im Kern ein Datei-Upload plus ein Web-Installer, der die Konfigurationsdatei erzeugt. Für den Dauerbetrieb sollte man trotzdem nicht dabei bleiben. Wichtiger sind: ein eigenes Datenbankkonto mit eng begrenzten Rechten, ein separates PHP-FPM-Pool mit eigenem Systembenutzer, korrekte Dateirechte auf dem documents-Verzeichnis und ein sauber konfiguriertes conf.php, das außerhalb des Webroots oder zumindest gegen Direktzugriff geschützt liegt.

Dolibarr bringt eine eigene Cron-Infrastruktur mit, über die wiederkehrende Aufgaben laufen – Rechnungsstellung bei Abonnements, Erinnerungen, E-Mail-Warteschlangen, Importjobs. Diese Jobs lassen sich entweder über einen System-Cron anstoßen oder über einen externen Dienst triggern. Wer sie ignoriert, wundert sich irgendwann, warum Mahnungen nicht versendet werden und Rechnungsvorlagen im Postausgang hängen bleiben.

Bei der Versionierung ist etwas Disziplin angebracht. Dolibarr veröffentlicht in einem halbjährlichen Rhythmus neue Hauptversionen, dazwischen Fehlerbehebungen. Nicht jede Version ist für den produktiven Einsatz gedacht; es gibt LTS-Zweige, die länger gepflegt werden, und genau die sind für Betriebe die richtige Wahl. Das Upgrade selbst ist technisch unspektakulär – Datenbank sichern, Dateien tauschen, Web-Installer aufrufen –, aber man sollte es nie zwischen zwei Kundenterminen machen.

Der Modulmarkt und seine Fallstricke

Dolibarrs Stärke ist zugleich seine Herausforderung: Der Funktionsumfang ist groß, aber nicht jede Lücke wird von der Community geschlossen. Für spezielle Anforderungen – etwa eine bestimmte DATEV-Schnittstelle, eine Branchenlösung oder ein ausgefeiltes Vertriebsmodul – gibt es externe Module von Dienstleistern, die kostenpflichtig sind. Das ist legitim und häufig günstiger als eine Individualentwicklung. Man sollte sich allerdings klarmachen, dass man damit Abhängigkeiten eingeht: Wer pflegt das Modul, funktioniert es nach dem nächsten Hauptrelease noch, und gibt es einen Supportweg, wenn nicht?

Nicht zuletzt ist die Dokumentation ein Thema. Die offizielle Doku ist umfangreich, aber nicht immer aktuell, und die Community antwortet in Foren je nach Sprache unterschiedlich schnell. Wer sich auf Dolibarr einlässt, sollte Bereitschaft mitbringen, im Zweifel im Quellcode nachzusehen. Das ist bei einer offenen PHP-Anwendung machbar – aber es kostet Zeit.

Warum die Kombination mehr ist als eine Notlösung

Nun zum eigentlichen Thema. Warum sollte man Nextcloud und Dolibarr zusammen betreiben? Die kurze Antwort: weil sie an derselben Bruchstelle ansetzen, an der viele kleine und mittlere Betriebe scheitern – der Verbindung zwischen kaufmännischem Vorgang und Dokument.

In der Praxis sieht das Dilemma so aus: Die Buchhaltung erzeugt eine Rechnung als PDF. Diese PDF muss zum Kunden, in den Ordner, ins Archiv, ins Steuerbüro, eventuell in eine revisionssichere Ablage. Ohne Integration landet sie irgendwo – auf einem Netzlaufwerk, in einem E-Mail-Postfach, auf dem Rechner einer Mitarbeiterin, die irgendwann das Unternehmen verlässt. Genau hier greifen die beiden Systeme ineinander.

Und es gibt noch einen zweiten Grund, der oft übersehen wird: die Datenhoheit. Wer Nextcloud und Dolibarr selbst betreibt, hält Kundendaten, Verträge, Buchhaltungsunterlagen und Geschäftsgeheimnisse auf eigener Hardware oder in einem europäischen Rechenzentrum seiner Wahl. Ob das automatisch DSGVO-konform ist, sei dahingestellt – Selbsthosting ist kein Freifahrtschein, sondern verlagert die Verantwortung. Aber es schafft Gestaltungsspielraum, den man mit SaaS-Angeboten schlicht nicht hat.

Integration über WebDAV: die pragmatische Variante

Der technisch einfachste Weg, beide Welten zu verbinden, führt über WebDAV. Nextcloud spricht WebDAV unter /remote.php/dav/files/<benutzer>/, und Dolibarr bringt seit einigen Versionen im ECM-Modul einen eigenen WebDAV-Client mit. Damit lässt sich Nextcloud als externer Speicher für die Dokumentenverwaltung von Dolibarr einbinden. Der Aufbau ist dann typischerweise hierarchisch: ein Wurzelverzeichnis für Kunden, Lieferanten, Produkte, Rechnungen und Projekte.

Eine wichtige Warnung an dieser Stelle, weil sie in Foren immer wieder auftaucht: Niemals sollte man versuchen, das Dolibarr-Verzeichnis documents direkt in Nextclouds data-Verzeichnis zu legen oder umgekehrt. Nextclouds Datenverzeichnis ist kein Freigabeordner. Wer dort fremde Strukturen anlegt oder Dateien von außen hineinkopiert, zerstört früher oder später den Metadatenbestand und kann die Instanz im schlimmsten Fall neu aufbauen. Der offizielle Kontaktpunkt ist WebDAV – oder, wenn es um Massendaten geht, eine saubere Anbindung über die jeweiligen APIs.

Ein zweiter, häufig unterschätzter Aspekt: Berechtigungen. Wenn Dolibarr über einen einzigen technischen WebDAV-Benutzer auf Nextcloud zugreift, erbt jeder Dolibarr-Nutzer dessen Rechte, sofern Dolibarr das nicht selbst filtert. Das ist ein Sicherheitsloch, das man nicht haben möchte. Deshalb ist eine sorgfältige Rechteplanung in Nextcloud nötig – Gruppenordner, technische Benutzer pro Mandant, klare Trennung zwischen Vertrieb, Buchhaltung und Geschäftsführung.

Single Sign-On: weniger Bequemlichkeit als Sicherheitsgewinn

Zwei Systeme bedeuten zwei Anmeldungen. Das ist lästig, aber vor allem ist es ein Sicherheitsproblem, weil Nutzer dazu neigen, identische Passwörter zu verwenden und diese großzügig weiterzugeben. Ein zentraler Identity Provider entschärft das erheblich. In der Praxis hat sich eine Kombination bewährt: ein Keycloak, Authentik oder Zitadel als IdP, Nextcloud angebunden über die OIDC-App oder die SAML-Anwendung, Dolibarr über das LDAP-Modul oder ein SAML-Modul eines Drittanbieters.

Die LDAP-Variante ist bei Dolibarr der reifere Weg. Dolibarr kann Benutzer aus einem Verzeichnisdienst importieren und synchronisieren, was bedeutet, dass neue Mitarbeiter zentral angelegt werden und nicht in zwei Systemen. Die SAML-Anbindung ist machbar, aber sie stammt aus dem Modul-Ökosystem und ist damit nicht kostenfrei. Wer einen Identity Provider ohnehin betreibt, wird trotzdem zur SAML-Variante greifen, weil sie echtes Single Sign-On liefert statt nur einer Passwortprüfung gegen das Verzeichnis.

Ein interessanter Aspekt: Nextcloud kann als Identity Provider nicht ohne Weiteres für Dolibarr dienen – dafür fehlt die IdP-Rolle. Die naheliegende Reihenfolge ist also: IdP als zentrale Instanz, beide Anwendungen als Service Provider. Klingt nach Mehraufwand, ist es auch. Aber die Alternative, in zwei Anwendungen parallel Benutzer zu pflegen, rächt sich spätestens beim ersten Offboarding, wenn ein ehemaliger Mitarbeiter in einem System vergessen wurde.

Automatisierung: von der Datei zur Kette

Richtig interessant wird es, wenn man die APIs ins Spiel bringt. Dolibarr verfügt über eine REST-Schnittstelle, die nach Aktivierung des Webservice-Moduls nahezu alle Objekte abbildet – Drittparteien, Angebote, Rechnungen, Produkte, Projekte, Zahlungen. Der Zugriff erfolgt über einen API-Schlüssel pro Benutzer. Nextcloud bietet daneben die OCS-API und die WebDAV-Schnittstelle, über die sich Dateien, Freigaben und Ordnerstrukturen automatisieren lassen.

Daraus lassen sich Abläufe bauen, die vorher manuelle Handarbeit waren. Ein Beispiel aus der Praxis: Sobald in Dolibarr eine Rechnung als bezahlt markiert wird, erzeugt ein Cron-Job das PDF, legt es per WebDAV in den Kundenordner in Nextcloud und schreibt einen Eintrag in ein Protokoll. Ein zweiter Schritt erzeugt in Nextcloud Talk einen dedizierten Kanal für das Projekt, damit alle Beteiligten Zugriff auf denselben Stand haben. Solche Ketten lassen sich direkt in PHP-Skripten oder mit Automatisierungswerkzeugen wie n8n bauen. Wer ohnehin eine Low-Code-Plattform betreibt, spart sich dabei viel Eigenentwicklung.

Auch die Gegenrichtung funktioniert. Nextclouds Workflow-Engine kann bei Dateiänderungen oder -uploads automatische Aktionen auslösen – etwa ein Benachrichtigung an eine Gruppe, eine Umbenennung nach Namensschema oder ein Tag setzen. Kombiniert man das mit einem Webhook in Richtung Dolibarr, lässt sich etwa der Eingang eines Lieferantenbelegs dokumentieren, ohne dass jemand händisch eine Eingangsrechnung erfasst.

Man sollte bei alldem die Komplexität im Blick behalten. Jede Automatisierung ist ein Stück Code, das gewartet werden will. Eine Kette, die niemand dokumentiert hat und die nach einem Update steht, ist schlimmer als der manuelle Prozess von vorher. Deshalb: Automationen immer mit Protokollierung bauen, mit Fehlerbenachrichtigung, und immer so, dass ein manueller Fallback existiert.

Betriebsalltag: Was beide Systeme gemeinsam haben

Obwohl Nextcloud und Dolibarr unterschiedliche Aufgaben erfüllen, teilen sie dieselben betrieblichen Realitäten. Beide sind PHP-Anwendungen, beide benötigen eine relationale Datenbank, beide leben von einer sauberen Backup-Strategie, und beide werden von ihren Communities schnell weiterentwickelt.

Backups, die diesen Namen verdienen

Ein Backup, das nie getestet wurde, ist kein Backup, sondern eine Dateisammlung. Bei Nextcloud gilt: Instanz in den Wartungsmodus, Datenbank sichern, Datenverzeichnis sichern – idealerweise als Snapshot oder inkrementell –, Konfiguration sichern, Wartungsmodus beenden. Wer den Wartungsmodus weglässt, riskiert eine inkonsistente Datenbank, in der Dateieinträge auf Dateien verweisen, die noch gar nicht geschrieben wurden. Bei Dolibarr ist es ähnlich: Datenbankdump, documents-Verzeichnis, conf.php. Nichts davon liegt in der Datenbank, weshalb der klassische dump-only-Ansatz hier zwangsläufig scheitert.

Sinnvoll ist zudem eine Versionierung, die über das tägliche Vollbackup hinausgeht. MySQL und MariaDB schreiben Binärlogs, mit denen sich ein Point-in-Time-Recovery machen lässt. Wenn eine Mitarbeiterin um 14:37 Uhr versehentlich einen Ordner löscht und das Backup von 03:00 Uhr stammt, ist der Unterschied zwischen „vier Stunden Arbeit verloren“ und „fünf Minuten Wiederherstellung“ genau dieser Punkt.

Überwachung und Fehlersuche

Nextcloud bringt von Haus aus brauchbare Diagnosewerkzeuge mit: die Statusübersicht im Adminbereich, das Serverinfo-Modul, ein konfigurierbarer Log-Level und mit occ eine Möglichkeit, viele Probleme von der Kommandozeile aus einzugrenzen. Wer es ernsthaft betreiben will, exportiert die Kennzahlen nach Prometheus und baut sich ein Dashboard auf. Datenbankverbindungen, PHP-FPM-Queue, Cron-Laufzeiten, Speicherbelegung, Anzahl der Dateikonflikte – diese Werte erzählen früh, wenn etwas aus der Balance gerät.

Dolibarr ist hier sparsamer aufgestellt. Es schreibt in eine eigene Logdatei und bietet Optionen für Syslog, aber ein umfassendes Monitoring-Framework sucht man vergeblich. Das ist ein echter Nachteil, der in produktiven Umgebungen durch externe Überwachung kompensiert werden muss: Verfügbarkeitschecks auf HTTP-Ebene, Datenbankmetriken, Plattenplatz, regelmäßige Prüfung der Cron-Jobs. Wer beides betreibt, sollte die Zustandsüberwachung zentralisieren, statt pro Anwendung eine eigene Insel zu bauen.

Wo die Grenzen liegen

Man tut beiden Projekten keinen Gefallen, wenn man sie schönredet. Nextcloud hat in großen Installationen mit der Performance von PHP zu kämpfen, wenn die Instanz nicht sauber getunt ist. Der Desktop-Client kann eigenwillig reagieren, wenn Nutzer dieselbe Datei auf zwei Geräten gleichzeitig bearbeiten und das Konfliktmanagement nicht greift. Der App-Store enthält Qualität und Ballast, und die Release-Zyklen sind so kurz, dass Administratoren dauerhaft gefordert sind. Wer nicht regelmäßig Updates einspielen will, sollte eine andere Lösung wählen – und zwar bevor die Instanz produktiv geht, nicht danach.

Dolibarr wiederum hat eine Oberfläche, die man mögen muss, und eine Doku, die man geduldig lesen muss. Das Standarddesign lässt sich anpassen, aber es kostet Arbeit. Manche Module sind funktional, aber nicht komfortabel. Und es gibt Bereiche – etwa die Lohnbuchhaltung oder komplexe Produktionsplanung –, in denen Dolibarr an Grenzen stößt und andere Systeme die bessere Wahl sind. Das ist keine Schwäche, sondern eine Frage der Zielgruppe.

Nicht zuletzt: Beide Systeme zusammen bedeuten zwei Updateschläuche, zwei Backup-Jobs, zwei Fehlerquellen. Wer das unterschätzt, hat nach einem Jahr eine halb gepatchte Nextcloud und eine Dolibarr-Instanz, die noch auf einer alten Datenbank läuft, weil das Upgrade „gerade nicht passt“. Genau so entstehen die Sicherheitsvorfälle, über die dann in Fachmedien berichtet wird.

Ein realistischer Fahrplan

Wer die Kombination neu aufsetzen will, sollte mit einer Testumgebung beginnen – und zwar mit einer, die der Produktionsumgebung ähnelt. Vier bis acht vCPU, 16 bis 32 Gigabyte Arbeitsspeicher, NVMe-Speicher und eine getrennte Datenbankinstanz sind für einen Betrieb mit dreißig bis fünfzig Nutzern eine vernünftige Ausgangsbasis. Darauf: nginx, PHP-FPM mit separaten Pools pro Anwendung, MariaDB mit angepassten Einstellungen, Redis, ein Reverse Proxy mit TLS, ein Identity Provider.

Dann folgt der unangenehme Teil, den viele überspringen: die Ablage strukturieren. Bevor die erste Datei hochgeladen wird, sollte klar sein, wie die Ordnerhierarchie aussieht, welche Gruppen welche Rechte haben und wer Eigentümer gemeinsamer Ordner ist. Eine nachträgliche Umstrukturierung von zehntausend Dateien mit gewachsenen Rechten ist ein Projekt für sich. Wer hier zwei Tage investiert, spart später Wochen.

Der letzte Schritt ist die Migration der kaufmännischen Daten. Dolibarr bringt Importwerkzeuge für CSV-Dateien mit, über die Kunden, Produkte und offene Rechnungen übernommen werden können. Das ist mit Sorgfalt zu machen, weil ein falsch importierter Zahlungsstand später viel Ärger verursacht. Bewährt hat sich ein Parallelbetrieb über ein bis zwei Abrechnungsperioden: Das Altsystem läuft weiter mit, die neue Umgebung wird mit echten Vorgängen befüllt, und man vergleicht die Ergebnisse. Erst wenn sie übereinstimmen, wird umgeschaltet.

Fazit

Nextcloud und Dolibarr sind keine Traumpaarung im marketingtauglichen Sinn. Sie sind zwei Werkzeuge mit unterschiedlicher Herkunft, die sich an einer entscheidenden Stelle berühren: dort, wo Dokumente entstehen, gebraucht und archiviert werden. Verbunden über WebDAV, abgesichert über einen zentralen Identity Provider, automatisiert über ihre jeweiligen APIs, ergeben sie eine Arbeitsumgebung, die für viele kleine und mittlere Betriebe erstaunlich gut passt – ohne Lizenzkosten pro Sitzplatz und mit der Datenhoheit beim Betreiber.

Der Preis dafür ist Aufmerksamkeit. Beide Systeme wollen gepflegt werden, und die Verantwortung für Sicherheit, Backup und Verfügbarkeit liegt vollständig beim Betreiber. Wer das akzeptiert und die nötige Zeit einplant, bekommt eine Infrastruktur, die sich über Jahre trägt und die man nicht bei jedem Anbieterwechsel neu aufbauen muss. Wer eine Lösung sucht, die man einmal installiert und dann vergisst, wird mit dieser Kombination nicht glücklich.

Ein letzter Gedanke: Die spannendere Entwicklung liegt weniger in neuen Funktionen als in der Frage, wie offene Systeme miteinander sprechen. Standards wie WebDAV, CalDAV, OIDC und REST sind unspektakulär – und genau deshalb tragen sie. Die Integration zwischen einer Groupware und einer Warenwirtschaft ist kein Hexenwerk, sondern eine Frage sorgfältiger Konfiguration. Das ist die eigentliche Botschaft dieser Kombination: Man muss nicht alles aus einer Hand kaufen, um einen stimmigen Arbeitsablauf zu bekommen.