OpenList ist ein Gateway, kein neuer Cloud-Speicher
Fünf Cloud-Konten, ein S3-Bucket, ein NAS und irgendwo noch ein WebDAV-Zugang: Das eigentliche Problem ist selten der fehlende Speicherplatz. Es sind die unterschiedlichen Oberflächen, Zugangsdaten und Freigabelogiken. OpenList setzt genau dort an. Die selbst gehostete Anwendung stellt mehrere Speicherquellen unter einer gemeinsamen Weboberfläche bereit, ohne daraus automatisch einen neuen zentralen Datenspeicher zu machen.
Das offizielle OpenList-Repository beschreibt das Projekt als community-getriebenen Fork von AList. Der Code ist in Go geschrieben und steht unter AGPL-3.0. Die aktuelle Version v4.2.5 erschien am 7. August 2026. Das ist für den praktischen Einsatz wichtiger als die reine Sternzahl auf GitHub: Ein Gateway zu produktiven Daten braucht nachvollziehbare Releases, offene Änderungen und eine klare Update-Linie.
OpenList arbeitet als Vermittler. Nach Darstellung des Projekts werden Zugriffe je nach Treiber per HTTP-302-Redirect oder Traffic-Forwarding an den eigentlichen Speicher weitergereicht. Die Dateien bleiben damit grundsätzlich beim jeweiligen Anbieter oder auf dem lokalen System. Das reduziert Migrationen, bedeutet aber auch: Verfügbarkeit, Löschregeln, Quoten und Kontosperren der einzelnen Dienste bleiben bestehen.
Welche Dienste und Protokolle zusammenlaufen
Die Treiberliste ist ungewöhnlich breit. Das README nennt unter anderem lokale Dateisysteme, Google Drive, OneDrive und SharePoint, Dropbox, Proton Drive, Amazon S3, Azure Blob Storage, Seafile, SMB, FTP, SFTP und WebDAV. Dazu kommen zahlreiche regionale Cloud-Dienste. Für Administratoren ist vor allem die Mischung interessant: klassische Dateiprotokolle und moderne Objektspeicher lassen sich im selben Navigationsmodell abbilden.
Im Browser zeigt OpenList Verzeichnisse und Dateien, rendert Vorschauen für Bilder, PDF, Markdown, Quellcode und Office-Formate und kann Audio oder Video wiedergeben. Einzelne Bereiche lassen sich schützen. Zusätzlich stellt die Plattform den zusammengeführten Bestand über einen eigenen WebDAV-Endpunkt bereit. Damit können Dateimanager und kompatible Anwendungen auf mehrere Quellen zugreifen, ohne jeden Anbieter separat einzubinden.
Eine Kopierfunktion überträgt Dateien zwischen zwei angebundenen Speichern. Das klingt nach einer universellen Migrationsmaschine, sollte aber nüchtern betrachtet werden: Geschwindigkeit, API-Limits, Dateigrößen und Metadaten hängen weiterhin von beiden Endpunkten ab. OpenList kann den Arbeitsweg vereinheitlichen; es kann keine Beschränkung eines Cloud-Anbieters wegkonfigurieren und garantiert keine verlustfreie Übernahme jeder proprietären Freigabeinformation.
Auch Vorschauen sind technisch nicht neutral. Damit ein Browser PDF, Office-Dateien, Bilder oder Medien darstellen kann, müssen Inhalte durch die OpenList-Instanz oder beteiligte Hilfsdienste verarbeitet werden. Bei vertraulichen Dateien sollten Sie deshalb prüfen, welche Vorschaufunktion lokal arbeitet, welche externen Dienste benötigt und welche temporären Daten entstehen. Nicht jede bequeme Vorschau gehört automatisch in einen sensiblen Mandanten.
Komfort vergrößert den Berechtigungsradius
Die zentrale Oberfläche ist zugleich der zentrale Risikopunkt. Damit OpenList Ordner auflisten, Dateien anzeigen oder zwischen Speichern kopieren kann, benötigt es Zugangsdaten, Tokens oder freigegebene Konten. Wird die Instanz kompromittiert, betrifft der mögliche Zugriff nicht nur einen Ordner, sondern potenziell mehrere verbundene Dienste. Je bequemer der Sammelzugang, desto wichtiger wird das Prinzip der minimalen Berechtigung.
Geben Sie einem Treiber deshalb nur die Rechte, die sein Zweck wirklich benötigt. Ein ausschließlich lesender Medienbestand braucht keine Lösch- oder Schreibberechtigung. Produktive Dokumente sollten nicht gemeinsam mit öffentlichen Downloadbereichen über dasselbe Administratorkonto verwaltet werden. Nicht mehr verwendete API-Tokens gehören widerrufen, nicht lediglich aus der Oberfläche entfernt. Der Beitrag zur Rootless-Härtung von Docker und Podman zeigt, warum auch der Container selbst Teil dieses Berechtigungsmodells ist.
OpenList ersetzt zudem kein Backup. Eine gemeinsame Ansicht kann den Eindruck erwecken, alle Daten seien nun an einem Ort gesichert. Tatsächlich zeigt sie nur mehrere Quellen unter einem Zugang. Wird eine Datei beim Anbieter gelöscht und die Operation über OpenList bestätigt, entsteht dadurch keine unabhängige Kopie. Für wichtige Daten bleiben getrennte Sicherungen, getestete Wiederherstellung und dokumentierte Aufbewahrungsfristen notwendig.
Behandeln Sie die Connector-Zugangsdaten wie produktive Secrets. Speichern Sie keine Tokens in Compose-Dateien, die später im Git-Repository landen, und verwenden Sie für jeden Dienst möglichst einen separaten technischen Zugang. Dann lässt sich ein einzelner Connector sperren, ohne sämtliche Verbindungen neu aufzubauen. Eine regelmäßige Rotation ist besonders wichtig, wenn mehrere Administratoren Zugriff auf die Instanz oder ihre Sicherungen haben.
Docker macht die Installation nicht automatisch sicher
Das Projekt bietet Docker- und Docker-Compose-Konfigurationen sowie Binärdateien für mehrere Plattformen. Damit lässt sich ein Test schnell starten. Ein laufender Container ist jedoch noch keine belastbare Produktionsumgebung. Persistente Datenverzeichnisse, feste Image-Tags, kontrollierte Updates, Protokollierung und ein Wiederanlauf nach Host-Neustart müssen bewusst konfiguriert werden.
Die offizielle Security Policy rät zu HTTPS, einem Reverse Proxy, begrenzten offenen Ports und einem starken, einmaligen Admin-Passwort. Gastzugriff soll nur aktiviert werden, wenn er wirklich nötig ist. Für Docker empfiehlt das Projekt, den Container nach Möglichkeit nicht als Root auszuführen. Diese Hinweise sind keine optionale Politur, sondern Mindestanforderungen für eine Instanz mit Zugriff auf mehrere Cloud-Konten.
Für den ersten Versuch gehört OpenList deshalb nicht ungefiltert ins öffentliche Internet. Sinnvoller ist ein internes Netz oder ein VPN, davor ein Reverse Proxy mit TLS und ein separater Testbenutzer. Erst wenn Anmeldung, Protokolle, Berechtigungen und Restore des OpenList-Datenverzeichnisses geprüft sind, sollte der Kreis der Nutzer wachsen. Cloudflare Workers können laut README als Proxy dienen, ersetzen aber keine saubere Zugriffspolitik der eigentlichen Instanz.
Updates sind bei OpenList Pflicht
Die Security Policy ist an einem Punkt ungewöhnlich eindeutig: Nur die aktuelle stabile v4.x erhält Sicherheitsfixes, ältere Versionen gelten als nicht unterstützt. Wer OpenList betreibt, übernimmt damit einen kontinuierlichen Wartungsauftrag. Ein einmal eingerichteter Container, der monatelang unverändert läuft, passt nicht zum Supportmodell des Projekts.
Das aktuelle Release v4.2.5 ergänzt unter anderem einen neuen Treiber und pipelined multipart upload, enthält aber auch mehrere Fehlerkorrekturen. Neue Funktionen und Sicherheitswartung kommen über denselben Releasekanal. Automatisches Aktualisieren ohne Test ist trotzdem riskant, weil sich Treiberverhalten oder Authentifizierungsabläufe ändern können. Die bessere Reihenfolge lautet: Release Notes lesen, Konfiguration sichern, Testinstanz aktualisieren, Kernpfade prüfen und erst dann Produktion nachziehen.
Überwachen sollten Sie nicht nur die OpenList-Version. Auch OAuth-Anwendungen, API-Schlüssel und Richtlinien der angebundenen Anbieter verändern sich. Ein Treiber kann technisch unverändert sein und trotzdem scheitern, weil ein Cloud-Dienst seine Anmeldung, Quote oder Freigaberegeln ändert. Genau deshalb gehören ein kleiner Funktionstest und ein dokumentierter Rückweg in jedes Updatefenster.
Ein sinnvoller Gesundheitscheck prüft mindestens Anmeldung, Verzeichnisliste, Download einer kleinen Testdatei und freien Speicher am Ziel. Für schreibende Connectoren kommt ein kontrollierter Upload mit anschließendem Löschen hinzu. Alarmieren sollten nicht nur HTTP-Fehler, sondern auch ungewöhnlich leere Ordner oder dauerhaft langsame Antworten. Solche semantischen Ausfälle sehen für einen simplen Portcheck gesund aus, obwohl der eigentliche Speicherzugriff bereits gestört ist. Protokolle sollten deshalb zentral gesammelt und mit einer klaren Aufbewahrungsfrist versehen werden.
Für wen sich OpenList wirklich lohnt
OpenList ist attraktiv, wenn mehrere heterogene Speicher regelmäßig durchsucht, angesehen oder zwischen definierten Zielen bewegt werden. Homelabs, kleine Teams, Medienarchive und technische Arbeitsgruppen können von einer gemeinsamen Navigation profitieren. Besonders nützlich ist das WebDAV-Gateway, wenn vorhandene Programme nicht für jeden Cloud-Anbieter einen eigenen Connector mitbringen.
Weniger sinnvoll ist die Plattform, wenn nur ein einziger Cloud-Dienst genutzt wird oder wenn dessen native Oberfläche alle Anforderungen erfüllt. Dann entsteht durch Self-Hosting vor allem zusätzliche Wartung. Auch hochregulierte Daten gehören nicht allein deshalb in OpenList, weil ein Treiber vorhanden ist. Auditierbarkeit, Schlüsselverwaltung, Protokollaufbewahrung und Rollenmodell müssen zum eigenen Schutzbedarf passen.
Die AGPL-3.0 und das offene Repository erleichtern Prüfung und Anpassung, sind aber kein automatisches Qualitätssiegel. Die Projektaktivität mit aktuellen Releases und vielen Beiträgen ist ein positives Signal, ersetzt jedoch keine eigene Risikoanalyse. Entscheidend ist, ob Sie die Instanz dauerhaft aktualisieren, überwachen und bei einem Ausfall wiederherstellen können. Wer diese Arbeit nicht übernehmen möchte, spart mit einer weiteren Oberfläche wenig.
Trennen Sie außerdem Administration und Nutzung. Die Person, die neue Connectoren und Tokens hinterlegt, benötigt andere Rechte als jemand, der lediglich Dateien durchsucht oder herunterlädt. Gemeinsame Admin-Konten verhindern eine belastbare Zuordnung von Änderungen. Für Teams gehören deshalb individuelle Konten, dokumentierte Rollen und ein geregelter Entzug beim Ausscheiden zur Einführung – auch wenn der erste Homelab-Test noch mit einem einzigen Benutzer beginnt.
So testen Sie OpenList ohne Vollmigration
Beginnen Sie mit einer isolierten Instanz und zwei unkritischen Quellen: etwa einem Testordner auf dem NAS und einem separaten S3-Bucket. Verwenden Sie eigene Zugangsdaten mit minimalen Rechten. Prüfen Sie zunächst nur Auflistung, Vorschau und Download. Schreib-, Kopier- und Löschoperationen kommen erst hinzu, wenn die Lesepfade nachvollziehbar funktionieren.
Im zweiten Schritt testen Sie Fehlerfälle. Entziehen Sie einem Token die Berechtigung, stoppen Sie einen Speicherendpunkt und spielen Sie eine gesicherte OpenList-Konfiguration zurück. Beobachten Sie, welche Meldungen Nutzer sehen und welche Ereignisse protokolliert werden. So zeigt sich, ob das Gateway nur im Idealfall bequem ist oder auch unter realistischen Störungen beherrschbar bleibt.
Erst danach binden Sie produktive Daten an. Dokumentieren Sie pro Quelle Eigentümer, Zweck, Berechtigungen, Token-Laufzeit und unabhängigen Backupweg. OpenList kann dann tatsächlich Komplexität reduzieren: nicht weil es alle Clouds ersetzt, sondern weil ein sauber verwaltetes Gateway den Zugriff vereinheitlicht. Ohne diese Disziplin wird aus einer Oberfläche lediglich ein zusätzlicher, besonders mächtiger Zugangspunkt.
Definieren Sie vor der Freigabe klare Abbruchkriterien: unvollständige Verzeichnislisten, unerklärliche Schreibfehler, fehlende Auditdaten oder eine nicht reproduzierbare Wiederherstellung stoppen den Pilotbetrieb. Der Rückweg ist einfach, solange die nativen Anbieterzugänge unverändert bleiben und OpenList nur als zusätzliche Zugriffsschicht dient. Genau diese Reversibilität ist der wichtigste Vorteil eines Tests ohne Vollmigration.
Was halten Sie von dem Thema? Hier können Sie mit anderen Leserinnen und Lesern ins Gespräch gehen.
Mitreden & diskutieren
Ihre Meinung zählt — teilen Sie Gedanken, Fragen oder Erfahrungen zu diesem Artikel.