OpenCloud installieren – ganz einfach auf dem eigenen Server

Sie möchten OpenCloud produktiv betreiben – mit eigener Domain, gültigen TLS-Zertifikaten und Weboffice? In diesem Artikel erfahren Sie Schritt für Schritt, wie Sie OpenCloud auf einem bestehenden Server einrichten und nahtlos in Ihre Infrastruktur integrieren.

Wie unser Handbuch beschreibt, lässt sich OpenCloud in ganz unterschiedlichen Szenarien einsetzen – vom lokalen Testsystem bis hin zum vollwertigen Cloud-Dienst mit Weboffice, Nutzerverwaltung und E-Mail-Anbindung. In diesem Artikel zeigen wir den Weg zur produktiven Bereitstellung: auf einem realen Server mit öffentlicher Domain, gültigen TLS-Zertifikaten und bestehenden Diensten wie etwa Apache.

Die Besonderheit: Wir installieren OpenCloud nicht auf der sprichwörtlichen „grünen Wiese“, sondern integrieren es in eine bereits laufende Umgebung mit Ubuntu 24.04 LTS – ohne andere Dienste zu stören. Unser Ziel: ein sicheres, containerbasiertes Setup mit Apache als Reverse Proxy, Docker Compose und allem, was für einen stabilen Produktivbetrieb dazugehört.

Voraussetzungen für den eigenen OpenCloud-Server

Damit Sie OpenCloud auf einem eigenen Server betreiben können, sind einige grundlegende Voraussetzungen nötig. Am besten eignet sich ein Root-Server oder vServer mit einer Linux-Distribution Ihrer Wahl. Wichtig ist dabei, dass Sie über vollständigen administrativen Zugriff verfügen, denn einige der Schritte erfordern root-Rechte.

Für den produktiven Betrieb sollten Sie außerdem folgende Punkte vorbereiten:

• Eigene Domain mit passenden Subdomains wie cloud., collabora. und wopiserver., die auf die IP-Adresse Ihres Servers zeigen.
• TLS-Zertifikate, idealerweise von Let’s Encrypt, um die Dienste per HTTPS abzusichern.
• Docker und Docker Compose, da OpenCloud containerbasiert betrieben wird (mehr dazu im Abschnitt „Docker installieren: Die Grundlage für OpenCloud“).
• Apache oder ein anderer Webserver, der als Reverse Proxy zwischen Internet und Containern vermittelt.

In unserem Beispiel haben wir OpenCloud auf einem Root-Server mit Ubuntu 24.04 LTS installiert. Ein Apache-Webserver war bereits eingerichtet und belegte die Ports 80 und 443 – daher haben wir auf Traefik verzichtet. Stattdessen nutzen wir Apache als Reverse Proxy für die OpenCloud-Dienste.

Folgende Subdomains wurden in der DNS-Zone konfiguriert und zeigen auf die Server-IP:

• blog.opencloud.rocks
• cloud.blog.opencloud.rocks
• collabora.blog.opencloud.rocks
• wopiserver.blog.opencloud.rocks

Ein gültiges Zertifikat für blog.opencloud.rocks war bereits vorhanden. Damit auch die Subdomains sicher erreichbar sind, haben wir vorab gültige TLS-Zertifikate für diese erstellt.

TLS-Zertifikate für OpenCloud-Subdomains erstellen

Damit Sie OpenCloud später über HTTPS nutzen können, brauchen alle benötigten Subdomains gültige TLS-Zertifikate. Da Apache als Reverse Proxy fungiert und die TLS-Terminierung übernimmt, kommt hier kein integrierter Proxy wie Traefik zum Einsatz.

Am einfachsten funktioniert die Zertifikatserstellung mit Let’s Encrypt. Für den Einsatz von certbot – dem offiziellen Client für Let’s Encrypt – muss Apache die Subdomains bereits bedienen können. Das eigentliche Ziel, etwa OpenCloud oder Collabora, spielt in diesem Moment noch keine Rolle. Entscheidend ist, dass Apache die Domain korrekt verarbeitet und auf HTTP-Anfragen antwortet. Dazu richten Sie Platzhalter-VirtualHosts ein, die einfache statische HTML-Seiten ausliefern.

Für jede Subdomain – in unserem Fall cloud.blog.opencloud.rocks, collabora.blog.opencloud.rocks und wopiserver.blog.opencloud.rocks – gibt es eine eigene Konfigurationsdatei in /etc/apache2/sites-available/. Ein VirtualHost für cloud.blog.opencloud.rocks könnte zum Beispiel so aussehen:

<VirtualHost *:80>
    ServerName cloud.blog.opencloud.rocks
    DocumentRoot /var/www/placeholder-cloud

    <Directory /var/www/placeholder-cloud>
        Options -Indexes
        AllowOverride None
        Require all granted
    </Directory>

    ErrorLog ${APACHE_LOG_DIR}/cloud_error.log
    CustomLog ${APACHE_LOG_DIR}/cloud_access.log combined
</VirtualHost>

Damit Apache auf Anfragen reagiert, legen Sie das zugehörige Verzeichnis an und erstellen eine einfache Platzhalterseite:

sudo mkdir -p /var/www/placeholder-cloud
echo "OpenCloud-Vorbereitung" | sudo tee /var/www/placeholder-cloud/index.html

Im Anschluss aktivieren Sie die Site und laden die Konfiguration neu:

sudo a2ensite cloud.blog.opencloud.rocks.conf
sudo systemctl reload apache2

Für collabora.blog.opencloud.rocks und wopiserver.blog.opencloud.rocks gehen Sie genauso vor – jeweils mit einem eigenen Verzeichnis (zum Beispiel /var/www/placeholder-collabora und /var/www/placeholder-wopiserver) und einer passenden VHost-Konfiguration.

Sind alle drei Subdomains erreichbar, fordern Sie mit certbot ein gemeinsames TLS-Zertifikat an:

sudo certbot --apache \
  -d cloud.blog.opencloud.rocks \
  -d collabora.blog.opencloud.rocks \
  -d wopiserver.blog.opencloud.rocks

certbot erkennt die bestehenden VHosts automatisch, führt die HTTP-01-Challenge durch und erweitert die Apache-Konfiguration um die nötigen TLS-Einstellungen. Für die Subdomains fordert certbot ein gemeinsames SAN-Zertifikat (Subject Alternative Names) an, das alle drei Subdomains abdeckt. Die erzeugten Zertifikate finden Sie anschließend im Verzeichnis /etc/letsencrypt/live/<domain>/; sie werden künftig automatisch verlängert.

Apache als Reverse Proxy einrichten

Sobald die TLS-Zertifikate eingerichtet sind, können Sie Apache so konfigurieren, dass HTTPS-Anfragen an die richtigen Dienste in Ihrem Docker-Setup weitergeleitet werden. Dazu ersetzen Sie die bisherigen Platzhalter-VHosts durch produktive Konfigurationen mit aktiviertem Reverse Proxy.

Jede Subdomain leitet dabei Anfragen an einen internen Docker-Dienst weiter – OpenCloud, den WOPI-Server oder Collabora. Apache übernimmt die TLS-Terminierung und reicht die Anfrage intern über HTTP oder WebSockets an den richtigen Container weiter.

Beispiel: OpenCloud (Port 9200) per cloud.blog.opencloud.rocks bereitstellen

<IfModule mod_ssl.c>
<VirtualHost *:443>
    ServerName cloud.blog.opencloud.rocks

    SSLEngine on
    SSLCertificateFile /etc/letsencrypt/live/cloud.blog.opencloud.rocks/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/cloud.blog.opencloud.rocks/privkey.pem

    ProxyPreserveHost On
    ProxyPass / http://127.0.0.1:9200/
    ProxyPassReverse / http://127.0.0.1:9200/

    ErrorLog ${APACHE_LOG_DIR}/cloud_error.log
    CustomLog ${APACHE_LOG_DIR}/cloud_access.log combined
</VirtualHost>
</IfModule>

Beispiel: WOPI-Server (Port 9300) per wopiserver.blog.opencloud.rocks anbinden

<IfModule mod_ssl.c>
<VirtualHost *:443>
    ServerName wopiserver.blog.opencloud.rocks

    SSLEngine on
    SSLCertificateFile /etc/letsencrypt/live/cloud.blog.opencloud.rocks/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/cloud.blog.opencloud.rocks/privkey.pem

    ProxyPreserveHost On
    ProxyPass / http://127.0.0.1:9300/
    ProxyPassReverse / http://127.0.0.1:9300/

    ErrorLog ${APACHE_LOG_DIR}/wopi_error.log
    CustomLog ${APACHE_LOG_DIR}/wopi_access.log combined
</VirtualHost>
</IfModule>

Collabora (Port 9980): WebSockets, Header und viele Stolperfallen

Besonderes Augenmerk verdient die Konfiguration für Collabora. Damit die Integration zuverlässig funktioniert – besonders die Office-Vorschau und -Bearbeitung – müssen Sie einige zusätzliche Regeln beachten. Die Herausforderung: Neben klassischen HTTP-Aufrufen nutzt Collabora auch WebSockets, und die müssen explizit durchgereicht werden. So sieht eine funktionierende Konfiguration für collabora.blog.opencloud.rocks aus:

<IfModule mod_ssl.c>
<VirtualHost *:443>
    ServerName collabora.blog.opencloud.rocks

    SSLEngine on
    SSLCertificateFile /etc/letsencrypt/live/cloud.blog.opencloud.rocks/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/cloud.blog.opencloud.rocks/privkey.pem

    ProxyPreserveHost On
    AllowEncodedSlashes NoDecode

    # WebSockets
    ProxyPassMatch "/cool/(.*)/ws$" ws://127.0.0.1:9980/cool/$1/ws nocanon
    ProxyPassMatch "^/cool/adminws$" ws://127.0.0.1:9980/cool/adminws

    # Standardpfade
    ProxyPass /cool http://127.0.0.1:9980/cool
    ProxyPassReverse /cool http://127.0.0.1:9980/cool
    ProxyPass /hosting/discovery http://127.0.0.1:9980/hosting/discovery
    ProxyPassReverse /hosting/discovery http://127.0.0.1:9980/hosting/discovery
    ProxyPass /browser http://127.0.0.1:9980/browser
    ProxyPassReverse /browser http://127.0.0.1:9980/browser

    # Wichtiger Header für HTTPS-Verbindung
    RequestHeader set X-Forwarded-Proto "https"

    # Zeitlimits erhöhen
    ProxyTimeout 300
    ProxyIOBufferSize 65536

    ErrorLog ${APACHE_LOG_DIR}/collabora_error.log
    CustomLog ${APACHE_LOG_DIR}/collabora_access.log combined
</VirtualHost>
</IfModule>

Apache-Module aktivieren

Damit das funktioniert, müssen auf dem System auch die nötigen Apache-Module aktiviert sein: 

$ sudo a2enmod proxy proxy_http ssl headers proxy_connect proxy_wstunnel
[…]
$ systemctl restart apache2

Hinweis: Die zuvor eingerichteten Platzhalter-VHosts (z. B. cloud.blog.opencloud.rocks.conf) dienen ausschließlich dazu, die TLS-Zertifikate mit certbot zu erzeugen. Ändern Sie diese Dateien nicht nachträglich zur produktiven Nutzung! Stattdessen legen Sie eigene Konfigurationsdateien für die HTTPS-VirtualHosts an, die Apache später als Reverse Proxy nutzt. Sobald diese neuen Konfigurationen aktiv sind, können die Platzhalter-VHosts gefahrlos deaktiviert und gelöscht werden.

Platzhalter-VHosts jetzt deaktivieren

Für die TLS-Zertifikate hatten Sie zuvor einfache Platzhalter-VHosts eingerichtet – jeweils eine Konfiguration pro Subdomain, die lediglich eine statische HTML-Seite ausgeliefert hat. Diese Platzhalter waren notwendig, damit certbot die Domains verifizieren und ein gültiges Zertifikat von Let’s Encrypt ausstellen konnte.

Jetzt, da Apache produktiv als Reverse Proxy arbeitet und die neuen VHosts aktiv sind, können Sie die alten Konfigurationen entfernen. Andernfalls würde Apache versuchen, mehrere VHosts für dieselbe Subdomain zu laden – das führt zu Fehlermeldungen beim Neustart des Webservers.

So deaktivieren Sie die überflüssigen Platzhalter-Sites:

sudo a2dissite cloud.blog.opencloud.rocks.conf
sudo a2dissite collabora.blog.opencloud.rocks.conf
sudo a2dissite wopiserver.blog.opencloud.rocks.conf

Anschließend laden Sie Apache neu:

systemctl restart apache2

Damit ist der Weg frei für das eigentliche OpenCloud-System – erreichbar über die eingerichteten Subdomains mit gültigem TLS-Zertifikat und sicherem Proxy-Zugriff.

Docker installieren: Die Grundlage für OpenCloud

Bevor Sie OpenCloud auf Ihrem Server starten können, sollten ein paar Voraussetzungen erfüllt sein: Docker und Docker Compose (Version 2) müssen installiert sein, Ihre Domain muss auf den Server zeigen, und Sie sollten sich grundsätzlich mit dem Konzept von Docker Compose auskennen. Klingt kompliziert? Ist es nicht – und Sie müssen auch kein Profi sein, um loszulegen.

Besonders wichtig: Achten Sie unbedingt darauf, Docker Compose in Version 2 zu verwenden. In einigen Linux-Distributionen – etwa Debian 12 „Bookworm“ – ist in den Standardpaketen noch die veraltete Version 1 enthalten. Damit funktioniert OpenCloud nicht zuverlässig.

Die sicherste Methode: Installieren Sie Docker direkt nach der offiziellen Anleitung. Damit stellen Sie sicher, dass alle Komponenten aktuell sind – einschließlich docker compose, das später alle Dienste gemeinsam startet und verwaltet. Ob Docker korrekt eingerichtet ist, prüfen Sie einfach mit diesem Befehl:

sudo docker run hello-world

 
Tipp: Wenn Sie möchten, dass Ihr normaler Benutzer Docker-Befehle ohne sudo ausführen darf, fügen Sie ihn zur Docker-Gruppe hinzu:

sudo usermod -aG docker $USER

Nach dem nächsten Login ist die Änderung aktiv – und Ihrem OpenCloud-Setup steht nichts mehr im Weg.

OpenCloud vorbereiten: Repository klonen und Konfiguration einrichten

Damit Ihr OpenCloud-Setup reibungslos startet, klonen Sie im ersten Schritt das offizielle Compose-Repository und passen anschließend die Konfiguration an Ihre Umgebung an.

Wechseln Sie in ein geeignetes Verzeichnis und führen Sie folgende Befehle aus:

git clone https://github.com/opencloud-eu/opencloud-compose.git
cd opencloud-compose

Erstellen Sie nun auf Basis der mitgelieferten Vorlage Ihre persönliche Umgebungsdatei:

cp .env.example .env

Öffnen Sie die Datei .env mit einem Texteditor und tragen Sie dort die folgenden Parameter ein:

# Domain, unter der OpenCloud später erreichbar sein soll
OC_DOMAIN=cloud.blog.opencloud.rocks

# Admin-Passwort für den ersten Login (Benutzername: admin)
INITIAL_ADMIN_PASSWORD=<top-secret>

# Subdomains für Weboffice und WOPI-Dienst
COLLABORA_DOMAIN=collabora.blog.opencloud.rocks
WOPISERVER_DOMAIN=wopiserver.blog.opencloud.rocks

Tipp: Zum Generieren eines sicheren Passwortes können Sie das Tool pwgen auf der Kommandozeile verwenden:

$ pwgen -cny 12 1
aij)aeSh8mai

Die Optionen -cny sorgen dafür, dass das generierte Passwort mindestens einen Großbuchstaben (-c), eine Zahl (-n) und ein Sonderzeichen (-y) enthält.

Dienste auswählen: Welche OpenCloud-Komponenten sollen starten?

OpenCloud setzt auf Docker Compose – und erlaubt es Ihnen, gezielt auszuwählen, welche Komponenten Sie wirklich benötigen. Die zentrale Variable in der .env-Datei dafür heißt COMPOSE_FILE. Sie legt fest, welche Dienste beim Start von Docker Compose berücksichtigt werden.

Für das Setup mit Apache als Reverse Proxy und der Online-Bearbeitung von Dokumenten mit Collabora tragen Sie Folgendes ein:

COMPOSE_FILE=docker-compose.yml:weboffice/collabora.yml:external-proxy/opencloud.yml:external-proxy/collabora.yml

Diese Auswahl startet:

• OpenCloud: die zentrale Plattform
• Collabora Online: für die Bearbeitung von Office-Dokumenten direkt im Browser
• Apache-spezifische Proxy-Konfigurationen: damit OpenCloud und Collabora sauber hinter Ihrem Reverse Proxy laufen

Damit ist Ihr Setup vollständig vorbereitet: Sie kombinieren volle Kontrolle über TLS und Routing mit der vollen Funktionalität von OpenCloud. Im nächsten Schritt starten Sie die Container – und melden sich zum ersten Mal an.

OpenCloud starten: Container hochfahren und prüfen

Jetzt wird’s konkret: Sie haben die .env-Datei eingerichtet, Apache als Reverse Proxy vorbereitet und alle gewünschten Dienste über COMPOSE_FILE ausgewählt. Nun ist es an der Zeit, OpenCloud zu starten.

Zuerst laden Sie alle benötigten Container-Images herunter:

docker compose pull

Dieser Befehl sorgt dafür, dass Docker alle Images für Ihr Setup lokal bereithält – darunter OpenCloud selbst, Collabora für die Bearbeitung von Office-Dokumenten und die zugehörigen Datenbanken.

Anschließend starten Sie alle konfigurierten Dienste im Hintergrund:

docker compose up -d

Das -d steht für „detached mode“: Die Container laufen im Hintergrund weiter – auch wenn Sie das Terminal schließen.

Ein kurzer Blick mit docker ps zeigt, ob alles wie geplant läuft:

In der Liste der laufenden Container sollten Sie unter anderem opencloud und collabora sehen. Sobald alles gestartet ist, können Sie die Weboberfläche von OpenCloud im Browser aufrufen – unter der Domain, die Sie in der .env-Datei gesetzt haben.

OpenCloud im Browser aufrufen

Sobald alle Container laufen, öffnen Sie Ihren Browser und rufen die konfigurierte Subdomain auf.

Sie sollten nun die Anmeldeseite von OpenCloud sehen. Für den ersten Login verwenden Sie den Benutzernamen admin und das Passwort, das Sie zuvor in der .env unter INITIAL_ADMIN_PASSWORD definiert haben.

Hinweis: Nach dem Einloggen sollten Sie das Passwort direkt ändern.

Wenn alles funktioniert, ist Ihre eigene OpenCloud-Instanz betriebsbereit – sicher per HTTPS erreichbar und eingebunden in Ihre bestehende Infrastruktur.

Storage nicht vergessen: OpenCloud-Daten dauerhaft speichern

Für den produktiven Betrieb von OpenCloud reicht es nicht, wenn der Login funktioniert – Ihre Daten und Einstellungen müssen auch nach einem Neustart erhalten bleiben. Ohne eigene Speicherpfade landen sie sonst in anonymen Docker-Volumes, die sich nur schwer sichern und kaum verwalten lassen. Für eine saubere und zuverlässige Datenhaltung ist deshalb ein eigenes Verzeichnis außerhalb des Containers empfehlenswert.

Ein möglicher Ort dafür ist /srv/opencloud. Laut Filesystem Hierarchy Standard (FHS) steht /srv für „Data for services provided by the system“ – also genau das, was OpenCloud tut. Während Pfade wie /opt oder /var/lib eher für Drittsoftware oder temporäre Laufzeitdaten gedacht sind, bietet /srv eine klare Trennung, ist konsistent nutzbar und lässt sich einfach sichern oder in Backups einbinden. Auch /home ist nicht ideal, da dort typischerweise nur Benutzerdaten liegen – nicht die Dienste selbst. Wer ein eigenes Datenlaufwerk eingebunden hat, kann alternativ auch /mnt/opencloud o. Ä. nutzen.

Im ersten Schritt erstellen Sie die benötigten Verzeichnisse für Konfiguration, Daten und Erweiterungen:

mkdir -p /srv/opencloud/{config,data,apps}
chown -R 1000:1000 /srv/opencloud

Der Benutzer mit der UID 1000 ist der Standard-User innerhalb des Containers. Damit OpenCloud auf die neuen Pfade zugreifen kann, muss der Account Besitzer der Verzeichnisse sein. Die Struktur sieht also so aus:

/srv/opencloud/
├── config/   → Konfig-Dateien von OpenCloud
├── data/     → Benutzerdaten, Dateien, Inhalte
└── apps/     → ggf. lokale Web-Erweiterungen

Anschließend tragen Sie die neuen Speicherorte in Ihrer .env ein:

# OpenCloud Speicherorte für Konfiguration, Daten und Apps (lokale Erweiterungen)

# Konfigurationsverzeichnis – persistent, z. B. config.php, Web-Einstellungen usw.
OC_CONFIG_DIR=/srv/opencloud/config

# Datenverzeichnis – hier landen die Dateien der Nutzer*innen
OC_DATA_DIR=/srv/opencloud/data

# Apps-Verzeichnis – für manuell installierte Erweiterungen (optional)
OC_APPS_DIR=/srv/opencloud/apps

Dann stoppen Sie die laufenden Dienste und starten sie mit der angepassten Konfiguration neu:

docker compose down
docker compose up -d

Jetzt verwendet OpenCloud die persistenten Verzeichnisse auf Ihrem Server – updatefest, sicher und transparent.

Ob alles korrekt eingerichtet ist, prüfen Sie mit einem Blick ins laufende Setup:

docker inspect opencloud-compose-opencloud-1 | grep /srv/opencloud
ls -l /srv/opencloud/config

Wenn die Datei config.php neu angelegt wurde, ist Ihre Konfiguration erfolgreich – OpenCloud speichert nun dauerhaft alle Daten außerhalb des Containers. Ein wichtiger Schritt für alle, die ihre Instanz langfristig stabil betreiben möchten.

OpenCloud auf eigenem Server – flexibel, sicher, souverän

Mit wenigen gezielten Schritten bringen Sie OpenCloud auf einem eigenen Server zum Laufen – inklusive Reverse Proxy, TLS-Verschlüsselung und dauerhaftem Speicher. Das Ergebnis: Eine voll funktionsfähige Cloud-Plattform, die sich nahtlos in Ihre Infrastruktur integriert, ohne Abhängigkeit von externen Anbietern. Ob im Unternehmen, in der Schule oder privat – mit OpenCloud behalten Sie die Kontrolle über Ihre Daten und bleiben technisch unabhängig.