Wer seine Daten nicht ständig bei irgendwelchen US-Diensten parken will, landet früher oder später bei der gleichen Frage: Warum eigentlich nicht eine eigene Cloud betreiben?
Die Vorteile liegen ziemlich klar auf der Hand. Eine selbst gehostete Cloud bringt mehr Kontrolle über die eigenen Daten, mehr Datenschutz, weniger Abhängigkeit von großen Plattformen und oft auch ein deutlich besseres Gefühl im Alltag. Dazu kommt: Wenn dann noch eine Office-Lösung direkt integriert ist, wird aus einem simplen Dateispeicher schnell eine vollwertige Arbeitsumgebung. Dokumente im Browser öffnen, gemeinsam bearbeiten, Dateien zentral ablegen, Kalender und Kontakte verwalten — alles an einem Ort, ohne den üblichen Fremdzugriff durch Dritte.
Klingt gut. Ist es auch. Aber ganz ohne Stolperfallen läuft so ein Setup natürlich nicht.
Ausgangslage
Die Basis war eine sauber laufende selbst gehostete Cloud in Docker. Dateien, Datenbank, Redis, Reverse Proxy — alles funktionierte. Der nächste logische Schritt war die Office-Integration, damit sich Dokumente direkt im Browser öffnen und bearbeiten lassen.
Also wurde die passende Office-App in der Cloud installiert. Soweit erstmal unspektakulär.
Das Problem zeigte sich direkt beim ersten Test: Dokument anklicken, Ladebildschirm, und dann… nichts. Das Dokument lud einfach endlos. Kein sauberer Fehler, kein brauchbarer Hinweis im Frontend, nur Stillstand.
Genau diese Art Fehler ist nervig. Nicht komplett kaputt, aber eben auch nicht nutzbar.
Der erste Irrtum: Die Office-App allein reicht nicht
An der Stelle kommt man schnell auf den falschen Gedanken, dass mit der Installation der Office-App schon alles erledigt sei.
Ist es nicht.
Die App in der Cloud ist im Grunde nur die Integration. Damit Dokumente tatsächlich geöffnet werden können, braucht es zusätzlich einen Office-Dienst im Hintergrund. In vielen Setups ist das entweder der eingebaute CODE-Server oder ein separater Collabora-Container.
Die App allein macht also noch keine Office-Umgebung. Sie liefert nur die Verbindung dorthin.
Erst Built-in CODE probiert
Der erste Versuch lief über den eingebauten CODE-Server. Auf dem Papier klingt das praktisch: schnell aktiviert, direkt in die Oberfläche integriert, kein zusätzlicher externer Office-Container nötig.
In der Praxis war das bei diesem Setup aber genau der Teil, der Ärger gemacht hat.
Die Oberfläche meldete zwar sinngemäß, dass der Office-Server erreichbar sei, trotzdem luden Dokumente weiter endlos. Die Logs waren deutlich ehrlicher als die GUI. Dort tauchten unter anderem Meldungen auf, die ziemlich klar gezeigt haben, dass der eingebaute Dienst nicht sauber hochkommt.
Heißt unterm Strich: Die Grundkommunikation war nicht komplett tot, aber stabil oder vollständig funktionsfähig war das Ganze eben auch nicht.
Dann die üblichen Verdächtigen geprüft
Wie immer bei solchen Themen landet man schnell bei den klassischen Problemstellen:
- Reverse Proxy
- interne Erreichbarkeit
- WOPI-Konfiguration
- Container-Netze
- Trusted Proxies
- saubere Hostnamen und HTTPS-Weitergabe
Gerade wenn die Cloud in Docker läuft, ist es wichtig zu verstehen, aus welchem Netz welcher Dienst eigentlich kommt. Sonst trägt man fröhlich IPs ein, die am Problem komplett vorbeigehen.
Die Analyse des Docker-Netzwerks zeigte dann auch sauber, welche Container in welchem Netz hängen und welche internen Adressen tatsächlich relevant sind. Das war wichtig, um die Konfiguration besser einzuordnen und nicht weiter im Blindflug zu arbeiten.
Der eigentliche Wendepunkt: externer Collabora-Container
Irgendwann muss man ehrlich sein: Wenn der eingebaute Dienst zickt, bringt es wenig, ihn stundenlang schönreden zu wollen.
Also wurde der pragmatische Weg gewählt: kein Built-in CODE mehr, sondern ein separater Collabora-Container hinter dem bestehenden Reverse Proxy. Eigene Subdomain, sauber per HTTPS angebunden, klar getrennte Zuständigkeiten.
Und genau das war am Ende die richtige Entscheidung.
Nach dem Umstellen auf einen separaten Office-Container funktionierte das Öffnen von Dokumenten sofort sauber. Keine Endlosschleife mehr, kein Hängenbleiben, kein Herumgeeiere. Einfach Dokument anklicken und loslegen — so wie es sein soll.
Warum der separate Container die bessere Lösung war
Der Unterschied ist schnell erklärt.
Ein externer Collabora-Container ist in so einem Docker-Setup meist deutlich robuster, weil:
- der Office-Dienst klar getrennt läuft
- Reverse-Proxy-Regeln sauber und transparent bleiben
- Fehler einfacher zu lokalisieren sind
- das Ganze langfristig wartbarer ist
- man nicht von Eigenheiten des eingebauten Dienstes abhängig ist
Kurz gesagt: weniger Magie, mehr Kontrolle.
Und genau das ist bei Selfhosting meistens der bessere Weg.
Nebenbei noch ein Konfigurationsdetail bereinigt
Im Zuge der Fehlersuche fiel noch ein kleiner, aber typischer Konfigurationsfehler auf: die Definition der Trusted Proxies war zwar nicht komplett kaputt, aber unsauber formuliert.
Das war nicht die Hauptursache für das Office-Problem, sollte aber trotzdem korrigiert werden. Solche Dinge rächen sich gern später an anderer Stelle — etwa bei Weiterleitungen, HTTPS-Erkennung oder Client-IP-Auswertung.
Auch da zeigt sich wieder: Wenn man ohnehin schon dran ist, lieber gleich sauber machen statt halbgar stehenlassen.
Das Ergebnis
Am Ende steht jetzt eine eigene Cloud-Umgebung mit integrierter Office-Funktion, die genau das tut, was sie soll:
- Dateien zentral speichern
- Dokumente direkt im Browser öffnen
- Office-Dateien bearbeiten
- Daten unter eigener Kontrolle behalten
- unabhängig von den üblichen Großplattformen arbeiten
Und genau darum lohnt sich der Aufwand.
Klar, man muss sich mit Docker, Reverse Proxy, Netzwerken und Konfiguration beschäftigen. Geschenkt gibt es das nicht. Aber wenn es einmal sauber steht, hat man eine Lösung, die nicht nur funktioniert, sondern auch wirklich einem selbst gehört.
Fazit
Eine eigene Cloud mit Office-Integration ist kein Spielzeug mehr, sondern eine ernstzunehmende Alternative zu kommerziellen Diensten. Wer Wert auf Datenschutz, Kontrolle und technische Unabhängigkeit legt, bekommt damit ein starkes Gesamtpaket.
Die wichtigste Erkenntnis aus diesem Aufbau war dabei ziemlich simpel:
Nicht jede „eingebaute“ Komfortlösung ist automatisch die beste. Manchmal ist der direkte, sauber getrennte Weg schlicht der bessere. In diesem Fall hieß das: Built-in CODE raus, externer Collabora-Container rein — und plötzlich lief das System so, wie es von Anfang an hätte laufen sollen.
Interessanter Links: