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 Leser, jeweils ein Absatz

Miniflux ist in Go geschrieben und wird als einzelne statisch kompilierte Binärdatei veröffentlicht. In der Dokumentation wird die eine harte Abhängigkeit ausdrücklich genannt: Das Programm „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 Import und Export von OPML. Die Volltextsuche wird an PostgreSQL delegiert. 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 wird bereits in unserer Anleitung zu FreshRSS auf einem VPS beschrieben. Diese Seite vergleicht FreshRSS daher nur, statt die Installation zu wiederholen.

CommaFeed ist eine Java-Anwendung auf Quarkus mit einem Aufbau nach dem Vorbild von Google Reader. Die Datenbank wird zur Build-Zeit und nicht zur Laufzeit ausgewählt. Daher 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. Diese Tags bezeichnen nativ kompilierte Builds. Ein Suffix -jvm kennzeichnet dagegen die Varianten, die auf einer JVM laufen. CommaFeed stellt eine REST API und eine Fever-kompatible API bereit. Seit Version 7.3.0 (August 2026) gibt es außerdem eine Google-Reader-kompatible API.

yarr (yet another rss reader) besteht aus einer einzelnen Go-Binärdatei 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.9 von September 2026, geprüft im Oktober 2026. Zuvor erschienen v2.7 im Juni und v2.8 im Juli. Das Projekt wird daher wieder aktiv entwickelt.

Tiny Tiny RSS ist das älteste und am aufwendigsten zu betreibende Projekt der fünf. Das ursprüngliche Projekt auf tt-rss.org wurde am 1. November 2025 eingestellt. Die Entwicklung wird in einem Community-Fork unter github.com/tt-rss/tt-rss fortgesetzt. Dessen Dokumentation ist inzwischen die offizielle Installationsanleitung. Dieses 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. In der Dokumentation steht ausdrücklich: „Dieses Setup verwendet PostgreSQL.“ Tiny Tiny RSS verfügt über eine eigene JSON API, die vom Android-Client und mehreren Drittanbieter-Apps verwendet wird. Fever ist nicht Bestandteil des Projekts.

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 Sie jeweils verwenden müssen

Die Datenbank ist der größte betriebliche Unterschied zwischen diesen fünf Anwendungen. Diese Entscheidung ist wichtiger als Unterschiede in der Benutzeroberfläche, weil sie Ihre Backup-Prozedur und das Upgrade-Risiko bestimmt.

Miniflux und die offizielle Tiny-Tiny-RSS-Einrichtung benötigen PostgreSQL. Damit erhalten Sie eine echte Volltextsuche und sichere parallele Schreibzugriffe. Dafür benötigen Sie einen zweiten Container und ein Volume. Außerdem entsteht ein wiederkehrendes Problem: Die offiziellen PostgreSQL-Images können Daten nicht direkt zwischen Hauptversionen migrieren. In der Dokumentation von Tiny Tiny RSS wird dies ausdrücklich erwähnt. Dort steht, dass „official PostgreSQL containers have no support for migrating data between major versions“. Für einen Feedreader haben Sie realistisch zwei Möglichkeiten: Sie pinnen die alte Hauptversion oder führen mit pg_dump und pg_restore einen Dump und eine Wiederherstellung durch. PostgreSQL dokumentiert außerdem pg_upgrade und Upgrades auf Basis von Replikation. Diese Verfahren rechtfertigen den zusätzlichen Einrichtungsaufwand bei großen Datenbanken, bei denen Ausfallzeiten relevant sind. Die Datenbank eines Feedreaders gehört selten dazu. Planen Sie diese Aufgabe einmal pro Jahr oder alle 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 FreshRSS mit seiner PostgreSQL-Option. yarr unterstützt seit v2.7 optional PostgreSQL. Für den normalen Betrieb wird jedoch die eingebettete Datei verwendet.

H2 ist die eingebettete Standarddatenbank von CommaFeed. Sie sollten diese Entscheidung vor dem Start sorgfältig prüfen, weil CommaFeed seine Datenbank beim Erstellen des Images auswählt. Der Wechsel von H2 zu PostgreSQL ist später keine Konfigurationsänderung. Sie benötigen dafür ein anderes Image und müssen die Daten selbst migrieren. Entscheiden Sie sich daher, bevor sich ein Jahr Lesehistorie in der Instanz angesammelt hat.

Funktioniert Ihre Smartphone-App?

Diese Frage entscheidet über mehr, als viele erwarten, weil die Weboberfläche nur die Hälfte der Nutzung eines Feed-Readers abdeckt.

Miniflux stellt eine Fever-kompatible API und eine Google-Reader-kompatible API bereit. Daher können die meisten iOS- und Android-Clients eine Verbindung herstellen. FreshRSS stellt dieselben beiden APIs bereit. In der eigenen Dokumentation werden sie unterschiedlich bewertet: Die Google-Reader-API ist „best“ und unterstützt den vollständigen Funktionsumfang. Die Fever-API bietet dagegen „limited features and less efficient“ 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 Sie das API-Passwort nicht erstellen, schlägt die Authentifizierung in der App fehl, während die Anmeldung über die Weboberfläche weiterhin funktioniert. Das ist verwirrend, bis Sie wissen, wo Sie suchen müssen.

CommaFeed unterstützt inzwischen ebenfalls beide APIs. Das Programm bietet schon lange eine Fever-kompatible API. Version 7.3.0 hat zusätzlich eine Google-Reader-kompatible API für Apps eingeführt, die Fever nicht unterstützen. Verwenden Sie daher 7.3.0 oder eine neuere Version, wenn Ihre App ausschließlich Google Reader unterstützt. yarr stellt eine Fever-kompatible API bereit und keine weitere. Es funktioniert daher mit Fever-fähigen Clients, nicht aber mit Apps, die ausschließlich Google Reader unterstützen. Tiny Tiny RSS verwendet stattdessen eine eigene API. Sie benötigen daher einen dafür entwickelten Client. Prüfen Sie, ob Ihre bevorzugte App den Feed-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 Oktober 2026. Der veröffentlichte Port ist an die Loopback-Adresse gebunden, die Adresse wird 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 wiederholt, was das offizielle Image bereits in seiner Dockerfile festlegt. Zusammen mit miniflux/miniflux ist das daher eine harmlose Absicherung und keine Fehlerbehebung. Die Einstellung ist relevant, wenn Sie ein eigenes Image erstellen oder eine paketierte Binärdatei ausführen, weil der dokumentierte Standardwert der Binärdatei 127.0.0.1:8080 lautet. Ein Prozess, der innerhalb eines Containers an die Loopback-Adresse gebunden ist, kann über den veröffentlichten Port nicht erreicht werden. Dadurch erhalten Sie einen Verbindungsabbruch, obwohl der Container einen fehlerfreien Status anzeigt. Der Volume-Pfad /var/lib/postgresql entspricht PostgreSQL 18. Version 17 und frühere Versionen speichern die Daten unter /var/lib/postgresql/data. Wenn der falsche Pfad eingebunden wird, liegt das Datenverzeichnis überhaupt nicht auf dem Volume. Beim nächsten Neuerstellen des Containers sind daher alle Daten verschwunden. 127.0.0.1:8080:8080 hält den Port vom öffentlichen Internet fern, weil das Veröffentlichen eines Ports ohne Adresse eine Regel in eine Chain schreibt, 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. Diese werden durch RUN_MIGRATIONS=1 ausgelöst. docker stats --no-stream gibt die aktuelle Speicherspalte aus. Diesen Wert vergleichen Sie mit den Grenzwerten in der obigen Tabelle. Wenn der Miniflux-Container in einer Neustartschleife läuft, lesen Sie sein Log. connect: connection refused bedeutet, dass der Container gestartet wurde, bevor PostgreSQL Verbindungen annehmen konnte. Genau das verhindert die Bedingung service_healthy. Prüfen Sie daher, ob die Bedingung bei Ihren Änderungen erhalten geblieben ist. Wenn Compose für Sie neu ist, erklärt Docker-Compose-Grundlagen auf einem VPS zunächst den Aufbau der Datei.

Was auf einen 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. Er läuft dort jedoch nicht zusammen mit einer weiteren datenbankgestützten Anwendung und einem Reverse Proxy. Vier Dienste bedeuten viermal Overhead. Einer davon ist PostgreSQL.

CommaFeed passt, aber nur mit dem H2-Image und der Begrenzung auf 256 MB, die das eigene Beispiel des Projekts festlegt. Problematisch für einen kleinen Server ist CommaFeed zusammen mit einem separaten Datenbankserver. Die -jvm-Image-Varianten verschärfen das Problem, weil die Dokumentation des Projekts darauf hinweist, dass eine JVM standardmäßig viel Speicher beansprucht und ungenutzten Speicher nicht an das Betriebssystem zurückgibt. Bei latest-h2 und latest-postgresql handelt es sich um native Builds. Das Projekt empfiehlt sie wegen ihres geringeren Speicherbedarfs. Verwenden Sie daher diese Varianten, sofern Sie keinen Grund für den Betrieb der JVM haben.

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 Anwendungs-Log eine Meldung erscheint. Die Anwendung konnte keine Meldung schreiben, weil sie nicht mehr dazu kam.

Wie sich Upgrades bei den einzelnen Anwendungen verhalten

• Miniflux: docker compose pull && docker compose up -d, wobei Schema-Migrationen beim Start ausgeführt werden, solange RUN_MIGRATIONS=1 gesetzt ist. Das Upgrade-Risiko liegt nicht bei Miniflux. Es liegt bei der darunterliegenden PostgreSQL-Hauptversion.
• FreshRSS: Pullen Sie das neue Image. Bei SQLite gibt es keine Datenbank-Engine, die aktualisiert werden muss. Typische Fehler werden daher durch Erweiterungen von Drittanbietern verursacht, die nicht aktuell gehalten wurden.
• CommaFeed: Pullen Sie die Image-Variante, die zu Ihrer Datenbank passt. Der Wechsel von latest-h2 zu latest-postgresql übernimmt Ihre Daten nicht.
• yarr: Ersetzen Sie die Binärdatei und behalten Sie die Datenbankdatei. Im Juni, Juli und September 2026 wurden Releases veröffentlicht. Mit v2.9 war im Oktober 2026 die neueste Version verfügbar. Prüfen Sie daher gelegentlich die Release-Seite.
• Tiny Tiny RSS: docker compose pull && docker compose up -d. Der Anwendung-Container aktualisiert sich beim Start selbst. Die FAQ des Projekts führt Fehler bei Schema-Updates auf ein fehlerhaftes Volume oder eine fehlerhafte Override-Konfiguration zurück. Prüfen Sie diese zuerst, wenn ein solcher Fehler auftritt. Wenn Ihre Compose-Datei weiterhin Images vom eingestellten Projekt tt-rss.org abruft, stellen Sie sie auf die Images des Forks um (supahgreg/tt-rss auf Docker Hub oder ghcr.io/tt-rss/tt-rss).

Erstellen Sie vor jedem dieser Vorgänge einen Datenbank-Dump, nicht 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. Dieser letzte Fall ist 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. Eine standardkonforme OPML-Datei enthält Feed-URLs und Ordnernamen. FreshRSS ergänzt einen eigenen XML-Namespace, der auch Feed-spezifische Einstellungen wie das Aktualisierungsintervall, XPath-Scraping-Selektoren und Filter für das automatische Lesen enthält. Kein OPML-Export enthält jedoch den Lesestatus, markierte Artikel oder den von Ihnen gespeicherten Artikeltext. Wenn Sie diese OPML-Datei in eine neue Installation importieren, sind Ihre Feeds wieder vorhanden, aber alle Artikel, die Sie jemals gelesen haben, sind erneut als ungelesen markiert.

Das entscheidende 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 Zeitplan vom Server auf ein anderes System. Dafür sind restic-Backups auf einem VPS vorgesehen. Stellen Sie mindestens einmal ein Backup in einem temporären Container wieder her, damit Sie wissen, dass das Verfahren funktioniert.

Ein Feed-Reader gehört zu den günstigsten Diensten für den Eigenbetrieb. Deshalb steht 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 Suchanfragen auf Hardware, die Sie kontrollieren.

FAQ

Welcher Self-Hosted-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 Sprachlaufzeit erforderlich, und ein Limit von 128 MB bietet ausreichend Spielraum. Der Nachteil ist der Funktionsumfang: yarr unterstützt nur die Fever API, und die neueste Version ist v2.9 vom September 2026. Wenn Sie Unterstützung für die Google Reader API und eine Volltextsuche bei einem ähnlichen Ressourcenbedarf benötigen, ist Miniflux mit PostgreSQL bei 320 MB die bessere Wahl.

Kann ich einen Self-Hosted-RSS-Reader auf einem 1-GB-VPS betreiben?

Ja. Miniflux mit PostgreSQL bleibt bei 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 Services einschließlich eines eigenen PostgreSQL-Services. Setzen Sie immer Speicherlimits. Ein unbegrenzter Container auf einem ausgelasteten System führt dazu, dass der Kernel einen Prozess beendet. Häufig trifft es dabei die Datenbank und nicht die Anwendung, die den Fehler verursacht hat.

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

Miniflux, FreshRSS und CommaFeed 7.3.0 oder höher unterstützen sowohl eine Fever-kompatible API als auch eine Google-Reader-kompatible API. Daher lassen sich fast alle mobilen Clients verbinden. yarr bietet nur die Fever API. Tiny Tiny RSS verwendet eine eigene API. Sie benötigen daher einen dafür entwickelten Client. In FreshRSS müssen Sie den API-Zugriff außerdem unter Authentication 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 stellt Ihre Abonnementliste wieder her. Der erweiterte Export von FreshRSS enthält außerdem Einstellungen und Filter pro Feed. Der Lesestatus, markierte Elemente und Artikeltexte werden jedoch vollständig in der Datenbank gespeichert. 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 auf ein anderes System.

Unterstützt Miniflux SQLite?

Nein. Laut Projektdokumentation funktioniert Miniflux „nur mit PostgreSQL“. Die Volltextsuche verwendet PostgreSQL-Funktionen. Daher gibt es keinen Modus mit geringerem Ressourcenbedarf, auf den Sie umstellen können. Wenn Sie einen Feed-Reader ohne separaten Datenbankcontainer benötigen, betreiben Sie FreshRSS mit dem standardmäßigen SQLite-Backend oder yarr mit seiner eingebetteten Datei.