FreshRSS 2026 selbst hosten: Feed-Aktualisierung, Mobile API und Backups
Eine praxisnahe Anleitung zum Self-Hosting von FreshRSS mit Docker, Ports, persistenten Daten, TLS, Security, Backups und den Fehlern, die einen produktiven Betrieb verhindern. Inklusive Checks.
Ein fehlgeschlagenes FreshRSS-Deployment stürzt nicht immer ab. Es kann eine Login-Seite ausliefern, während Feeds nie aktualisiert werden, weil cron deaktiviert ist oder die ausgehende DNS-Auflösung fehlschlägt. Beginne stattdessen mit einem End-to-End-Check: Feeds hinzufügen, eine geplante Aktualisierung ausführen, einen Eintrag als gelesen markieren und diesen Status über die Mobile API synchronisieren.
Dieser Check entspricht dem dokumentierten Zweck von FreshRSS: ein selbst gehosteter RSS-Reader mit kompatibler Mobile API. Außerdem macht er fehlende Abhängigkeiten, falsche Proxy-Annahmen und flüchtige Daten früher sichtbar als ein einfacher Uptime-Check.
FreshRSS analysieren, bevor du Docker anfasst
Trenne bei FreshRSS vier Bereiche: Ingress, den Listener auf Port 80, dauerhaften State sowie unterstützende Services oder lokale Kapazitäten. Die externe Anforderung von FreshRSS besteht in der geplanten Feed-Aktualisierung und dem ausgehenden Zugriff auf Feed-Hosts. Teste ausgehendes DNS, TLS und das Verhalten des Providers, ohne einen weiteren eingehenden Service zu veröffentlichen.
Führe die bekannte funktionierende Transaktion — Feeds hinzufügen, eine geplante Aktualisierung ausführen, einen Eintrag als gelesen markieren und diesen Status über die Mobile API synchronisieren — aus, bevor du diese Trennung als abgeschlossen betrachtest. Miss die Anzahl der Feeds, das Aktualisierungsintervall, langsame Publisher, Datenbank-Schreibvorgänge und gleichzeitig aktive API-Clients und bewahre das Ergebnis zusammen mit dem Deployment-Eintrag auf. Damit erhältst du sowohl ein Abnahmekriterium als auch die erste Kapazitäts-Baseline.
Den State sichern, den FreshRSS nicht wiederherstellen kann
Erstelle für FreshRSS ein Recovery-Manifest: Daten, Extensions und die ausgewählte Datenbank. Hänge /var/www/FreshRSS/data vor dem Bootstrap ein, schreibe harmlose Beispieldaten und ersetze den Container, um zu beweisen, dass dieser Pfad tatsächlich persistent ist. Prüfe jetzt Ownership und freien Speicherplatz, denn ein eingebundener, aber nicht beschreibbarer Pfad verhält sich vollständig wie fehlende Persistenz.
Sichere in eine von dem laufenden Server getrennte Failure Domain. Stelle FreshRSS aus seinem gepinnten Image wieder her und prüfe, ob Abonnements, Kategorien, Lesestatus, Filter und Extensions zurückkehren und die geplante Aktualisierung einen neuen Eintrag abruft. Der Leitfaden zu persistenten Volumes hilft dabei, diese Übung in eine Snapshot- und Retention-Policy zu übertragen.
Die FreshRSS-Trust-Boundary festlegen
Erstelle ein Threat Model für die Aktionen, die FreshRSS ausführt, nicht nur für das Login-Formular. Der größte Fehler besteht hier darin, das initiale Setup oder den Default-User auf einem öffentlichen Host zugänglich zu lassen. Implementiere diese Boundary: Schließe das Setup privat ab, schütze API-Passwörter und konfiguriere Trusted Proxies, bevor du die mobile Synchronisierung aktivierst.
CRON_MIN steuert das Verhalten, nicht die Vertraulichkeit. Validiere Typ und Wert und speichere echte FreshRSS-Zugangsdaten separat. Behebe einen Berechtigungsfehler nicht, indem du den Container als root ausführst oder den Host weitreichend einbindest. Resource Limits gehören ebenfalls zum Security-Design, wenn Nutzer die Anzahl der Feeds, das Aktualisierungsintervall, langsame Publisher, Datenbank-Schreibvorgänge und gleichzeitig aktive API-Clients beeinflussen können.
Was vor dem Eintreffen echter FreshRSS-Daten erfolgreich sein muss
Überführe den FreshRSS-Smoke-Test in einen wiederholbaren Release-Befehl oder ein kurzes Runbook. Die Ausgabe muss dieses Ergebnis nachweisen: Feeds hinzufügen, eine geplante Aktualisierung ausführen, einen Eintrag als gelesen markieren und diesen Status über die Mobile API synchronisieren. Halte gemeinsam mit dem Ergebnis die Anwendungsversion, den Container-Digest, den Route-Hostnamen und die Kennung der Testdaten fest.
Führe denselben Check nach einem routinemäßigen Container-Austausch und nach der Wiederherstellung von Daten, Extensions und der ausgewählten Datenbank an einem anderen Ort aus. Die Wiederherstellung war erfolgreich, wenn Abonnements, Kategorien, Lesestatus, Filter und Extensions zurückkehren und die geplante Aktualisierung einen neuen Eintrag abruft. Vergleiche die Dauer und den Verbrauch im Zusammenhang mit der Anzahl der Feeds, dem Aktualisierungsintervall, langsamen Publishern, Datenbank-Schreibvorgängen und gleichzeitig aktiven API-Clients. Eine deutliche Änderung verdient eine Untersuchung, selbst wenn die abschließende Aktion weiterhin erfolgreich ist.
Simuliere anschließend einen sicheren Fehler: Verweigere vorübergehend den für die geplante Feed-Aktualisierung und den ausgehenden Zugriff auf Feed-Hosts verwendeten Testpfad. Bestätige, dass FreshRSS den Fehler sichtbar macht und ohne destruktive manuelle Änderungen zum Normalbetrieb zurückkehrt. Bewahre nur den erforderlichen, bereinigten Log-Auszug auf. Dieses vierteilige Gate deckt Start, Persistenz, Wiederherstellung und Fehlerbehandlung ab.
Eine Docker-Baseline für FreshRSS
Ein produktionsnaher Start ist bewusst unspektakulär: benannter State, ein expliziter Port und keine Secrets im Image.
docker run -d \
--name freshrss \
--restart unless-stopped \
-p 127.0.0.1:80:80 \
-v freshrss-data:/var/www/FreshRSS/data \
-e CRON_MIN=15 \
freshrss/freshrss:latest
Das Beispiel ist eine Baseline und kein vollständiger Supporting Stack. Erlaube und verifiziere den für die geplante Feed-Aktualisierung und den ausgehenden Zugriff auf Feed-Hosts erforderlichen Outbound- oder clientseitigen Pfad. Prüfe die tatsächlich verwendeten Mounts und den Listener und versuche anschließend, Feeds hinzuzufügen, eine geplante Aktualisierung auszuführen, einen Eintrag als gelesen zu markieren und diesen Status über die Mobile API zu synchronisieren. Pinnen das funktionierende Image, bevor der nächste Neustart erfolgt.
Verhindern, dass ein erfolgreicher Proxy den Anwendungsfehler verdeckt
Browser, API-Client und FreshRSS müssen sich auf eine gemeinsame Origin einigen. Damit das funktioniert, deklarierst du Trusted Proxies und die kanonische HTTPS-Basis. Bewahre den ursprünglichen Host und das ursprüngliche Protokoll auf und halte Port 80 als konkurrierende öffentliche Adresse nicht verfügbar.
Der Leitfaden zur Fehlersuche bei nicht erreichbaren Websites hilft dabei, eine nicht erreichbare Route von einer antwortenden Anwendung zu unterscheiden. Diese Unterscheidung ist hier wichtig: Feeds werden nie aktualisiert, weil cron deaktiviert ist oder ausgehendes DNS fehlschlägt. Nur der erste Fall lässt sich durch Änderungen am Ingress beheben; der zweite erfordert eine Untersuchung der FreshRSS-Logs, des States oder der Workload.
Die Workload beobachten, nicht nur den Container
Beobachte die von FreshRSS ausgeführte Arbeit: Anzahl der Feeds, Aktualisierungsintervall, langsame Publisher, Datenbank-Schreibvorgänge und gleichzeitig aktive API-Clients. Setze Limits mit ausreichend Headroom für diese Arbeit und vermeide einen Liveness Probe, der mit ihr konkurriert. Der Operator-Check sollte weiterhin regelmäßig versuchen, Feeds hinzuzufügen, eine geplante Aktualisierung auszuführen, einen Eintrag als gelesen zu markieren und diesen Status über die Mobile API zu synchronisieren.
Denke bei Updates daran, dass Extensions, Datenbank-Migrationen und Änderungen am Feed-Parser die Aktualisierungen beeinflussen können, auch wenn der Login weiterhin funktioniert. Deploye den Kandidaten gegen eine wiederhergestellte Kopie und wiederhole den bekannten Test. Wenn Feeds nie aktualisiert werden, weil cron deaktiviert ist oder ausgehendes DNS fehlschlägt, nutze Runtime-Logs und den tatsächlichen Netzwerk-Request, um herauszufinden, welche Annahme sich geändert hat.
Wiederholbare Infrastrukturarbeit zu Dockup verschieben
Das One-Click-FreshRSS-Deployment von Dockup sollte den Austausch sicher machen: Die Route zeigt weiterhin auf Port 80, Secrets sind nicht in das Image eingebrannt und persistente Pfade stehen im neuen Container wieder zur Verfügung. Dasselbe Deployment kann auf Dockup Compute oder einer angebundenen Maschine ausgeführt werden.
Schließe die anwendungsspezifischen Arbeiten ab, indem du die geplante Feed-Aktualisierung und den ausgehenden Zugriff auf Feed-Hosts erlaubst und verifizierst, die kanonische öffentliche Adresse anwendest und diesen Abnahmetest ausführst: Feeds hinzufügen, eine geplante Aktualisierung ausführen, einen Eintrag als gelesen markieren und diesen Status über die Mobile API synchronisieren. Ergänze das Ergebnis der Wiederherstellung im Runbook, bevor echte Nutzer hinzukommen.
Häufig gestellte Fragen
Was benötigt FreshRSS für ein produktives Deployment?
Route den FreshRSS-Container über eine einzige HTTPS-Origin auf Port 80. Die externe Voraussetzung für die Auslieferung ist die geplante Feed-Aktualisierung und der ausgehende Zugriff auf Feed-Hosts. Erkläre FreshRSS erst dann für bereit, wenn du Feeds hinzufügen, eine geplante Aktualisierung ausführen, einen Eintrag als gelesen markieren und diesen Status über die Mobile API synchronisieren kannst.
Welche FreshRSS-Daten gehören in ein Backup?
Persistiere /var/www/FreshRSS/data und nimm Daten, Extensions und die ausgewählte Datenbank in dasselbe Recovery-Manifest auf. Eine saubere FreshRSS-Wiederherstellung ist nur dann erfolgreich, wenn Abonnements, Kategorien, Lesestatus, Filter und Extensions zurückkehren und die geplante Aktualisierung einen neuen Eintrag abruft.
Benötigt FreshRSS hinter einem Reverse Proxy HTTPS?
Verwende HTTPS für die öffentliche FreshRSS-Origin und halte Port 80 auf der internen Route. Wende die FreshRSS-Einstellung korrekt an: Deklariere Trusted Proxies und die kanonische HTTPS-Basis. Bei FreshRSS schützt HTTPS Zugangsdaten oder Benutzerinhalte während der Übertragung und sorgt für konsistentes, originabhängiges Client-Verhalten.
Wie sollte ein FreshRSS-Upgrade getestet werden?
Stelle den aktuellen FreshRSS-State in einem isolierten Deployment wieder her, spiele die Kandidatenversion ein und wiederhole die Abnahmetransaktion. Achte besonders darauf, da Extensions, Datenbank-Migrationen und Änderungen am Feed-Parser die Aktualisierungen beeinflussen können, auch wenn der Login weiterhin funktioniert. Bewahre das vorherige FreshRSS-Image auf, bis die Grenzen für Datenmigration und Rollback geklärt sind.