Nextcloud und Docker: Ein Praxisleitfaden für die selbstgehostete Cloud
Nextcloud ist für viele Unternehmen und technikaffine Privatpersonen die einzig plausible Antwort auf die Frage nach digitaler Autonomie. Die Software verbindet Dateiablage, Kalender, Kontakte, Office-Dokumente und Kommunikation zu einer Plattform, die auf dem eigenen Server läuft – oder im Rechenzentrum, auf das man selbst Zugriff hat. Docker hat sich in den vergangenen Jahren als Standardwerkzeug für die Auslieferung solcher Anwendungen etabliert. Das klingt in der Theorie bestechend: Ein Befehl zieht eine komplette Umgebung hoch, in der Nextcloud sofort funktioniert. In der Praxis zeigt sich jedoch, dass Container die Komplexität nicht verschwinden lassen, sondern nur anders organisieren. Wer Nextcloud mit Docker betreibt, muss sich mit Architektur, Datenhaltung und einigen Eigenheiten der Software auseinandersetzen. Dieser Artikel begleitet Sie dabei – von der ersten Container-Umgebung bis zum abgesicherten, performanten Produktivbetrieb.
Warum überhaupt Nextcloud?
Die Zeiten, in denen eine private Cloud nur aus einem Netzwerkspeicher mit ein paar Ordnerfreigaben bestand, sind lange vorbei. Nextcloud hat sich zu einer Plattform entwickelt, die inzwischen einen erheblichen Teil der üblichen Büro- und Kollaborationsarbeit abdeckt. Dokumente lassen sich online bearbeiten und kommentieren, Videokonferenzen sind integriert, und über Erweiterungen gibt es Schnittstellen zu E-Mail, PDF-Workflows und sogar KI-gestützter Textanalyse. Was die Software gegenüber proprietären Diensten auszeichnet, ist der offene Quellcode und die Möglichkeit, alle Daten selbst zu kontrollieren. Gerade für Organisationen mit strengen Datenschutzanforderungen ist das ein unschlagbares Argument. Aber auch für Einzelpersonen, die nicht jede Notiz in den Server eines US-Konzerns verschieben möchten, ist Nextcloud eine ernsthafte Option.
Allerdings hat diese Mächtigkeit ihren Preis. Nextcloud ist kein kleines PHP-Programm, das mal eben in ein Webverzeichnis kopiert wird. Die Installation umfasst eine Datenbank, einen Cache-Dienst, einen Webserver mit PHP und nicht selten zusätzlich eine Office-Integration. Wer früher eine Nextcloud manuell eingerichtet hat, kennt die Mühen mit falschen PHP-Modulen, verschachtelten Verzeichnisberechtigungen und Konfigurationsfehlern, die sich erst nach Tagen bemerkbar machen. Genau hier setzt Docker an: Es bündelt alle Komponenten in isolierten Containern und stellt so sicher, dass die Umgebung reproduzierbar ist. Die Theorie verheißt, dass ein Update nur noch aus dem Austausch eines Images besteht. Die Praxis ist erstaunlich nah an dieser Verheißung – vorausgesetzt, man hat einige Grundprinzipien verinnerlicht.
Docker als Fundament: Vorzüge und Tücken
Die zentrale Idee von Docker ist es, Software mit ihrem gesamten Laufzeit-Ökosystem auszuliefern. Ein Container enthält alles, was ein Prozess benötigt: Libraries, Laufzeitumgebung, Systemdateien. Das macht die Anwendung unabhängig vom Betriebssystem des Hosts und vereinfacht das Deployment erheblich. Für Nextcloud bedeutet das: Man vergisst endlich die Sorge, ob auf dem Server die richtige PHP-Version läuft und ob die Erweiterungen für Exif, GD oder Intl vorhanden sind. Das offizielle Image bringt genau diese Bestandteile bereits mit. Es gibt sogar verschiedene Varianten: Einmal mit Apache als Webserver und einmal mit PHP-FPM. Letzteres eignet sich für den Betrieb mit einem separaten Webserver wie Nginx, was in professionellen Umgebungen häufig die bessere Wahl ist.
Doch Docker ist kein Selbstläufer. Ein Container ist standardmäßig kurzlebig und zustandslos. Nextcloud ist jedoch eine zustandsbehaftete Anwendung. Sie schreibt Dateien, führt Datenbankoperationen aus und verwaltet Konfigurationen. Diese Daten müssen über Containerwechsel hinaus bestehen bleiben – genau dafür gibt es Docker-Volumes. Wer das ignoriert und die Dateien nur im Container lässt, verliert sie beim nächsten `docker compose down`. Ein weiteres häufiges Problem ist die Netzwerkkommunikation. In einer Docker-Umgebung sprechen die Dienste über interne Netzwerke miteinander. Wenn die Konfiguration nicht stimmt, meldet Nextcloud beispielsweise `Deletion of file failed` oder zeigt eine weiße Seite, weil die Verbindung zur Datenbank nicht zustande kommt. Die Fehlersuche ist dann deutlich aufwendiger als bei einer klassischen Installation.
Wer sich also für Docker entscheidet, muss sich mit den Konzepten der Container-Orchestrierung anfreunden – zumindest mit den Grundlagen. Dazu gehören Volumes, Netzwerke, Umgebungsvariablen und die Vorstellung, dass Kinderkrankheiten der Software nicht einfach durch einen Neustart des Hosts behoben sind. Dafür belohnt Docker mit einer großen Portabilität: Man kann die gesamte Nextcloud-Infrastruktur auf einen anderen Server verschieben, indem man die Compose-Datei, das Datenverzeichnis und die `.env`-Datei mitnimmt. Das ist ein immenser Vorteil gegenüber herkömmlichen Installationen, bei denen man sonst stundenlang PHP-Pakete nachrüsten darf.
Die offiziellen Images: Apache, FPM und die Frage der Architektur
Nextcloud pflegt auf Docker Hub mehrere offizielle Image-Varianten. Die wichtigste Unterscheidung ist die zwischen dem `nextcloud:apache`-Image und dem `nextcloud:fpm`-Image. Erstere Variante bringt den kompletten Webserver mit, inklusive einer funktionierenden Konfiguration. Man gibt einfach einen Port nach außen frei, und die Instanz ist erreichbar. Das ist die schnellste Methode, um eine Nextcloud aufzusetzen – ideal für Tests oder kleine Umgebungen mit wenigen Benutzern. Natürlich lässt sich auch dieses Image in ein Compose-Setup mit Datenbank und Redis integrieren. Der eingebaute Apache-Prozess übernimmt dann sämtliche HTTP-Aufgaben.
Das FPM-Image ist anders aufgebaut. Hier wird die PHP-Anwendung in einem Prozessmanager ausgeführt, der nicht selbst HTTP versteht. FPM spricht – vereinfacht gesagt – FastCGI. Dafür wird ein separater Webserver benötigt, der eingehende HTTP-Requests an den FPM-Prozess weiterleitet. In der Docker-Welt ist das häufig Nginx. Diese Trennung hat Vorteile: Man kann den Webserver optimieren, ohne das Nextcloud-Image zu verändern. Und man kann den FPM-Container unabhängig von Webserver-Containern skalieren. Für die meisten produktiven Installationen ist das die robustere Architektur. Allerdings steigt die Komplexität, denn nun muss man sich um eine zusätzliche Konfigurationsdatei kümmern – etwa darum, wie Nginx Anfragen an den PHP-Dienst weiterreicht.
Daneben gibt es noch Varianten wie `nextcloud:stable`, die eine der stabilen Versionslinien nach einem festen Schema referenziert. Wichtig ist, niemals mit `latest` zu arbeiten, wenn man ein verlässliches Deployment haben möchte. Das Image wird regelmäßig neu gebaut, und die Versionssprünge sind manchmal größer als erwartet. Besser man pinnt die Version, zum Beispiel `nextcloud:29-fpm`. So behält man die Kontrolle und kann bewusst aktualisieren.
Eine belastbare Grundarchitektur mit Docker Compose
Wer Nextcloud nicht nur experimentell betreiben will, sollte die einzelnen Komponenten als eigenständige Container anlegen. Dazu gehören mindestens eine Datenbank, ein Cache-Dienst, die Anwendung selbst und ein Webserver. Docker Compose ist das passende Werkzeug, um diese Dienste zu definieren und gemeinsam zu verwalten. Ein typisches Setup sieht dann so aus:
services:
db:
image: mariadb:10.11
restart: unless-stopped
command: --transaction-isolation=READ-COMMITTED --binlog-format=ROW
environment:
MYSQL_ROOT_PASSWORD: ${DB_ROOT_PASSWORD}
MYSQL_DATABASE: nextcloud
MYSQL_USER: nextcloud
MYSQL_PASSWORD: ${DB_PASSWORD}
volumes:
- db_data:/var/lib/mysql
healthcheck:
test: ["CMD", "healthcheck.sh", "--connect", "--innodb_initialized"]
interval: 10s
timeout: 5s
retries: 5
redis:
image: redis:7
restart: unless-stopped
app:
image: nextcloud:29-fpm
restart: unless-stopped
environment:
MYSQL_HOST: db
REDIS_HOST: redis
PHP_MEMORY_LIMIT: 512M
volumes:
- nextcloud_data:/var/www/html
depends_on:
- db
- redis
web:
image: nginx:1.25
restart: unless-stopped
ports:
- "8080:80"
volumes:
- nextcloud_data:/var/www/html:ro
- ./nginx.conf:/etc/nginx/conf.d/default.conf:ro
depends_on:
- app
volumes:
db_data:
nextcloud_data:
In dieser Konfiguration wird Nextcloud als `app`-Container betrieben, wobei das Verzeichnis `/var/www/html` in einem Volume namens `nextcloud_data` persistiert wird. Der Nginx-Webserver erhält von außen Anfragen auf Port 8080 und leitet sie an den FPM-Container weiter. Die Datenbank läuft als MariaDB und verwendet ein eigenes Volume. Redis wird für Caching und Locks eingesetzt – auf die Details dazu kommen wir noch zurück.
Auffällig ist, dass der `app`-Container keinen direkten Port nach außen freigibt. Das ist gewollt, denn er soll nur über den internen Webserver erreichbar sein. Wer unbedingt die schnelle Variante mit Apache nutzen möchte, kann sich das FPM-Image sparen und stattdessen `nextcloud:apache` verwenden. In dem Fall entfallen der Nginx-Container und die eigene Konfigurationsdatei. Der Komfort hat aber seinen Preis: Man kann die HTTP-Ebene nicht mehr individualisieren, und die Trennung der Dienste ist weniger sauber.
Die feinen Details: Umgebungsvariablen und erste Konfiguration
Beim ersten Start liest das Nextcloud-Image eine Reihe von Umgebungsvariablen, um die Datenbankverbindung und das Administratorenkonto anzulegen. Die wichtigsten Variablen sind `MYSQL_HOST`, `MYSQL_DATABASE`, `MYSQL_USER` und `MYSQL_PASSWORD`. Der Hostname muss dabei mit dem Dienstnamen in der Compose-Datei übereinstimmen, also `db`. Weiterhin gibt es `NEXTCLOUD_ADMIN_USER` und `NEXTCLOUD_ADMIN_PASSWORD`, mit denen das erste Konto erzeugt wird. Später kann man weitere Benutzer im Webinterface anlegen. Es ist nicht nötig, diese Variablen dauerhaft zu setzen; das Image überträgt die Informationen in die lokale Konfigurationsdatei. Aber auch bei späteren Updates spielt das Image diese Einstellungen zusammen. Deshalb sollte man in Compose nicht mit festen Klartext-Passwörtern arbeiten, sondern mit einer `.env`-Datei, die nicht in die Versionskontrolle gehört.
Die eigentliche Konfiguration von Nextcloud steckt in der Datei `config.php`. Sie liegt im Volume unter `/var/www/html/config`. Viele Einstellungen, die man in einem normalen System per Webinstaller setzt, können hier direkt eingetragen werden. Dazu gehört die Liste der vertrauenswürdigen Domains, die dafür sorgt, dass Nextcloud Anfragen nur annimmt, wenn sie an einen eingetragenen Hostnamen gehen. Diese Liste ist essenziell, wenn man die Instanz hinter einem Reverse Proxy betreibt. Im Docker-Kontext kann man die Datei von außen bearbeiten, solange das Volume gemountet ist. Man muss jedoch darauf achten, dass der Container die Datei beim Start nicht überschreibt. Das offizielle Image legt sie nur an, wenn sie noch nicht existiert.
Ein weiterer wichtiger Punkt ist die Konfiguration der Vertrauensgrenzen. Wenn man hinter einem Nginx- oder Traefik-Proxy arbeitet, muss Nextcloud wissen, dass die eigentliche Verbindung über HTTPS läuft, obwohl der Container nur HTTP sieht. Dafür gibt es die Variablen `overwriteprotocol` und `overwritehost` in der `config.php`. Ohne diese Angaben kann es zu Endlos-Loops kommen oder die Anwendung beschwert sich, dass die Sicherheitswarnung „Der Reverse Proxy hat nicht die richtigen Header gesetzt“ besteht. Wer mit einem modernen Reverse Proxy wie Traefik arbeitet, der die X-Forwarded-Header korrekt setzt, kann die automatische Erkennung nutzen. In den meisten Fällen ist es aber sicherer, die Werte manuell zu spezifizieren.
Der Reverse Proxy: Tür ins Freie oder Stolperfalle
Sobald die Nextcloud-Instanz von außen erreichbar sein soll, genügt es nicht, den Port des Webservers freizugeben. Ohne HTTPS und ohne gescheite HTTP-Header spielt das Ganze keine Rolle für den Ernstfall. Ein Reverse Proxy ist heute obligatorisch, und er übernimmt in der Regel auch das Ausstellen von Let’s-Encrypt-Zertifikaten. In einer Docker-Umgebung kann man hierfür entweder einen Nginx-Container als zentralen Einstiegspunkt betreiben oder Traefik nutzen, das Zertifikatsmanagement automatisch erledigt. Wenn man die weiter oben gezeigte Nginx-Architektur vertikal erweitern möchte, braucht man also nur einen zusätzlichen Nginx-Container, der eingehende Verbindungen auf Port 80/443 annimmt und an den Web-Container auf Port 8080 weiterreicht. Eine minimale Konfiguration dafür sieht so aus:
server {
listen 80;
server_name cloud.example.com;
return 301 https://$host$request_uri;
}
server {
listen 443 ssl http2;
server_name cloud.example.com;
ssl_certificate /etc/letsencrypt/live/cloud.example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/cloud.example.com/privkey.pem;
ssl_protocols TLSv1.2 TLSv1.3;
client_max_body_size 10G;
add_header Strict-Transport-Security "max-age=15768000" always;
location / {
proxy_pass http://web:8080;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
Diese Konfiguration ist bewusst einfach gehalten. Sie zeigt das Grundprinzip: Der eigentliche Nextcloud-Container bleibt im internen Compose-Netzwerk abgeschirmt, während der Proxy die einzige öffentliche Schnittstelle darstellt. Ein Vorteil dieser Trennung ist, dass man den Nextcloud-Webcontainer je nach Bedarf erweitern oder ersetzen kann, ohne den Außenauftritt zu verändern. Gleichzeitig ist dies auch ein Nachteil: Fehler in der Proxykonfiguration führen gerne zu unklaren Fehlermeldungen wie „502 Bad Gateway“ oder leeren Seiten. Die Ursache liegt dann nicht in Nextcloud selbst, sondern in einer falsch gesetzten IP-Weiterleitung. Der Satz `proxy_set_header Host $host;` ist dabei das wichtigste Element – er signalisiert der Anwendung, welchen Hostnamen der Client verwendet.
Wer Traefik bevorzugt, findet in der Compose-Datei eine elegantere Lösung. Traefik kann über Labels automatisch herausfinden, dass es Requests an den Nextcloud-Webcontainer weiterleiten soll. Es erstellt sogar Let’s-Encrypt-Zertifikate ganz ohne zusätzlichen Container. Allerdings ist Traefik selbst ein sehr mächtiges Werkzeug, das man beherrschen wollen muss. Ein Syntaxfehler in der dynamischen Konfiguration führt dazu, dass der Proxy nicht startet und die ganze Wolke kurzzeitig offline ist. Gerade für less erfahrene Administratorinnen und Administratoren ist der klassische Nginx- oder Caddy-Container oft schneller eingerichtet. Caddy macht sich dabei besonders beliebt, weil er TLS automatisch konfiguriert und keine ständige Pflege der Zertifikatsdateien erfordert.
Datenhaltung: Was liegt wo im Volume?
Ein Docker-Volume ist kein Zauberkasten, sondern ein Verzeichnis auf dem Host. Wenn man den gesamten `/var/www/html`-Ordner des Nextcloud-Images über ein Volume persistiert, dann bleiben alle Anwendungsdateien, die `config.php`, die `data`-Ordner und die installierten Apps erhalten. Das ist die sicherste Methode, weil das Image beim nächsten Update nichts überschreibt, was nicht fehlen darf. Einige Administratoren mounten separat nur `config` und `data`, um einen Überblick zu behalten. Das ist in den meisten Fällen ebenfalls okay, aber es kann Probleme geben, wenn Apps wie Collabora oder OnlyOffice eigene Dateien im `apps-extra`-Verzeichnis ablegen oder Aktualisierungen durchführen möchten. Wir empfehlen, die einfache Variante zu wählen: das ganze HTML-Verzeichnis als Volume persistieren.
Die eigentlichen Nutzerdaten liegen dann in `/var/www/html/data`. Dieses Unterverzeichnis ist im Volume enthalten und wird nicht als eigenes Volume gemountet. Wenn Sie die Daten später einmal auf einen anderen Host verschieben wollen, müssen Sie das gesamte `nextcloud_data`-Volume kopieren. Die Datenbank liegt separat in `db_data`. Diese Trennung ist wichtig, denn ein einfaches Kopieren des Dateisystems reicht nicht aus, um die Datenbank konsistent zu sichern. Dazu kommen wir im Abschnitt Backup noch einmal zurück.
Ein unbequemer Nebeneffekt des vollständigen Persistierens ist, dass Sie nach einem Image-Wechsel auf eine neue Version darauf achten müssen, dass die Verzeichnisberechtigungen im Container zum Host passen. Das offizielle Nextcloud-Image arbeitet mit dem Benutzer `www-data`, der die UID 33 hat. Wenn Ihr Host aus Sicherheitsgründen einen anderen Benutzer für das Volume verwendet, kann es zu Berechtigungsfehlern kommen. In der Praxis bewährt sich die Lösung, die Dateien im Volume dem `www-data`-Benutzer zu geben oder die UID des Host-Benutzers auf 33 zu mappen. Ein sauber geschriebenes Compose-File kann dies über `user: „33:33″` für den Container erledigen. Es ist ein scheinbar triviales Detail, aber es nervt später mächtig, wenn man bei einem Update nachts um drei auf einmal eine Fehlermeldung wie `File is not writable` erhält.
Updates ohne Bauchschmerzen
Der Alltag mit einer Nextcloud-Installation besteht zu einem großen Teil aus regelmäßigen Updates. Docker macht diese Updates im Prinzip einfach: Man zieht ein neues Image, ersetzt den Container, startet wieder. Doch die Datenbank ist von diesem Prozess nicht ausgenommen. Bei jedem Versionssprung führt Nextcloud Datenbankmigrationen durch, die während des Betriebs nicht ablaufen sollten. Das offizielle Docker-Image ist darauf trainiert, solche Migrationen beim Start automatisch auszuführen. Das funktioniert meist reibungslos, aber es gibt Situationen, in denen man den Prozess manuell kontrollieren sollte.
Vor einem größeren Update – etwa von Version 29 auf 30 – ist es ratsam, Nextcloud in den Wartungsmodus zu versetzen. Dafür genügt ein Befehl im laufenden Container:
docker exec -u www-data my_nextcloud_app php occ maintenance:mode --on
Anschließend zieht man das neue Image, etwa mit `docker compose pull app`, und aktualisiert die Container insgesamt. Nach dem Neustart sollte man die Logs beobachten, um zu sehen, ob die Migrationen fehlerfrei durchlaufen. Wenn etwas schiefgeht, ist der Wartungsmodus Ihr Rettungsanker, weil dadurch keine neuen Schreibzugriffe von Benutzern hereinkommen. Man kann dann in Ruhe untersuchen, ob die Datenbank ein neues Schema erwartet, und im Zweifel die alte Image-Version wieder zurückrollen. Es ist beruhigend zu wissen, dass die meisten Migrationen nicht irreversibel sind – aber das trifft nur zu, wenn man ein Datenbank-Backup zur Hand hat.
Einen wichtigen Punkt, den viele unterschätzen, ist das Upgrade von „Kleinversionen“ innerhalb derselben Major-Version. Hier gibt es in der Regel keine Datenbankänderungen, nur Anpassungen an PHP- oder JavaScript-Dateien. Das Wechseln des Images fühlt sich deshalb risikofrei an. Trotzdem empfiehlt es sich, den Wartungsmodus zu aktivieren, weil Nextcloud während des Upgrades auch die Dateien auf dem Volume aktualisiert. Wenn in diesem Moment ein Benutzer gerade eine Datei hochlädt oder eine Synchronisation läuft, kann das zu Inkonsistenzen führen. Der Wartungsmodus verhindert das, allerdings um den Preis, dass die Cloud für ein paar Minuten nicht erreichbar ist. Ein guter Zeitpunkt ist nachts oder am Wochenende – die meisten kleinen Installationen überleben das problemlos.
Backup-Strategien: Was wirklich hilft
Ein Backup, das nicht regelmäßig getestet wird, ist kein Backup. Das gilt insbesondere bei Docker, weil man schnell den Überblick darüber verliert, welche Daten in welchem Volume liegen. Für Nextcloud sind zwei Komponenten zu sichern: das `nextcloud_data`-Volume und die Datenbank. Wer nur das Volume kopiert, erhält die Dateien der Benutzer und die App-Dateien, aber die Datenbank bleibt außen vor – und in der Datenbank liegen die Metadaten, die Ordnerstruktur und die Freigaben. Umgekehrt reicht auch ein Datenbank-Dump nicht aus, weil die eigentlichen Dateien fehlen. Die beiden Sicherungen müssen also zusammenpassen.
Ein konsistenter Weg ist, Nextcloud vor der Sicherung in den Wartungsmodus zu versetzen. Dann wird sichergestellt, dass während des Dumps keine Schreibvorgänge passieren. Anschließend erstellt man einen `mysqldump` der Datenbank und kopiert das Volume. Ein einfaches Shell-Skript kann das erledigen, aber es gibt auch ausgereifte Werkzeuge wie Restic oder BorgBackup, die sich direkt mit Docker-Volumes verwenden lassen. Restic kann sogar das Dateisystem der Container durchforsten, wenn man es mit dem entsprechenden Docker-Plugin einsetzt. Für eine kleine Instanz ist aber ein traditionelles Skript völlig ausreichend. Wichtig ist, die Backups an einem anderen Ort zu speichern, am besten auf einem separaten Server oder in einer externen Storage-Lösung.
Ein typischer Fehler ist es, die Datenbank mit `mysqladmin` einfach herunterzufahren und dann das Verzeichnis zu kopieren. Das funktioniert in Einfachstumgebungen, aber wenn der MariaDB-Container währenddessen abstürzt, kann die Datei beschädigt sein. Sauberer ist es, den MySQL-Dump über den Container auszuführen, etwa mit:
docker exec db mysqldump --single-transaction -u nextcloud -p$DB_PASSWORD nextcloud > backup.sql
Der Parameter `–single-transaction` sorgt dafür, dass der Dump ein konsistentes Bild der Datenbank liefert, ohne sie für andere Reads zu sperren. Das ist für Nextcloud ausreichend, weil die meiste Zeit keine massiven Schreibzugriffe stattfinden. Für den Fall eines kompletten Systemausfalls hat man dann alle Daten praktisch beisammen: die Dateien aus dem Volume und die Strukturen aus dem Dump. Bei der Wiederherstellung muss man nur darauf achten, dass die beiden Teile zum selben Zeitpunkt gehören. Deshalb lohnt es sich, Wartungsmodus und Dump zwingend zu kombinieren.
Feintuning: Redis, Cron und Performance
Nextcloud ist eine mächtige Anwendung, aber sie fordert ihren Tribut. Ohne Caching wird die Oberfläche schnell zäh, und bei mehreren parallelen Nutzern kann die Datenbank zum Flaschenhals werden. Redis ist hier die Rettung. Redis übernimmt den Distributed Cache, die Datenbank für App-Zwischenspeicher und nicht zuletzt das Datei-Locking. Das verhindert, dass zwei Benutzer gleichzeitig dieselbe Datei bearbeiten und dabei Daten verlieren. In der Compose-Datei haben wir den Redis-Dienst bereits angelegt. Es fehlt nur noch die Konfiguration in der `config.php`, um Redis zu aktivieren:
'memcache.local' => '\\OC\\Memcache\\Redis', 'memcache.distributed' => '\\OC\\Memcache\\Redis', 'memcache.locking' => '\\OC\\Memcache\\Redis', 'redis' => [ 'host' => 'redis', 'port' => 6379, ],
Diese wenigen Zeilen haben eine enorme Wirkung. Sofort fühlt sich die Oberfläche flüssiger an, und die Anzahl der Datenbankabfragen sinkt spürbar. Es ist ein kleines Wunder, dass manche Anwender Nextcloud über Jahre ohne Redis betreiben und sich über die Langsamkeit wundern. Ein weiterer Performance-Faktor ist der Cron-Job. Nextcloud führt viele Aufgaben nicht sofort aus, sondern stellt sie in eine Warteschlange. Standardmäßig ist der sogenannte AJAX-Cron aktiviert, der nur dann läuft, wenn jemanddie Webseite besucht. Bei einem aktiven Cloud-Dienst führt das zu unregelmäßigen Verzögerungen, weil Hintergrundjobs wie Benachrichtigungen oder Scan-Aktivitäten auf den nächsten Besucher warten müssen. Der richtige Weg ist, für den Container einen eigenen Cron-Prozess zu starten.
In der Compose-Datei fügt man dazu einen weiteren Dienst hinzu, der dasselbe Image verwendet, aber mit einem anderen Einstiegspunkt läuft:
cron:
image: nextcloud:29-fpm
restart: unless-stopped
volumes:
- nextcloud_data:/var/www/html
entrypoint: ["cron", "-f"]
Dieser Dienst tut nichts anderes, als alle fünf Minuten die Datei `cron.php` aufzurufen. Dazu muss Nextcloud wissen, dass es den System-Cron verwenden soll. In der `config.php` trägt man ein:
'backgroundjobs_mode' => 'cron',
Wer dies einmal umgestellt hat, wird den Unterschied bemerken: Das Hochladen mehrerer Dateien läuft stabiler, und die Verzögerung bei E-Mail-Benachrichtigungen verschwindet.
Nicht zuletzt spielt die Wahl des Dateisystems eine Rolle für die Performance. Der Flaschenhals ist oft nicht der Container, sondern die zugrunde liegende Festplatte. Ein NFS-Mount ohne ausreichende Cache-Einstellungen kann ruckeln, ebenso eine VM mit langsamen virtuellen Platten. Docker selbst bringt hier keine Magie. Wer Nextcloud also über Docker betreibt, sollte sicherstellen, dass der Host genügend RAM hat und die Storage-Latenz niedrig ist. Die Datenbank möchte am liebsten auf schnellen NVMe-Platten arbeiten, während die Dateiablage auf mechanischen Festplatten toleriert wird. Diese Verteilung lässt sich in Docker sauber abbilden, indem man die Volumes auf unterschiedliche Host-Pfade legt.
Sicherheit: Mehr als nur HTTPS
Nextcloud ist eine sehr sichere Anwendung, wenn man sie richtig konfiguriert. Das gilt auch im Docker-Betrieb – aber es gibt ein paar Stolperfallen. Die erste lautet: ein Container ist kein Schutzschild. Er trennt Prozesse, aber er ermöglicht natürlich keinen direkten Zugriff auf Host-Ressourcen, wenn man ihn nicht absichtlich öffnet. Viele Administratoren setzen die umgebungsabhängigen Konstanten wie `TRUSTED_DOMAINS` nicht korrekt, sodass die Instanz auf jede IP-Adresse antwortet. Für einen kurzen Test ist das okay, für den produktiven Einsatz ist es ein Sicherheitsrisiko. Nextcloud selbst warnt dann im Administrationsbereich mit gelben Hinweisen, die man nicht ignorieren sollte. Eine saubere Konfiguration umfasst mindestens:
– Die `trusted_domains`-Liste in der `config.php`, in der nur der öffentliche Hostname und ggf. der interne Docker-Hostname stehen.
– HTTPS mit einem gültigen Zertifikat, egal ob über Let’s Encrypt oder einen anderen Anbieter.
– Einen Reverse Proxy, der nur die benötigten HTTP-Header durchlässt und keine Requests an den internen Container direkt weiterleitet.
– Regelmäßige Updates der Container-Images und des Betriebssystems.
Dabei zeigt sich, dass Docker nicht automatisch sicherer ist als eine klassische Installation. Man muss nur verhindern, dass der Container in ein unsicheres Netzwerk segmentiert wird. Ein alter Trick ist, den `–network host`-Modus zu verwenden, damit der Container die Netzwerkumgebung des Hosts teilt – das ist für Nextcloud nicht empfehlenswert, weil es den Betrieb von Web- und MySQL-Container unübersichtlich macht und die Isolation aufhebt.
Des Weiteren sollte man niemals die MySQL-Verbindungsparameter im Klartext in einem öffentlichen GitHub-Repo lesen. Das scheint trivial, aber es passiert erstaunlich oft. In der Docker-Welt arbeitet man am besten mit `.env`-Dateien, die nicht eingecheckt werden, und mit Geheimnissen, die der Container zur Laufzeit liest. Traefik und Docker Compose unterstützen das. Und noch etwas: Der nächste Punkt betrifft die Berechtigungen innerhalb des Volumes. Wenn der `www-data`-Benutzer nicht auf das Volume schreiben kann, erhält die Anwendung keine Backups, sie kann keine Apps aktualisieren und kein Caching betreiben. Umgekehrt sollte man es auch nicht übertreiben und dem Host-Benutzer `root` alle Dateien geben, denn dann laufen die Prozesse im Container mit Root-Rechten auf die gemounteten Dateien – das wäre unnötig. Der schmale Grat wird schnell zur täglichen Routine.
Nicht zu vergessen ist die Firewall des Hosts. Der Port von Nginx oder Apache sollte nur auf die IP des Reverse-Proxys zeigen, wenn man mehrere Server hat. Ist der Reverse Proxy auf demselben Host wie die Container, genügt es, den öffentlichen Port nach außen zu begrenzen. Docker selbst öffnet Ports standardmäßig auf allen Interfaces. Ein `iptables`-Regelsatz ist also trotz Docker nötig, wenn man nicht alles der Außenwelt präsentieren möchte.
Office-Integration: Collabora Online und OnlyOffice
Eine der großen Attraktionen von Nextcloud ist die Möglichkeit, Office-Dokumente im Browser zu bearbeiten. Diese Funktion wird nicht von Nextcloud selbst bereitgestellt, sondern von einer separaten Software, die über das WOPI-Protokoll angebunden wird. Die beiden bekanntesten Optionen sind Collabora Online und OnlyOffice. Beide lassen sich als Container in die bestehende Docker-Infrastruktur integrieren. Der Aufwand ist überschaubar, aber man sollte dennoch wissen, was passiert, wenn man sie nicht einrichtet: Ohne einen entsprechenden Server wird die Office-App in Nextcloud keine Bearbeitung anbieten.
Für Collabora Online genügt ein weiterer Dienst in der Compose-Datei. Das Image heißt `collabora/code` und benötigt die URL der Nextcloud-Instanz. Man startet es mit mehreren Umgebungsvariablen, unter anderem mit `username` und `password`, die für die Verbindung zu Nextcloud verwendet werden. In der Nextcloud-App muss man dann die entsprechende URL angeben, etwa `https://collabora.example.com`. Die Konfiguration ist in der Regel in wenigen Minuten erledigt. OnlyOffice bietet ein ähnliches Setup, hat aber den Vorteil, dass es etwas weniger Ressourcen verbraucht. Vielen Anwendern genügt ein schlanker Container mit 2 GB RAM, um Dokumente komfortabel zu bearbeiten. Wer viele gleichzeitige Nutzer hat, sollte die Ressourcen entsprechend erhöhen.
Interessant ist, dass diese Office-Container nicht unbedingt öffentlich erreichbar sein müssen. Nextcloud spricht mit ihnen über das Docker-Netzwerk, idealerweise ohne zusätzlichen Reverse Proxy. In der Compose-Datei kann man einfach den internen Port angeben, wenn man die beiden Container im selben Netzwerk betreibt. Das erhöht die Sicherheit und spart die Domain-Konfiguration. Man muss nur sicherstellen, dass die WOPI-Verbindung von Nextcloud aus den Service-Namen auflösen kann. Die genaue Konfiguration hängt von der verwendeten Office-Suite und der Nextcloud-Version ab. In den meisten Fällen findet man auf den offiziellen Dokumentationsseiten eine gerade aktuelle Docker-Compose-Vorlage.
Ein Wort zur Vorsicht: Office-Dienste sind komplex und brauchen regelmäßige Updates. Wenn man Nextcloud aktualisiert, sollte man auch Collabora oder OnlyOffice mitziehen. Nicht selten hängt die Office-Funktion an einer bestimmten Version dieser Dienste, und ein Versionssprung von Nextcloud kann dazu führen, dass das WOPI-Protokoll nicht mehr reagiert. Das ist kein Grund, auf die Funktion zu verzichten – aber man sollte sich bewusst sein, dass die Kombination mehr Fehlerquellen bietet als eine reine Dateiablage.
Der Umzug von einer klassischen Installation
Viele, die heute mit Docker liebäugeln, betreiben bereits eine Nextcloud auf einem herkömmlichen Webserver. Der Umzug ist kein Hexenwerk, aber er erfordert ein wenig Planung. Man muss die Dateien aus dem alten `data`-Verzeichnis, die `config.php` und die Datenbank in die neue Docker-Umgebung übertragen. Die einfachste Methode ist, das alte Verzeichnis in das Volume des neuen Containers zu kopieren und dann die Datenbank aus einem Dump zu importieren. Anschließend führt man die schon erwähnten `occ`-Befehle aus, um den Cache zu leeren und die Datenbank auf den neuen Stand zu bringen.
Ein häufiger Fehler ist, dass in der alten `config.php` noch lokale Pfade wie `/var/www/nextcloud` stehen. Diese müssen auf den neuen Container-Pfad `/var/www/html` angepasst werden. Zudem sind die `trusted_domains` wahrscheinlich auf die alte Domain eingestellt. Nach dem Umzug gilt: Erst die neue Installations-URL eintragen, dann die alte entfernen. Sonst wartet man nach jedem Aufruf auf eine Fehlermeldung, dass die Domain nicht erlaubt ist. Der Umzug ist ein guter Zeitpunkt, um auch die Docker-Volumes sauber zu benennen und in eine Backup-Strategie zu integrieren. Einmal richtig aufgesetzt, ist das System danach deutlich weniger bewartungsintensiv als die alte Installation.
Dennoch sollte man sich nicht der Illusion hingeben, Docker erzwinge automatisch saubere Strukturen. Was man beim Umzug vorfindet, ist häufig ein Sammelsurium an alten Verzeichnissen und Konfigurationsdateien. Wer sowieso einen Tapetenwechsel plant, kann mutig alle Daten auf das Volume legen und die Datenbank mit einem frischen Schema neu aufbauen. Das funktioniert, wenn die Benutzerdaten in `data` erhalten bleiben. Die Kalender, Kontakte und Freigaben sind in der Datenbank gespeichert – die werden dann über einen Dump übertragen. Man sollte ein Nachmittag einplanen, aber man wird mit einem aufgeräumten System belohnt.
Wenn es hakt: Troubleshooting in der Containerwelt
Keine Software läuft fehlerfrei, und Nextcloud in Docker hat seine Eigenheiten. Die häufigsten Probleme sind Verbindungsabbrüche zwischen Containern, falsche Persistenz und Berechtigungsprobleme. Eines der ersten Anzeichen ist ein `502 Bad Gateway` im Browser. Dann ist der Webserver-Container erreichbar, aber der FPM-Container findet nicht. Mögliche Ursachen sind ein falsch konfiguriertes Datei-Mounting oder ein unterbrochenes Netzwerk. Ein Blick in die Logs hilft: `docker compose logs web` und `docker compose logs app` zeigen dir, ob der PHP-FPM-Prozess überhaupt läuft und ob es Fehler in der Konfigurationsdatei gibt.
Ein anderes typisches Problem ist die Fehlermeldung `PHP Fatal error: Uncaught Exception: Memcache \OC\Memcache\Redis not available`. Das bedeutet nicht unbedingt, dass Redis nicht läuft. Oft ist es ein falscher Hostname in der `config.php`, weil der Hostname des Containers nicht mit dem Dienstnamen übereinstimmt. In unserem Compose-Setup heißt der Redis-Dienst einfach `redis`. In der Konfiguration muss also auch `host => ‚redis’` stehen, nicht `localhost`. Solche Fehler sind charakteristisch für die Container-Orchestrierung: Dienste haben hier keine IP-Adresse wie in klassischen Setups, sondern funktionieren über DNS-Namen, die Docker Compose automatisch vergibt. Wer sich damit abfindet, wird in kurzer Zeit sattelfest.
Neben diesen technischen Fallstricken gibt es auch welche, die in der Anwendung selbst liegen. Wenn Nextcloud nach einem Update eine leere weiße Seite zeigt, kann das an einer veralteten App liegen. Eine Möglichkeit, schnell wieder Kontrolle zu bekommen, ist der auf die `occ`-Kommandozeile. Man kann über `docker exec -u www-data app php occ list` alle verfügbaren Befehle abrufen. Damit lässt sich auch der Wartungsmodus deaktivieren, Apps deinstallieren und Datenbankindizes reparieren. Diese Kommandozeilenzugriff ist eine der großen Stärken von Nextcloud. In Docker ist er sogar einfacher, denn man muss nicht erst einen SSH-Zugang zum Server wählen – solange der Container läuft, hat man sofort ein Terminal.
Ein weiteres häufiges Thema ist das Überschreiben der `config.php` durch das Image. Während das Image bei jedem Start die Datei liest und Werte wie `trusted_domains` übernimmt, muss man aufpassen, wenn man eigene Änderungen einträgt. Der sauberste Weg ist, die Datei im Volume zu bearbeiten, nachdem der Container gestoppt wurde. Alternativ kann man die Konfiguration über die Admin-Oberfläche ändern, aber einige Werte sind dort nicht sichtbar. In Docker-Setups hält man am besten alle Änderungen in einer `config/.env`-Datei oder direkt in der Compose-Datei fest, damit man beim Update nichts vergisst.
Monitoring: Die Cloud im Blick behalten
Eine Nextcloud-Instanz ist kein Selbstläufer, auch nicht mit Docker. Es ist sinnvoll, sich zu überlegen, wie man die Gesundheit der Container überwacht. Der einfachste Schritt ist ein Healthcheck in der Compose-Datei. Das offizielle Nextcloud-Image bietet bereits einen Healthcheck an, aber man kann auch selbst einen definieren. Ein Docker-Healthcheck führt regelmäßig einen Befehl im Container aus und meldet dessen Status an den Host. So kann man frühzeitig erkennen, ob der Container ewig lädt oder ob die Datenbank kontinuierlich Fehler produziert.
Darüber hinaus empfiehlt es sich, die Logs zu zentralisieren. Dazu eignet sich eine Lösung wie Dokku, ein ELK-Stack oder einfach ein weiteres Container-Werkzeug, das die Logs nach kritischen Mustern durchsucht. Nextcloud selbst schreibt Fehler in eine Logdatei, die im Volume liegt. Weit nützlicher ist es jedoch, die Docker-Logs auszuwerten, da dort auch Nginx-Fehler und PHP-Warnungen auftauchen. Wer das nicht manuell machen möchte, kann einen Dienst wie Prometheus und Grafana einsetzen, um Metriken wie CPU, RAM und Netzwerk zu visualisieren. Einfacher geht es mit dem Kommando `docker stats`, das den Ressourcenverbrauch aller Container in Echtzeit zeigt. Das ist zwar nicht für das Monitoring über Wochen geeignet, gibt aber einen ersten Eindruck davon, ob der RAM für Collabora ausreicht oder ob die Datenbank ständig unter Last stöhnt.
Ein oft übersehener Punkt ist der Speicherplatz. Nextcloud protokolliert bei zu wenig Speicher keine Warnung, bis es zu spät ist. Deshalb solltest du das Host-Dateisystem im Blick behalten, insbesondere das Volume, in dem die `data`-Ordner liegen. Wenn es voll läuft, können nicht nur Uploads fehlschlagen, sondern auch Datenbanktransaktionen abbrechen. Ein simples Skript, das den freien Platz prüft und eine Benachrichtigung sendet, ist in der Regel das Erste, was man in einem Produktivbetrieb einrichtet. Es ist weniger spektakulär als eine Kubernetes-Orchestrierung, aber es rettet einem den Abend.
Ein Blick in die Zukunft: Was kommt nach Docker?
Docker hat sich als Standard etabliert, aber die Container-Orchestrierung geht weiter. Wer heute Nextcloud betreibt, wird sich früher oder später fragen, ob man die eigene Cloud nicht auch mit Podman, Kubernetes oder einer Docker-Swarm-Umgebung verwalten kann. Podman ist dazu gedacht, als daemonalternative ohne zentralen Daemon zu arbeiten. Es ist weitgehend kompatibel zu Docker auf CLI-Ebene, und viele Compose-Dateien laufen einfach weiter. In einer Welt, in der man Wert auf Sicherheit legt, ist Podman eine echte Alternative, weil die Container ohne Root-Rechte auskommen können.
Kubernetes hingegen ist für die meisten Nextcloud-Installationen schlicht überdimensioniert. Die Komplexität, einen StatefulSet-Controller mit PVCs und Ingresses zu konfigurieren, lohnt sich nur, wenn man bereits eine einheitliche Kubernetes-Plattform betreibt und alle Anwendungen dort laufen. Nextcloud ist dabei ein unangenehmer Kandidat, weil sie viele optimierte Speicherpfade braucht. Man kann es zum Laufen bringen, aber man verliert den Vorteil der Einfachheit, den Docker Compose bietet. Für Unternehmen mit einem starken Kubernetes-Team kann das dennoch die richtige Wahl sein – dann wird Nextcloud zu einem Managed Service im eigenen Cluster. Aber das ist ein anderes Thema.
Für den Großteil der Administratoren bleibt Docker Compose die vernünftigste Lösung. Man bekommt die Vorteile der Containerisierung, ohne sich in ein zu großes Architekturprojekt zu verlieren. Die Compose-Datei ist im Grunde das gesamte Deployment, dokumentiert als Code. Das erleichtert nicht nur das eigene Leben, sondern auch das im Team, wenn man die Datei an Kolleginnen und Kollegen übergibt. Ein kurzer Blick auf den Dienstnamen `app` und die Volumes sagt mehr als jede 50-seitige Installationsanleitung.
Fazit: Ein Werkzeug, kein Allheilmittel
Nextcloud mit Docker zu betreiben, ist eine überzeugende Methode, um eine selbstgehostete Cloud aufzubauen. Sie spart Einrichtungszeit, erleichtert Updates und bietet eine saubere Trennung der Dienste. Doch die Technik ersetzt nicht das Verständnis für die zugrunde liegenden Systeme. Wer sich nicht mit Volumes, Netzwerken und Umgebungsvariablen auseinandersetzt, tauscht die alten Probleme gegen neue. Das ist kein Grund, Docker zu meiden, sondern ein Argument, sich die Konzepte gründlich anzueignen. Die Mühe wird belohnt mit einer Infrastruktur, die sich reproduzieren lässt, auf einen anderen Server umzieht und mit überschaubarem Aufwand betrieben werden kann. Nextcloud ist kein Ersatz für die großen kommerziellen Clouds, aber sie gibt einem etwas Entscheidendes zurück: die Kontrolle über die eigenen Daten. Und Docker hilft dabei, diese Kontrolle zu behalten – wenn man bereit ist, die Werkzeuge zu verstehen.