Wallabag 2026 selbst hosten: Importe, Datenbank und Hintergrundprozesse
Eine praxisnahe Anleitung zum Self-Hosting von Wallabag mit Docker, Ports, persistenten Daten, TLS, Sicherheit, Backups und den Fehlern, die den Produktiveinsatz verhindern. Inklusive Prüfungen.
Die kürzeste Wallabag-Demo belegt lediglich, dass ein Prozess auf Port 80 lauscht. Für den Produktiveinsatz braucht es belastbarere Nachweise. Dieses Szenario muss auch nach dem Austausch des Containers funktionieren: einen normalen Artikel und eine schwierige Seite speichern, die Hintergrundverarbeitung ausführen, einen mobilen Client synchronisieren und archivierte Inhalte durchsuchen.
Wallabag wird mit einem klaren Ziel eingesetzt: als Read-it-later-Archiv, das störende Seitenelemente entfernt. Die häufigste Falle bei der Bereitstellung besteht darin, dass Assets oder Login-Weiterleitungen HTTP verwenden, weil die Domain-Variable falsch gesetzt ist. Deshalb verdienen die Verarbeitung der öffentlichen URL und der dauerhafte Zustand genauso viel Aufmerksamkeit wie der Start des Images.
Den lokalen Befehl in einen überprüfbaren Service verwandeln
Mit dem folgenden Befehl wird die Container-Grenze sichtbar, ohne so zu tun, als würden damit alle externen Services bereitgestellt.
docker run -d \
--name wallabag \
--restart unless-stopped \
-p 127.0.0.1:80:80 \
-v wallabag-data:/var/www/wallabag/data \
-e SYMFONY__ENV__DOMAIN_NAME=https://app.example.com \
wallabag/wallabag:latest
Prüfe vor dem Öffnen des Ingress die aufgelöste Umgebung, Mounts und den Listener. Ergänze die geprüften Verbindungsdaten für Postgres oder MariaDB, Redis und geplante Import-Worker; verwende für private Services private Namen. Ein erfolgreicher Start ist erst erreicht, wenn du einen normalen Artikel und eine schwierige Seite speichern, die Hintergrundverarbeitung ausführen, einen mobilen Client synchronisieren und archivierte Inhalte durchsuchen kannst – nicht schon dann, wenn docker ps den Status Up ausgibt.
Wovon Wallabag abhängt
Ziehe um Wallabag drei Grenzen: den Ingress zu Port 80, den dauerhaften Zustand und die unterstützenden Anforderungen. Der Container ist austauschbar, die anderen beiden Bereiche brauchen jedoch klar zugewiesene Verantwortlichkeiten. Der Netzwerkvertrag für Wallabag umfasst Postgres oder MariaDB, Redis und geplante Import-Worker. Halte private Endpunkte im internen DNS, erlaube nur erforderliche ausgehende Verbindungen und gib Wallabag ein Service-Credential mit begrenztem Berechtigungsumfang.
Das Diagramm ist vollständig, wenn ein sauberer Client einen normalen Artikel und eine schwierige Seite speichern, die Hintergrundverarbeitung ausführen, einen mobilen Client synchronisieren und archivierte Inhalte durchsuchen kann. Erfasse Zeit- und Ressourcendaten für das Abrufen von Seiten, Parser-Verarbeitung, Bild-Downloads, Queues und das Wachstum der Datenbank. Wenn die Transaktion fehlschlägt, zeigt die erste Grenze, die sich nicht wie dokumentiert verhält, ob Routing, lokale Kapazität oder ein unterstützender Service untersucht werden muss.
Wallabag nach dem Bootstrap absichern
Übernimm keine Sicherheitsannahmen aus einem lokalen Tutorial. Das spezifische Risiko bei Wallabag besteht darin, Standard-Zugangsdaten beizubehalten oder die Konfiguration vertrauenswürdiger Proxies zu überspringen. Entferne daher vor dem öffentlichen Zugriff die Standard-Zugangsdaten, schütze Import-Tokens und konfiguriere vertrauenswürdige Proxies.
SYMFONY__ENV__DOMAIN_NAME ist eine Konfiguration und kein Secret. Halte seinen Wert dennoch explizit und schütze die separaten Zugangsdaten, die Wallabag verwendet. Begrenze den Datei- und Netzwerkzugriff, schütze Setup-Endpunkte und definiere Limits für Uploads, Requests oder die Ausführung rund um das Abrufen von Seiten, Parser-Verarbeitung, Bild-Downloads, Queues und das Wachstum der Datenbank.
Die öffentliche Origin eindeutig festlegen
Stelle für Wallabag einen einzigen HTTPS-Hostnamen bereit und halte den direkten Zugriff auf Port 80 privat. Setze den Domain-Namen auf die endgültige HTTPS-URL. So verhinderst du, dass Browser und API-Clients zwei konkurrierende Adressen kennenlernen.
Führe die bekannte erfolgreiche Transaktion mit einem sauberen Client aus und untersuche den ersten fehlschlagenden Request. Verwende den Leitfaden für benutzerdefinierte Domains, wenn DNS oder TLS fehlerhaft sind. Behandle „Assets oder Login-Weiterleitungen verwenden HTTP, weil die Domain-Variable falsch ist“ als separate Anwendungsdiagnose, sobald die Route nachweislich funktioniert.
Austauschbare Container von dauerhaften Daten trennen
Zum dauerhaften Wiederherstellungssatz gehören die Datenbank, Bilder, importierte Inhalte und die Konfiguration. Binde /var/www/wallabag/data vor dem Bootstrap ein, schreibe harmlose Beispieldaten und ersetze den Container, um zu beweisen, dass dieser Pfad tatsächlich persistent ist. Ein Volume schützt Daten vor dem Austausch des Containers, aber nicht vor dem Verlust des Hosts, versehentlichem Löschen oder Beschädigungen auf Anwendungsebene.
Erstelle Backups, die die jeweilige Datenquelle berücksichtigen: Verwende bei Bedarf logische Dumps für laufende Datenbanken und kopiere Dateien nur aus einem konsistenten Zustand. Bewahre eine verschlüsselte Kopie außerhalb des Wallabag-Hosts auf. Das Abnahmekriterium für eine Wiederherstellung ist konkret: Artikel, Tags, Annotationen, Benutzer und API-Tokens sind wieder vorhanden und der mobile Client synchronisiert. Der Leitfaden für getestete Wiederherstellungen erklärt, warum ein erfolgreicher Job allein nicht ausreicht.
Welche Nachweise vor dem Produktivstart von Wallabag gesammelt werden sollten
Definiere vor dem Start eine bekannte erfolgreiche Transaktion für Wallabag: einen normalen Artikel und eine schwierige Seite speichern, die Hintergrundverarbeitung ausführen, einen mobilen Client synchronisieren und archivierte Inhalte durchsuchen. Lege ihre Voraussetzungen, die erwartete Antwort und die Bereinigungsschritte ohne Secret-Werte in der Versionsverwaltung ab. Pinne das Image, mit dem diese Referenz erstellt wird.
Verwende die Transaktion, um einen Ersatz und eine unabhängige Wiederherstellung zu validieren. Der wiederhergestellte Service ist nur dann akzeptabel, wenn Artikel, Tags, Annotationen, Benutzer und API-Tokens wieder vorhanden sind und der mobile Client synchronisiert. Beobachte gleichzeitig das Abrufen von Seiten, Parser-Verarbeitung, Bild-Downloads, Queues und das Wachstum der Datenbank und mache den langsamsten oder am stärksten begrenzten Teil zu einem Service-Level-Alert.
Der Gate braucht außerdem einen Negativtest: Entziehe der Testidentität vorübergehend den Zugriff auf Postgres oder MariaDB, Redis und geplante Import-Worker. Bestätige, dass Wallabag einen verwertbaren Fehler ausgibt und dabei die Daten erhält, stelle den gültigen Zustand wieder her und wiederhole die bekannte erfolgreiche Transaktion. Wenn beide Ergebnisse aufbewahrt werden, verhindert das, dass ein oberflächlicher Health-Endpunkt zum einzigen Produktionsnachweis wird.
Wallabag entlang seines tatsächlichen Engpasses betreiben
Erstelle Dashboards für das Abrufen von Seiten, Parser-Verarbeitung, Bild-Downloads, Queues und das Wachstum der Datenbank. Ein CPU-Diagramm ohne Kontext zu dieser Auslastung kann nicht erklären, warum Wallabag langsam ist. Ergänze einen synthetischen oder geplanten Check, der mit harmlosen Testdaten versucht, einen normalen Artikel und eine schwierige Seite zu speichern, die Hintergrundverarbeitung auszuführen, einen mobilen Client zu synchronisieren und archivierte Inhalte zu durchsuchen.
Berücksichtige vor einem Upgrade dieses anwendungsspezifische Risiko: Wallabag-Migrationen, Parser-Verhalten und die Worker-Konfiguration sollten mit repräsentativ gespeicherten Seiten getestet werden. Stelle ein aktuelles Backup in einer isolierten Bereitstellung wieder her, führe dort die Migrationen aus und vergleiche das Verhalten. Wenn Assets oder Login-Weiterleitungen HTTP verwenden, weil die Domain-Variable falsch ist, untersuche zuerst die betroffene Grenze – öffentliche Origin, Storage oder Abhängigkeit –, bevor du andere Einstellungen änderst.
Dockup für die Plattformebene verwenden
Für Wallabag kann Dockup die Route und das TLS-Zertifikat erstellen, Mounts erhalten, Secrets bereitstellen und Postgres oder MariaDB, Redis sowie geplante Import-Worker über ein privates Netzwerk anbinden – unabhängig davon, ob die Bereitstellung auf Dockup oder auf angebundenen Servern erfolgt.
Das Release-Gate bleibt dennoch die konkrete Wallabag-Transaktion: einen normalen Artikel und eine schwierige Seite speichern, die Hintergrundverarbeitung ausführen, einen mobilen Client synchronisieren und archivierte Inhalte durchsuchen. Prüfe außerdem die Wiederherstellungsbedingung: Artikel, Tags, Annotationen, Benutzer und API-Tokens sind wieder vorhanden und der mobile Client synchronisiert. Diese beiden Prüfungen zeigen, ob die Bereitstellung funktioniert und ob sie wiederhergestellt werden kann.
Häufig gestellte Fragen
Was benötigt Wallabag für eine produktive Bereitstellung?
Leite den Wallabag-Container auf Port 80 über eine einzige HTTPS-Origin. Die unterstützenden Netzwerkanforderungen sind Postgres oder MariaDB, Redis und geplante Import-Worker. Erkläre Wallabag erst dann für bereit, wenn du einen normalen Artikel und eine schwierige Seite speichern, die Hintergrundverarbeitung ausführen, einen mobilen Client synchronisieren und archivierte Inhalte durchsuchen kannst.
Welche Wallabag-Daten gehören in ein Backup?
Mache /var/www/wallabag/data persistent und nimm Datenbank, Bilder, importierte Inhalte und Konfiguration in dasselbe Wiederherstellungsmanifest auf. Eine saubere Wallabag-Wiederherstellung ist erst dann erfolgreich, wenn Artikel, Tags, Annotationen, Benutzer und API-Tokens wieder vorhanden sind und der mobile Client synchronisiert.
Benötigt Wallabag hinter einem Reverse Proxy HTTPS?
Verwende HTTPS für die öffentliche Wallabag-Origin und halte Port 80 innerhalb der internen Route. Wende die Wallabag-Einstellung korrekt an: Setze den Domain-Namen auf die endgültige HTTPS-URL. Bei Wallabag schützt HTTPS Zugangsdaten oder Benutzerinhalte während der Übertragung und sorgt für ein konsistentes Client-Verhalten, das von der Origin abhängt.
Wie sollte ein Wallabag-Upgrade getestet werden?
Stelle den aktuellen Wallabag-Zustand in einer isolierten Bereitstellung wieder her, spiele die geplante Version ein und wiederhole die Abnahmetransaktion. Achte besonders darauf, da Wallabag-Migrationen, Parser-Verhalten und die Worker-Konfiguration mit repräsentativ gespeicherten Seiten getestet werden sollten. Bewahre das bisherige Wallabag-Image auf, bis die Grenzen für Datenmigration und Rollback verstanden sind.