RSS-Reader für einen kleinen VPS im Vergleich

Welcher selbst gehostete RSS-Reader passt zu einem kleinen VPS

Miniflux ist der selbst gehostete RSS-Reader für einen kleinen VPS. Er besteht aus einem Go-Binary und PostgreSQL. Er unterstützt die Fever- und Google-Reader-APIs, sodass sich Smartphone-Apps von Drittanbietern verbinden können. Ein Upgrade ist ein einzelner docker compose pull. Wählen Sie stattdessen FreshRSS, wenn Sie Erweiterungen und einen einzelnen Container mit integriertem SQLite benötigen.

Fünf Reader sind den Speicherplatz auf einem VPS wert: Miniflux, FreshRSS, CommaFeed, yarr und Tiny Tiny RSS. Diese Seite vergleicht die tatsächlichen Unterschiede zwischen ihnen: den Speicherbedarf jedes Stacks, die Datenbank, die jeweils erforderlich ist, die von Ihrer Smartphone-App benötigte Synchronisierungs-API und das Verhalten bei einem Upgrade. Jede Zahl hier wurde entweder vom Projekt veröffentlicht oder ergibt sich aus einer einfachen Berechnung. Der Text nennt jeweils die Quelle. Keine dieser Angaben ist ein Benchmark Ihrer Hardware. Messen Sie daher Ihren eigenen Server mit docker stats.

Die fünf Reader, jeweils ein Absatz

Miniflux ist in Go geschrieben und wird als einzelnes statisch kompiliertes Binary veröffentlicht. Die Dokumentation nennt eine einzige harte Abhängigkeit ausdrücklich: Es „funktioniert nur mit PostgreSQL“. Einen SQLite-Modus gibt es nicht. Miniflux bietet eine REST API, eine Fever-kompatible API und eine Google-Reader-kompatible API sowie den OPML-Import und -Export. Die Volltextsuche wird an PostgreSQL übergeben. Das ist ein Grund dafür, dass die Datenbank nicht optional ist.

FreshRSS ist in PHP geschrieben und läuft als ein Container, der sowohl den Webserver als auch die Anwendung enthält. SQLite ist die Standarddatenbank und benötigt keinen zweiten Dienst. Für größere Installationen werden PostgreSQL und MySQL unterstützt. FreshRSS unterstützt die Google-Reader-API und die Fever-API. Die Installation ist bereits in unserer Anleitung zu FreshRSS auf einem VPS beschrieben. Diese Seite vergleicht FreshRSS daher, statt die Installation zu wiederholen.

CommaFeed ist eine Java-Anwendung auf Quarkus mit einem Aufbau nach dem Vorbild von Google Reader. Die Datenbank wird beim Build und nicht zur Laufzeit ausgewählt. Deshalb veröffentlicht das Projekt ein Image pro Datenbank: athou/commafeed:latest-h2 für die eingebettete H2-Datenbank, athou/commafeed:latest-postgresql für PostgreSQL sowie weitere Varianten für MySQL und MariaDB. CommaFeed stellt eine REST API und eine Fever-kompatible API bereit.

yarr (yet another rss reader) ist ein einzelnes Go-Binary mit eingebettetem SQLite und benötigt überhaupt keinen Container. Plain ./yarr lauscht auf 127.0.0.1:7070. Die Flags sind kurz: -addr 0.0.0.0:7070 -auth alice:secret macht den Dienst hinter einem Passwort im Netzwerk erreichbar, und -db /data/yarr.db legt die Datenbank am gewünschten Speicherort ab. yarr bietet eine Fever-kompatible API. Das neueste getaggte Release ist v2.8 vom Juli 2024, geprüft im August 2026. Betrachten Sie yarr daher als abgeschlossene Software und nicht als aktiv weiterentwickeltes Projekt.

Tiny Tiny RSS ist der älteste und am aufwendigsten zu betreibende der fünf Reader. Das offizielle Docker-Setup besteht aus vier Diensten: einem PostgreSQL-Container, einem PHP-FPM-Anwendungscontainer, einem separaten Updater-Container zum Abrufen der Feeds und einem vorgeschalteten nginx-Container. Die Dokumentation stellt ausdrücklich fest: „Dieses Setup verwendet PostgreSQL.“ Tiny Tiny RSS hat eine eigene JSON API, die vom Android-Client und von mehreren Drittanbieter-Apps verwendet wird. Fever ist nicht integriert.

Wie viel Arbeitsspeicher die einzelnen Stacks benötigen

Die folgenden Werte sind Budgets, keine Messwerte: Jeder Stack sollte auf einem kleinen VPS unter dieser Arbeitsspeichergrenze bleiben. Der Wert für CommaFeed stammt aus einem vom Projekt selbst veröffentlichten Beispiel, das den Container auf 256 MB begrenzt. Die übrigen Werte sind Obergrenzen mit Reserve für den Feed-Abruf. Dieser Teil benötigt beim Start eines Aktualisierungszyklus kurzzeitig deutlich mehr Arbeitsspeicher.

[
  {
    "label": "yarr (SQLite)",
    "containers": 1,
    "mem_limit_mb": 128
  },
  {
    "label": "FreshRSS (SQLite)",
    "containers": 1,
    "mem_limit_mb": 256
  },
  {
    "label": "CommaFeed (H2)",
    "containers": 1,
    "mem_limit_mb": 256
  },
  {
    "label": "Miniflux + Postgres",
    "containers": 2,
    "mem_limit_mb": 320
  },
  {
    "label": "Tiny Tiny RSS",
    "containers": 4,
    "mem_limit_mb": 640
  }
]

yarr benötigt mit 128 MB am wenigsten Arbeitsspeicher, weil es aus einer Binärdatei und einer SQLite-Datei besteht und darunter weder ein Datenbankserver noch eine Sprachlaufzeit erforderlich ist. Miniflux benötigt über 2 Container hinweg 320 MB. Der größte Teil davon entfällt auf PostgreSQL und nicht auf Miniflux. Tiny Tiny RSS bildet mit 640 MB über 4 Container hinweg den Ausreißer. Anwendung, Updater, Datenbank und Webserver sind vier separate Prozesse mit jeweils eigener Heap-Nutzung.

Legen Sie diese Werte als tatsächliche Limits fest und nicht nur als Zielvorgaben. Arbeitsspeicherlimits in Docker Compose beschreibt die Syntax und das Verhalten eines Containers beim Erreichen der Obergrenze. Ein Container ohne Limit beendet sich bei einem vollen System nicht kontrolliert: Der Kernel wählt einen Prozess aus und beendet ihn. Häufig trifft es nicht den Container, der den Speicherdruck verursacht hat.

Welche Datenbank Ihnen die jeweilige Anwendung aufzwingt

Die Datenbank ist der größte operative Unterschied zwischen diesen fünf Anwendungen. Diese Entscheidung wiegt schwerer als Unterschiede in der Benutzeroberfläche, weil sie Ihr Backup-Verfahren und Ihr Upgrade-Risiko bestimmt.

Miniflux und die offizielle Tiny-Tiny-RSS-Konfiguration benötigen PostgreSQL. Damit erhalten Sie eine echte Volltextsuche und sichere parallele Schreibzugriffe. Dafür benötigen Sie einen zweiten Container, ein Volume und müssen mit einem wiederkehrenden Problem umgehen: Die offiziellen PostgreSQL-Images können Daten nicht direkt zwischen Hauptversionen migrieren. Die Dokumentation von Tiny Tiny RSS sagt das ausdrücklich und warnt, dass „official PostgreSQL containers have no support for migrating data between major versions“. Realistisch haben Sie zwei Möglichkeiten: Sie pinnen die alte Hauptversion oder führen mit pg_dump und pg_restore einen Dump und eine Wiederherstellung durch. Planen Sie dies alle ein bis zwei Jahre ein.

SQLite ist die Standarddatenbank von FreshRSS und yarr. Eine Datei, kein Server, kein Port, kein Passwort. Für eine Person mit einigen hundert Feeds funktioniert SQLite zuverlässig. Bei gleichzeitigen Schreibzugriffen mehrerer Benutzer wird es langsamer. Dann lohnt sich die PostgreSQL-Option von FreshRSS. yarr unterstützt seit v2.7 optional PostgreSQL. Für den normalen Betrieb wird jedoch die eingebettete Datei verwendet.

H2 ist die standardmäßig eingebettete Datenbank von CommaFeed. Überlegen Sie diese Entscheidung vor dem Start sorgfältig, weil CommaFeed die Datenbank beim Erstellen des Images festlegt. Der Wechsel von H2 zu PostgreSQL ist später keine Konfigurationsänderung. Dafür benötigen Sie ein anderes Image und eine Datenmigration, die Sie selbst durchführen müssen. Entscheiden Sie sich daher, bevor sich ein Jahr Leseverlauf im System angesammelt hat.

Funktioniert Ihre Smartphone-App?

Diese Frage ist wichtiger, als viele erwarten. Die Weboberfläche ist nur eine Hälfte der Nutzung eines Feedreaders.

Miniflux stellt eine Fever-kompatible API und eine Google-Reader-kompatible API bereit. Daher können sich die meisten iOS- und Android-Clients damit verbinden. FreshRSS unterstützt ebenfalls beide APIs und bewertet sie in der eigenen Dokumentation: Die Google-Reader-API ist „am besten“ und unterstützt den vollständigen Funktionsumfang. Die Fever-API bietet dagegen „eingeschränkte Funktionen und weniger effizientes“ Verhalten. FreshRSS benötigt außerdem zwei Schritte, bevor sich eine App anmelden kann. Aktivieren Sie unter Authentication die Option „Allow API access (required for mobile apps)“. Erstellen Sie anschließend im Benutzerprofil ein API-Passwort. Wenn das API-Passwort fehlt, schlägt die Authentifizierung in der App fehl, während die Webanmeldung weiterhin funktioniert. Das ist verwirrend, bis Sie wissen, wo Sie suchen müssen.

CommaFeed und yarr stellen jeweils nur eine Fever-kompatible API bereit. Sie funktionieren daher mit Fever-fähigen Clients, nicht aber mit Apps, die ausschließlich Google Reader unterstützen. Tiny Tiny RSS verfügt stattdessen über eine eigene API. Sie benötigen daher einen dafür entwickelten Client. Prüfen Sie, ob Ihre bevorzugte App den Reader unterstützt, bevor Sie 300 Feeds importieren.

Eine funktionierende Compose-Datei für einen Server mit 1 GB

Dies ist der Miniflux-Stack, angepasst an das Docker-Beispiel des Projekts mit Stand August 2026. Der veröffentlichte Port ist an die Loopback-Schnittstelle gebunden, die Listen-Adresse ist explizit gesetzt, und beide Container haben ein Speicherlimit.

services:
  miniflux:
    image: miniflux/miniflux:latest
    restart: unless-stopped
    ports:
      - "127.0.0.1:8080:8080"
    depends_on:
      db:
        condition: service_healthy
    environment:
      - DATABASE_URL=postgres://miniflux:CHANGE_ME@db/miniflux?sslmode=disable
      - LISTEN_ADDR=0.0.0.0:8080
      - BASE_URL=https://rss.example.com/
      - RUN_MIGRATIONS=1
      - CREATE_ADMIN=1
      - ADMIN_USERNAME=admin
      - ADMIN_PASSWORD=CHANGE_ME_TOO
      - POLLING_FREQUENCY=60
    healthcheck:
      test: ["CMD", "/usr/bin/miniflux", "-healthcheck", "auto"]
    mem_limit: 128m
  db:
    image: postgres:18
    restart: unless-stopped
    environment:
      - POSTGRES_USER=miniflux
      - POSTGRES_PASSWORD=CHANGE_ME
      - POSTGRES_DB=miniflux
    volumes:
      - miniflux-db:/var/lib/postgresql
    healthcheck:
      test: ["CMD", "pg_isready", "-U", "miniflux"]
      interval: 10s
      start_period: 30s
    mem_limit: 192m
volumes:
  miniflux-db:

Drei Zeilen in dieser Datei werden häufig falsch gesetzt. LISTEN_ADDR=0.0.0.0:8080 wird gesetzt, weil der dokumentierte Standardwert der Binärdatei 127.0.0.1:8080 ist. Ein Prozess, der innerhalb eines Containers an die Loopback-Schnittstelle gebunden ist, kann über den veröffentlichten Port nicht erreicht werden. Das führt zu einem Verbindungsabbruch, obwohl der Container scheinbar fehlerfrei läuft. Der Volume-Pfad /var/lib/postgresql entspricht PostgreSQL 18. Version 17 und frühere Versionen speichern die Daten unter /var/lib/postgresql/data. Wird der falsche Pfad eingebunden, liegt das Datenverzeichnis überhaupt nicht auf dem Volume. Beim nächsten Neuerstellen des Containers sind daher alle Daten weg. 127.0.0.1:8080:8080 hält den Port vom öffentlichen Internet fern. Wird ein Port ohne Adresse veröffentlicht, schreibt Docker eine Regel in eine Chain, die ufw nicht verwaltet. Docker-Ports umgehen ufw erklärt diesen Mechanismus. Ein Traefik-Reverse-Proxy stellt TLS davor.

docker compose up -d
docker compose ps
docker compose logs -f miniflux
docker stats --no-stream

docker compose ps sollte beide Dienste als laufend anzeigen. Die Datenbank sollte dabei als healthy markiert sein. Beim ersten Start von Miniflux werden die Schema-Migrationen protokolliert. Das löst RUN_MIGRATIONS=1 aus. docker stats --no-stream gibt die aktuelle Speicherspalte aus. Diesen Wert vergleichen Sie mit den Obergrenzen in der Tabelle oben. Wird der Miniflux-Container wiederholt neu gestartet, lesen Sie sein Log. connect: connection refused bedeutet, dass Miniflux gestartet wurde, bevor PostgreSQL Verbindungen akzeptieren konnte. Genau das verhindert die Bedingung service_healthy. Prüfen Sie daher, ob die Bedingung Ihre Änderungen überstanden hat. Wenn Compose für Sie neu ist, erklärt Docker-Compose-Grundlagen auf einem VPS zunächst den Aufbau der Datei.

Was auf einem 1-GB-Server nicht passt

Tiny Tiny RSS sollten Sie überspringen. Der offizielle Stack mit vier Diensten läuft auf einem 1-GB-VPS, wenn dieser VPS keine weiteren Aufgaben übernimmt. Neben einer anderen datenbankgestützten Anwendung und einem Reverse Proxy läuft er dort nicht zuverlässig. Vier Dienste bedeuten viermal zusätzlichen Overhead. Einer davon ist PostgreSQL.

CommaFeed passt, aber nur mit dem H2-Image und dem Limit von 256 MB, das im eigenen Beispiel des Projekts festgelegt ist. Problematisch für einen kleinen Server ist die Kombination aus einer JVM und einem separaten Datenbankserver. Eine JVM verwendet den verfügbaren Speicher, den Sie ihr überlassen. In der CommaFeed-Dokumentation wird -Xmx256m als harte Grenze genannt. OpenJ9 wird dort als „eine speichereffizientere Alternative zur HotSpot JVM“ bezeichnet. Daran erkennen Sie, wo der Speicherverbrauch entsteht.

Wenn einem Server der Speicher ausgeht, wählt der Out-of-Memory-Killer des Kernels einen Prozess aus und beendet ihn. dmesg -T zeigt eine Zeile wie Out of memory: Killed process 1234 (java). Der Container verschwindet dann einfach aus docker compose ps, ohne dass im Anwendungslog eine Meldung erscheint. Die Anwendung konnte keine Meldung mehr schreiben.

So verhalten sich Upgrades bei den einzelnen Anwendungen

• Miniflux: docker compose pull && docker compose up -d. Beim Start werden Schema-Migrationen ausgeführt, solange RUN_MIGRATIONS=1 gesetzt ist. Das Upgrade-Risiko liegt nicht bei Miniflux, sondern bei der darunterliegenden PostgreSQL-Hauptversion.
• FreshRSS: Ziehen Sie das neue Image. Bei SQLite muss keine Datenbank-Engine aktualisiert werden. Typische Probleme entstehen daher durch Erweiterungen von Drittanbietern, die nicht aktuell gehalten wurden.
• CommaFeed: Ziehen Sie die Image-Variante, die zu Ihrer Datenbank passt. Beim Wechsel von latest-h2 zu latest-postgresql werden Ihre Daten nicht übernommen.
• yarr: Ersetzen Sie die Binärdatei und behalten Sie die Datenbankdatei bei. Da seit v2.8 im July 2024 keine neue Version veröffentlicht wurde, geprüft im August 2026, gibt es in der Regel nichts zu aktualisieren.
• Tiny Tiny RSS: docker compose pull && docker compose up -d. Schema-Migrationen werden automatisch ausgeführt. Wenn eine Migration bestätigt werden muss, leitet die Oberfläche Sie zu einem Migrationsbildschirm weiter.

Erstellen Sie vor jedem dieser Upgrades einen Datenbank-Dump, nicht erst danach.

docker compose exec -T db pg_dump -U miniflux miniflux | gzip > miniflux-$(date +%F).sql.gz

Kosten eines Aktualisierungsintervalls beim Datenvolumen

Die folgenden Zahlen sind Berechnungen und keine Messwerte. Sie basieren auf 100 Feeds, einer Anfrage pro Feed und Intervall sowie 40 KB pro Antwort. Der tatsächliche Datenverkehr ist geringer, wenn ein Server bedingte Anfragen unterstützt, und höher, wenn Feeds den vollständigen Artikeltext übertragen.

[
  {
    "label": "Every 5 minutes",
    "fetches_per_month": "864,000",
    "gb_per_month": 34.6
  },
  {
    "label": "Every 15 minutes",
    "fetches_per_month": "288,000",
    "gb_per_month": 11.5
  },
  {
    "label": "Every 30 minutes",
    "fetches_per_month": "144,000",
    "gb_per_month": 5.8
  },
  {
    "label": "Every 60 minutes",
    "fetches_per_month": "72,000",
    "gb_per_month": 2.9
  }
]

Ein Intervall von fünf Minuten für 100 Feeds entspricht 864,000 Anfragen und ungefähr 34.6 GB pro Monat. Bei einer stündlichen Abfrage sind es 72,000 Anfragen und etwa 2.9 GB. Miniflux wird mit POLLING_FREQUENCY auf 60 Minuten ausgeliefert. Das entspricht der letzten Zeile des Diagramms. Dieser Standardwert ist für fast alle Benutzer richtig. Ein Artikel kommt nicht früher an, nur weil Sie häufiger danach fragen.

Bedingte Anfragen halten den tatsächlichen Wert unter der berechneten Datenmenge. Ein Reader, der die von einem Feed zurückgegebenen Header ETag und Last-Modified speichert, sendet sie als If-None-Match und If-Modified-Since zurück. Ein Server ohne neue Inhalte antwortet mit 304 Not Modified ohne Inhalt. Der Verbindungsaufbau verursacht weiterhin Datenverkehr, aber nicht die Nutzdaten. Feeds, die bedingte Anfragen ignorieren, übertragen bei jeder Anfrage das gesamte Dokument. Dadurch können wenige große Feeds allein den größten Teil Ihrer übertragenen Daten verursachen.

Aggressive Abfragen können außerdem zu einer Sperre führen. Ein Server, der feststellt, dass Sie zu viele Anfragen senden, antwortet mit 429 Too Many Requests. Einige Websites antworten stattdessen mit 403. Miniflux speichert den letzten Fehler direkt am Feed. Wenn ein Feed nicht mehr aktualisiert wird, während die übrigen Feeds weiterhin funktionieren, sollten Sie daher zuerst die Feed-Liste prüfen.

Feeds verschwinden, und eine OPML-Datei ist kein Backup

Feeds veralten schneller als erwartet. Domains laufen ab, Websites wechseln auf eine Plattform ohne Feed, und eine URL, die früher XML ausgeliefert hat, liefert plötzlich eine HTML-Fehlerseite mit einem 200 OK-Status. Der letzte Fall ist besonders problematisch: Der Abruf ist erfolgreich, das Parsen schlägt fehl, und Ihr Reader protokolliert einen Parsing-Fehler statt eines Netzwerkfehlers. Sortieren Sie die Feed-Liste einmal pro Jahr nach dem letzten Aktualisierungszeitpunkt und löschen Sie Feeds, die nicht mehr reagieren.

Ein OPML-Export ist Ihre Abonnementliste. Er enthält Feed-URLs und Ordnernamen. Der Export enthält weder den Lesestatus noch markierte Artikel, Einstellungen pro Feed, Filterregeln oder den von Ihnen gespeicherten Artikeltext. Wenn Sie diese OPML-Datei in eine neue Installation importieren, erhalten Sie Ihre Feeds zurück, aber alle Artikel, die Sie jemals gelesen haben, sind wieder als ungelesen markiert.

Das wichtige Backup ist die Datenbank. Bei PostgreSQL erledigt der oben genannte pg_dump-Befehl die gesamte Aufgabe. Bei einem SQLite-Reader wie FreshRSS oder yarr stoppen Sie den Schreibprozess und kopieren die Datei. Alternativ erstellen Sie während des Betriebs mit sqlite3 yarr.db ".backup '/tmp/yarr-backup.db'" eine konsistente Kopie. Ein einfaches cp einer Datenbank, in die gerade geschrieben wird, kann eine Datei erzeugen, die sich später nicht öffnen lässt, weil die Kopie einen noch nicht abgeschlossenen Schreibvorgang erfasst. Übertragen Sie diese Dateien anschließend nach einem festen Zeitplan vom Server. Dafür sind restic-Backups auf einem VPS vorgesehen. Stellen Sie mindestens einmal eine Datei in einem temporären Container wieder her, damit Sie wissen, dass das Verfahren funktioniert.

Ein Feed-Reader gehört zu den kostengünstigsten Diensten für den Eigenbetrieb. Deshalb erscheint er auf jeder Liste der Dienste, die sich 2026 für den Eigenbetrieb lohnen. Betreiben Sie daneben eine selbst gehostete SearXNG-Instanz. Dann bleiben sowohl Ihre Lektüre als auch Ihre Suchvorgänge auf Hardware, die Sie kontrollieren.

FAQ

Welcher selbst gehostete RSS-Reader benötigt am wenigsten Arbeitsspeicher?

yarr. Es handelt sich um ein einzelnes Go-Binary mit integriertem SQLite. Daher sind weder ein Datenbankserver noch eine zusätzliche Laufzeitumgebung erforderlich, und ein Limit von 128 MB ist ausreichend. Der Nachteil liegt bei Wartung und Funktionsumfang: Die neueste Version ist v2.8 von July 2024, und das Programm unterstützt ausschließlich die Fever API. Wenn Sie ein aktiv entwickeltes Projekt mit ähnlichem Ressourcenbedarf möchten, ist Miniflux mit PostgreSQL bei 320 MB die bessere Wahl.

Kann ich einen selbst gehosteten RSS-Reader auf einem 1 GB VPS betreiben?

Ja. Miniflux mit PostgreSQL benötigt etwa 320 MB, wenn Sie mem_limit für beide Container setzen. FreshRSS mit SQLite passt in einen Container. Auf einem 1-GB-System sollten Sie den offiziellen Tiny-Tiny-RSS-Stack vermeiden. Er besteht aus 4 Diensten einschließlich eines eigenen PostgreSQL. Setzen Sie immer Speicherlimits. Bei einem ausgelasteten System beendet der Kernel sonst einen Prozess in einem Container ohne Limit. Häufig trifft es dabei die Datenbank und nicht die eigentliche Anwendung.

Welche dieser Anwendungen funktionieren mit RSS-Apps für iOS und Android?

Miniflux und FreshRSS unterstützen sowohl eine Fever-kompatible API als auch eine Google-Reader-kompatible API. Daher können sich nahezu alle mobilen Clients verbinden. CommaFeed und yarr bieten ausschließlich die Fever API. Tiny Tiny RSS verwendet eine eigene API. Dafür benötigen Sie einen speziell dafür entwickelten Client. Bei FreshRSS müssen Sie außerdem unter Authentication den API-Zugriff aktivieren und im Profil ein separates API-Passwort festlegen. Andernfalls kann sich die App nicht anmelden, während die Website weiterhin funktioniert.

Ist ein OPML-Export ein Backup meines RSS-Readers?

Nein. OPML enthält Feed-URLs und Ordner. Damit lässt sich Ihre Abonnementliste wiederherstellen, aber nichts darüber hinaus. Lesestatus, markierte Einträge, Filterregeln und Artikeltexte befinden sich in der Datenbank. Sichern Sie die Datenbank selbst mit pg_dump für PostgreSQL oder mit einem .backup-Befehl für SQLite. Kopieren Sie das Ergebnis anschließend vom Server weg.

Unterstützt Miniflux SQLite?

Nein. In der Projektdokumentation steht, dass es „nur mit PostgreSQL funktioniert“. Die Volltextsuche verwendet PostgreSQL-Funktionen. Daher gibt es keinen Modus mit geringeren Anforderungen, auf den Sie umschalten können. Wenn Sie einen Feed-Reader ohne eigenen Datenbank-Container möchten, verwenden Sie FreshRSS mit dem standardmäßigen SQLite-Backend oder yarr mit seiner eingebetteten Datei.