Cloudreve mit Docker Compose: eigene Cloud mit Freigaben

Cloudreve ist eine selbst gehostete Dateiverwaltung mit Weboberfläche, Freigabelinks, WebDAV und Anbindung an Speicher wie lokale Platten, S3 oder OneDrive. Das in Go geschriebene Projekt steht unter GPL-3.0 und hat knapp 29.000 Sterne auf GitHub; es ist eine schlanke Alternative zu Nextcloud, wenn es vor allem um Ablage und Teilen geht. Diese Anleitung zeigt Version 4 mit Docker Compose, PostgreSQL und Redis, das erste Admin-Konto, Freigaben mit Passwort, eine vollständige Sicherung samt Wiederherstellung und das Update auf eine neue Version.

Voraussetzungen

Im Test belegte Cloudreve rund 125 MiB RAM, PostgreSQL 36 MiB und Redis 6 MiB. Der Plattenbedarf richtet sich nach Ihren Dateien. Für Vorschaubilder bringt das Image ffmpeg, LibreOffice und libvips mit, die beim Erzeugen kurzzeitig CPU brauchen.

• Linux-Server oder VM mit 2 CPU-Kernen, 2 GB RAM (4 GB mit Reserve für Vorschaubilder) und ausreichend Platz für die Nutzdaten, x86_64 oder ARM64
• Docker Engine mit Compose-Plugin v2
• Eine Domain mit TLS-Reverse-Proxy, wenn Freigaben außerhalb des LAN erreichbar sein sollen
• Ein zweites System oder externes Ziel für die Sicherungen
• curl, jq und openssl für die Prüfbefehle

Schritt 1: Compose-Datei anlegen

Die offizielle Doku verweist auf das separate Repository cloudreve/docker-compose. Dessen docker-compose.yml haben wir in drei Punkten angepasst. Erstens lässt PostgreSQL dort mit POSTGRES_HOST_AUTH_METHOD=trust jede Verbindung aus dem Compose-Netz ohne Passwort zu; hier bekommt die Datenbank ein Zufallspasswort, das Cloudreve über CR_CONF_Database.Password erhält. Zweitens hängt der Start an einem Healthcheck der Datenbank. Drittens fehlen die Ports 6888 TCP und UDP, die nur der eingebaute aria2-Dienst für Remote-Downloads per BitTorrent braucht. Redis ist auf die Hauptversion 8 festgelegt statt auf latest. Feste container_name-Einträge entfallen, damit nichts mit anderen Stacks kollidiert. Speichern Sie die Datei als /opt/cloudreve/compose.yaml:

services:
  cloudreve:
    image: cloudreve/cloudreve:${CLOUDREVE_TAG}
    restart: unless-stopped
    depends_on:
      postgresql:
        condition: service_healthy
      redis:
        condition: service_started
    ports:
      - "5212:5212"
    environment:
      - CR_CONF_Database.Type=postgres
      - CR_CONF_Database.Host=postgresql
      - CR_CONF_Database.Port=5432
      - CR_CONF_Database.User=cloudreve
      - CR_CONF_Database.Password=${POSTGRES_PASSWORD}
      - CR_CONF_Database.Name=cloudreve
      - CR_CONF_Redis.Server=redis:6379
      - TZ=Europe/Berlin
    volumes:
      - backend_data:/cloudreve/data

  postgresql:
    image: postgres:17
    restart: unless-stopped
    environment:
      - POSTGRES_USER=cloudreve
      - POSTGRES_DB=cloudreve
      - POSTGRES_PASSWORD=${POSTGRES_PASSWORD}
    volumes:
      - database_postgres:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U cloudreve -d cloudreve"]
      interval: 10s
      timeout: 5s
      retries: 10

  redis:
    image: redis:8
    restart: unless-stopped
    volumes:
      - redis_data:/data

volumes:
  backend_data:
  database_postgres:
  redis_data:

Das Image setzt ab Werk die Zeitzone Asia/Shanghai; mit TZ=Europe/Berlin zeigte der Container im Test die deutsche Zeit. Den Tag schreiben Sie in der .env fest, denn v4 und latest wandern mit jedem Release mit.

Verifizieren: docker compose config --quiet endet ohne Ausgabe mit Exit-Code 0. Warnungen über leere Variablen bedeuten, dass die .env aus Schritt 2 noch fehlt.

Schritt 2: Geheimnis erzeugen und starten

Die .env enthält nur den Image-Tag und das Datenbankpasswort. Alle übrigen Geheimnisse, etwa das Sitzungs-Secret, erzeugt Cloudreve beim ersten Start selbst und legt sie in /cloudreve/data/conf.ini und in der Datenbank ab.

mkdir -p /opt/cloudreve && cd /opt/cloudreve
# compose.yaml aus Schritt 1 hier ablegen, dann:
printf 'CLOUDREVE_TAG=4.19.1\nPOSTGRES_PASSWORD=%s\n' "$(openssl rand -hex 24)" > .env
chmod 600 .env
docker compose up -d

Nach dem Start mit Version 4.19.0 antwortete Cloudreve im Test schon nach rund fünf Sekunden; das Schema in PostgreSQL legt die Anwendung selbst an. Achtung: Cloudreve schreibt alle CR_CONF_-Werte beim Start ins Log, das Datenbankpasswort im Klartext eingeschlossen. Kopieren Sie docker compose logs daher nicht ungeprüft in Foren oder Tickets.

$ docker compose ps --format '{{.Service}} {{.Image}} {{.Status}}'
cloudreve cloudreve/cloudreve:4.19.1 Up 5 seconds
postgresql postgres:17 Up 57 seconds (healthy)
redis redis:8 Up 56 seconds

$ curl -s localhost:5212/api/v4/site/ping | jq -r .data
4.19.1

Verifizieren: PostgreSQL steht auf healthy, Cloudreve auf Up, und /api/v4/site/ping liefert die erwartete Version im Feld data.

Schritt 3: Admin-Konto anlegen und Registrierung schließen

Öffnen Sie http://SERVER:5212 und registrieren Sie ein Konto. Das erste Konto einer leeren Datenbank landet in der Gruppe Admin; im Test meldete der Login danach "group":"Admin". Die Weboberfläche ist vollständig ins Deutsche übersetzt.

Die Registrierung bleibt danach offen. Im Test ließ sich direkt nach dem Admin ein zweites Konto ohne jede Anmeldung anlegen. Für eine Firmen-Cloud ist das unerwünscht, schalten Sie die Registrierung deshalb im Dashboard unter Einstellungen oder per API ab und legen Sie weitere Benutzer im Dashboard unter Benutzer an:

B=http://localhost:5212/api/v4
read -rs PW   # Passwort des Admin-Kontos eingeben
AT=$(curl -s -H 'Content-Type: application/json' -X POST $B/session/token \
  -d "{\"email\":\"admin@example.com\",\"password\":\"$PW\"}" | jq -r .data.token.access_token)

# Registrierung abschalten
curl -s -H 'Content-Type: application/json' -H "Authorization: Bearer $AT" \
  -X PATCH $B/admin/settings -d '{"settings":{"register_enabled":"0"}}'

Tragen Sie im Dashboard unter /admin gleich die Site-URL ein. Ab Werk steht dort http://localhost:5212, und genau diese Adresse enthielten im Test neue Freigabelinks. Beim Aufruf über eine neue Adresse bietet Cloudreve an, sie zu übernehmen.

Verifizieren: Ein weiterer Registrierungsversuch per POST /api/v4/user liefert {"code":40019,"msg":"This feature is not enabled"}, und die Tabelle settings enthält register_enabled|0.

Schritt 4: Dateien hochladen und freigeben

Dateien laden Sie per Drag and Drop hoch. Mit der Standard-Speicherrichtlinie landen sie im Volume unter /cloudreve/data/uploads/BENUTZER-ID/ORDNER/ mit zufälligem Präfix im Dateinamen; große Dateien überträgt der Client in Stücken von 25 MiB. Für Automatisierung dient die REST-API mit dem Token aus Schritt 3, die Dateien über URIs wie cloudreve://my/Projekte adressiert:

# Ordner anlegen und kleine Datei direkt hochladen
curl -s -H 'Content-Type: application/json' -H "Authorization: Bearer $AT" \
  -X POST $B/file/create -d '{"uri":"cloudreve://my/Projekte","type":"folder"}'
curl -s -H "Authorization: Bearer $AT" -X PUT --data-binary @angebot.pdf \
  "$B/file/content?uri=cloudreve%3A%2F%2Fmy%2FProjekte%2Fangebot.pdf"

# Freigabe mit automatisch erzeugtem Passwort
curl -s -H 'Content-Type: application/json' -H "Authorization: Bearer $AT" \
  -X PUT $B/share -d '{"uri":"cloudreve://my/Projekte/angebot.pdf","is_private":true}'

{"code":0,"data":"http://localhost:5212/s/bWhG/8x5161gy","msg":""}

In der Weboberfläche erreichen Sie den Freigabedialog über das Kontextmenü einer Datei. Mit is_private erzeugt Cloudreve ein Passwort und hängt es an den Link an (/s/ID/PASSWORT). Geben Sie nur /s/ID weiter, muss der Empfänger das Passwort selbst eintippen. Optional begrenzen downloads und expire (Sekunden) Anzahl und Laufzeit.

Im Test lud ein anonymer Client die 3 MiB große Testdatei über den Freigabelink herunter, die SHA-256-Prüfsumme stimmte mit dem Original überein.

Verifizieren: curl -s "$B/share/info/ID?password=PASSWORT" | jq .data.unlocked ergibt true, ohne oder mit falschem Passwort false.

Schritt 5: Negativtests und Fehlercodes

Die Cloudreve-API antwortet auch bei Fehlern mit HTTP 200. Ob eine Aktion geklappt hat, steht nur im Feld code, 0 bedeutet Erfolg. Ein Skript, das nur HTTP-Status oder Exit-Code von curl prüft, merkt von einem falschen Passwort nichts. Diese Antworten lieferte der Test:

Login mit falschem Passwort (HTTP 200!):
{"code":40080,"msg":"Incorrect password or email address"}
Download aus der Freigabe mit falschem Passwort:
{"code":40081,"msg":"failed to get target file: Incorrect share password"}
Freigabe-ID, die es nicht gibt:
{"code":40001,"msg":"Failed to parse object ID"}
Registrierung nach dem Abschalten:
{"code":40019,"msg":"This feature is not enabled"}

Auch ein ungültiger Kurzlink wie /s/zzzz9 antwortet mit einer 302-Weiterleitung. Linkprüfer sollten daher /api/v4/share/info/ID abfragen.

Verifizieren: Jeder der vier Aufrufe liefert einen code ungleich 0, ein anonymer Download mit falschem Passwort bekommt keine Download-URL.

Schritt 6: Datenbank und Dateien sichern

Cloudreve verteilt seinen Zustand auf zwei Orte. PostgreSQL enthält Benutzer, Dateibaum, Freigaben und Einstellungen; das Volume backend_data enthält die eigentlichen Dateien unter uploads/ und die conf.ini mit dem Sitzungs-Secret. Das eine ohne das andere ist wertlos. Redis dient als Cache und für Sitzungen, im Test war es für die Wiederherstellung nicht nötig. Stoppen Sie für eine konsistente Sicherung kurz den Cloudreve-Container:

cd /opt/cloudreve && mkdir -p backup
docker compose stop cloudreve
docker compose exec -T postgresql pg_dump -U cloudreve -d cloudreve -Fc > backup/cloudreve-db.dump
docker compose run --rm --no-deps -T --entrypoint tar cloudreve \
  czf - -C /cloudreve/data . > backup/cloudreve-data.tgz
docker compose start cloudreve
cp .env compose.yaml backup/

Im Test war der Dump 71 KB groß, das Archiv rund 3,1 MB. Bei großen Datenmengen sichern Sie das Volume besser inkrementell mit restic oder Borg. Bei S3-Speicherrichtlinien liegen die Dateien beim Anbieter.

Verifizieren: tar tzf backup/cloudreve-data.tgz listet ./conf.ini und die Dateien unter ./uploads/, der Dump ist größer als null Byte.

Schritt 7: Wiederherstellung durchspielen

Eine Sicherung zählt erst, wenn die Rücksicherung einmal funktioniert hat. Im Test lagen eine Markerdatei und die freigegebene Testdatei mit bekannter Prüfsumme in Cloudreve. docker compose down -v löschte alle Volumes, die frische Datenbank enthielt null Tabellen. Dann lief die Wiederherstellung:

cd /opt/cloudreve
docker compose down -v          # löscht alle drei Volumes!
docker compose up -d postgresql redis
docker compose exec -T postgresql pg_isready -U cloudreve -d cloudreve
docker compose exec -T postgresql pg_restore -U cloudreve -d cloudreve \
  --exit-on-error < backup/cloudreve-db.dump
docker compose run --rm --no-deps -T --entrypoint tar cloudreve \
  xzf - -C /cloudreve/data < backup/cloudreve-data.tgz
docker compose up -d

pg_restore rc=0
untar rc=0
PING version=4.19.0 nach ca. 10 s
SHAREDL anonym sha256=81cb5a6e...3b0ae9 erwartet=81cb5a6e...3b0ae9
MARKER zurück: MARKER-1792541688 erwartet: MARKER-1792541688

Danach lieferte der alte Freigabelink die Datei anonym mit identischer Prüfsumme, der Marker war zurück. Ein vorher ausgestelltes Zugriffstoken blieb gültig, weil die Schlüssel aus conf.ini und Datenbank mit zurückkamen. Daraus folgt umgekehrt: Wer die Sicherung besitzt, kann gültige Sitzungen nachbilden. Lagern Sie sie verschlüsselt.

Verifizieren: pg_restore und tar enden mit Exit-Code 0, Login und Freigabelink funktionieren, und sha256sum der heruntergeladenen Datei entspricht dem Original.

Schritt 8: Auf eine neue Version aktualisieren

Der Test startete mit 4.19.0 und wechselte auf 4.19.1, das laut Release-Notes Fehler beim Mailversand und bei WOPI-Apps behebt. Sichern Sie vorher wie in Schritt 6, die Upgrade-Doku empfiehlt das ausdrücklich. Danach genügen neuer Tag, Pull und Neustart:

cd /opt/cloudreve
sed -i 's/^CLOUDREVE_TAG=.*/CLOUDREVE_TAG=4.19.1/' .env
docker compose pull cloudreve
docker compose up -d
docker compose logs --no-log-prefix cloudreve | grep 'Pro='

   V4.19.1  Commit #a8becb9  Pro=false

Nach zehn Sekunden meldete /site/ping die neue Version; Dateien, Freigabe, Prüfsumme und Login waren unverändert. Die Anleitung gilt für Updates innerhalb von Version 4; wer von Cloudreve 3 kommt, folgt der eigenen Migrationsanleitung des Projekts.

Verifizieren: docker compose ps zeigt cloudreve/cloudreve:4.19.1, das Log enthält V4.19.1 und Pro=false.

Troubleshooting

Hinter einem Reverse Proxy muss der Host-Header durchgereicht werden, sonst funktionieren laut Doku einige Funktionen nicht. In Nginx muss client_max_body_size zur Stückgröße passen.

Häufige Fragen

Was unterscheidet die Community Edition von Pro?

Die Community Edition deckt Dateiverwaltung, Freigaben, WebDAV und Speicherrichtlinien ab. Einige Bereiche, im Dashboard etwa Zahlungen und Ereignisse, sind der kostenpflichtigen Pro Edition vorbehalten. Pro nutzt ein eigenes Image aus der Registry release.cloudreve.org, braucht einen Lizenzschlüssel in CR_LICENSE_KEY und wird per cloudreve proupgrade auf die bestehende Datenbank angewendet.

Kann ich statt lokaler Platte S3 nutzen?

Ja. Unter Speicherrichtlinien lassen sich S3-kompatible Speicher wie MinIO, Backblaze B2 oder Cloudflare R2 anlegen und Benutzergruppen zuordnen. Die Sicherung der Dateien verlagert sich dann zum Speicheranbieter, der Datenbank-Dump bleibt Pflicht.

Fazit

Cloudreve ist schnell aufgesetzt und deutlich schlanker als eine Groupware. Entscheidend sind drei Handgriffe nach der Installation: Registrierung schließen, Site-URL setzen und PostgreSQL mit Passwort statt trust betreiben. Mit Dump und Datenverzeichnis kamen im Test nach einem Totalverlust Dateien, Freigaben und Sitzungen vollständig zurück. Updates innerhalb von Version 4 sind ein Tag-Wechsel; Skripte sollten die API-Codes statt der HTTP-Status prüfen.

Weiterführende Anleitungen und Quellen

• Seafile mit Docker Compose: Dateisync installieren und sichern
• PostgreSQL mit pg_dump und pg_restore sichern und migrieren
• Caddy als Reverse Proxy mit automatischem HTTPS
• Cloudreve auf GitHub
• Offizielles Docker-Compose-Repository
• Doku: Deploy with Docker Compose
• Doku: Next Steps, Reverse Proxy und Site-URL
• Doku: REST-API
• Release-Notes Cloudreve 4.19.1
• Image-Tags auf Docker Hub