Self-hosted RSS-readers voor een kleine VPS vergelijken

Welke self-hosted RSS-reader is geschikt voor een kleine VPS

Miniflux is de self-hosted RSS-reader voor een kleine VPS. Het bestaat uit één Go-binary naast PostgreSQL. Het ondersteunt de Fever- en Google Reader-API's, waardoor apps van derden verbinding kunnen maken, en een upgrade is slechts één docker compose pull. Kies voor FreshRSS wanneer u extensies wilt en één container met SQLite erin.

Vijf readers zijn de schijfruimte op een VPS waard: Miniflux, FreshRSS, CommaFeed, yarr en Tiny Tiny RSS. Deze pagina vergelijkt de werkelijke verschillen tussen deze opties: het geheugengebruik van de stack, de database die wordt vereist, de sync-API die uw telefoon-app nodig heeft en wat er gebeurt tijdens een upgrade. Elk cijfer hier is afkomstig van het project zelf of is gebaseerd op eenvoudige berekeningen; de tekst geeft aan welke van de twee van toepassing is. Dit is geen benchmark van uw hardware; meet daarom uw eigen systeem met docker stats.

De vijf lezers, één paragraaf per stuk

Miniflux is geschreven in Go en wordt geleverd als een enkel statisch gecompileerd binair bestand. De documentatie is duidelijk over de enige harde afhankelijkheid: het "werkt alleen met PostgreSQL". Er is geen SQLite-modus. Het biedt een REST API, een Fever-compatibele API en een Google Reader-compatibele API, plus OPML-import en -export. Full-text search wordt afgehandeld door PostgreSQL, wat mede de reden is dat de database niet optioneel is.

FreshRSS is gebaseerd op PHP en draait als één container die zowel de webserver als de applicatie bevat. SQLite is de standaarddatabase en vereist geen tweede service, terwijl PostgreSQL en MySQL worden ondersteund voor grotere installaties. Het ondersteunt de Google Reader API en de Fever API. De installatie hiervan is reeds behandeld in onze FreshRSS op een VPS handleiding, dus deze pagina vergelijkt de software in plaats van de installatie te herhalen.

CommaFeed is Java op Quarkus met een lay-out die Google Reader kopieert. De database wordt gekozen tijdens het build-proces, niet tijdens runtime, waardoor het project één image per database publiceert: athou/commafeed:latest-h2 voor de ingebedde H2-database, athou/commafeed:latest-postgresql voor PostgreSQL, en verdere varianten voor MySQL en MariaDB. Deze tags zijn native gecompileerde builds, en een -jvm-achtervoegsel markeert de varianten die op een JVM draaien. Het stelt een REST API en een Fever-compatibele API beschikbaar, en sinds versie 7.3.0 (augustus 2026) ook een Google Reader-compatibele API.

yarr (yet another rss reader) is één Go-binair bestand met ingebedde SQLite, en het vereist helemaal geen container. De standaard ./yarr luistert op 127.0.0.1:7070. De flags zijn kort: -addr 0.0.0.0:7070 -auth alice:secret stelt het open voor het netwerk achter een wachtwoord, en -db /data/yarr.db plaatst de database op de gewenste locatie. Het heeft een Fever-compatibele API. De nieuwste getagde release is v2.9, van september 2026, gecontroleerd in oktober 2026, volgend op v2.7 in juni en v2.8 in juli, dus het wordt weer actief ontwikkeld.

Tiny Tiny RSS is de oudste van de vijf en de zwaarste om te draaien. Het oorspronkelijke project op tt-rss.org werd op 1 november 2025 stopgezet, en de ontwikkeling gaat verder in een community-fork op github.com/tt-rss/tt-rss, waarvan de documentatie nu de officiële setup is. Die setup bestaat uit vier services: een PostgreSQL-container, een PHP-FPM applicatiecontainer, een aparte updater-container die feeds ophaalt, en een nginx-container aan de voorzijde. De documentatie stelt expliciet dat "deze setup PostgreSQL gebruikt". Het heeft een eigen JSON API, die door de Android-client en diverse applicaties van derden wordt ondersteund. Fever maakt er geen deel van uit.

Hoeveel geheugen elke stack nodig heeft

De onderstaande cijfers zijn budgetten, geen metingen: het geheugenplafond waarbinnen elke stack op een kleine VPS zou moeten blijven. Het getal voor CommaFeed is het door het project zelf gepubliceerde voorbeeld, dat de container beperkt tot 256 MB. De overige cijfers zijn plafonds die ruimte laten voor de feed-fetcher; dit is het onderdeel dat piekt wanneer een verversingscyclus start.

[
  {
    "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 staat het laagst op 128 MB omdat het bestaat uit één binary en één SQLite-bestand, zonder databaseserver of onderliggende language runtime. Miniflux heeft 320 MB nodig verdeeld over 2 containers, waarbij het grootste deel toebehoort aan PostgreSQL in plaats van aan Miniflux. Tiny Tiny RSS is de uitschieter met 640 MB verdeeld over 4 containers, omdat de applicatie, de updater, de database en de webserver vier afzonderlijke processen zijn met vier afzonderlijke heaps.

Stel deze in als harde limieten in plaats van als streefwaarden. Geheugenlimieten in Docker Compose behandelt de syntaxis en wat een container doet wanneer deze het plafond bereikt. Een container zonder limiet faalt niet netjes op een volle server: de kernel kiest een slachtofferproces en beëindigt dit, en het slachtoffer is vaak niet de container die de druk veroorzaakte.

Welke database elke reader aan u opdringt

De database is het grootste operationele verschil tussen deze vijf. Het is een ingrijpendere beslissing dan elk verschil in de gebruikersinterface, omdat het uw back-upprocedure en uw upgraderisico bepaalt.

PostgreSQL is vereist voor Miniflux en voor de officiële Tiny Tiny RSS-setup. Het levert echte full-text search en veilige gelijktijdige schrijfacties op. Het kost een tweede container, een volume en één terugkerend probleem: de officiële PostgreSQL-images kunnen data niet in-place migreren tussen hoofdversies. De documentatie van Tiny Tiny RSS stelt dit direct en waarschuwt dat "officiële PostgreSQL-containers geen ondersteuning bieden voor het migreren van data tussen hoofdversies". Voor een feed reader zijn uw realistische opties het vastzetten van de oude hoofdversie, of een dump en restore uitvoeren met pg_dump en pg_restore. PostgreSQL documenteert ook pg_upgrade en op replicatie gebaseerde upgrades, die de extra configuratie rechtvaardigen bij grote databases waar downtime van belang is; de database van een feed reader is dat zelden. Houd hier rekening mee voor eens in de één of twee jaar.

SQLite is de standaard voor FreshRSS en yarr. Eén bestand, geen server, geen poort, geen wachtwoord. Het voldoet prima voor één persoon met een paar honderd feeds, maar het vertraagt wanneer meerdere gebruikers tegelijk schrijven; op dat moment begint de PostgreSQL-optie van FreshRSS zijn waarde te bewijzen. yarr heeft in v2.7 optionele PostgreSQL-ondersteuning toegevoegd, maar het ingebedde bestand is de gebruikelijke manier om het te draaien.

H2 is de ingebedde standaard van CommaFeed en het verdient een moment van overweging voordat u begint, omdat CommaFeed zijn database kiest wanneer de image wordt gebouwd. Overstappen van H2 naar PostgreSQL op een later moment is geen configuratiewijziging. Het is een andere image plus een datamigratie die u zelf moet uitvoeren, dus beslis voordat u een jaar aan leesgeschiedenis in de box heeft staan.

Werkt uw mobiele app

Deze vraag is bepalender dan men vaak verwacht, omdat de webinterface slechts de helft is van hoe een feedreader wordt gebruikt.

Miniflux ondersteunt een Fever-compatibele API en een Google Reader-compatibele API, waardoor de meeste iOS- en Android-clients verbinding kunnen maken. FreshRSS ondersteunt dezelfde twee, en de documentatie rangschikt ze als volgt: de Google Reader API is "best" met volledige ondersteuning voor functies, terwijl de Fever API "beperkte functies en minder efficiënt" gedrag vertoont. FreshRSS vereist bovendien twee stappen voordat een app kan inloggen. Schakel "Allow API access (required for mobile apps)" in onder Authentication en maak vervolgens een API-wachtwoord aan in het gebruikersprofiel. Het overslaan van het API-wachtwoord resulteert in een authenticatiefout in de app, terwijl de weblogin blijft werken; dit is verwarrend totdat u weet waar u moet zoeken.

CommaFeed ondersteunt inmiddels beide: het beschikt al lang over een Fever-compatibele API, en versie 7.3.0 heeft een Google Reader-compatibele API toegevoegd voor apps die Fever niet ondersteunen. Gebruik dus versie 7.3.0 of hoger als uw app alleen Google Reader spreekt. yarr stelt alleen een Fever-compatibele API beschikbaar; het werkt dus met Fever-clients, maar niet met apps die uitsluitend Google Reader ondersteunen. Tiny Tiny RSS gebruikt daarentegen een eigen API, wat betekent dat u een client nodig heeft die specifiek hiervoor is geschreven. Controleer of uw favoriete app de reader ondersteunt voordat u 300 feeds importeert.

Een werkend compose-bestand voor een server met 1 GB RAM

Dit is de Miniflux-stack, aangepast aan het officiële Docker-voorbeeld van het project per oktober 2026. De gepubliceerde poort is gebonden aan de loopback-interface, het luisteradres is expliciet ingesteld en beide containers hebben een geheugenlimiet.

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:

Drie regels in dit bestand worden vaak onjuist geconfigureerd. LISTEN_ADDR=0.0.0.0:8080 herhaalt wat de officiële image al instelt in de Dockerfile, dus met miniflux/miniflux is het een veilige voorzorgsmaatregel in plaats van een noodzakelijke correctie. Dit is van belang wanneer u een eigen image bouwt of een packaged binary uitvoert, omdat de gedocumenteerde standaardwaarde van de binary 127.0.0.1:8080 is. Een proces dat binnen een container aan de loopback-interface is gebonden, is niet bereikbaar via de gepubliceerde poort; dit resulteert in een connection reset terwijl de container als gezond wordt gerapporteerd. Het volume-pad /var/lib/postgresql komt overeen met PostgreSQL 18; versie 17 en ouder slaan gegevens op in /var/lib/postgresql/data. Het mounten van het verkeerde pad betekent dat de datadirectory zich niet op het volume bevindt, waardoor alle gegevens verdwijnen zodra de container opnieuw wordt aangemaakt. 127.0.0.1:8080:8080 houdt de poort buiten het publieke internet, omdat het publiceren van een poort zonder adres een regel toevoegt aan een chain die niet door ufw wordt beheerd. Docker ports bypass ufw legt dit mechanisme uit, en a Traefik reverse proxy beschrijft hoe u hier TLS voor plaatst.

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

docker compose ps hoort beide services als draaiend weer te geven, waarbij de database als healthy is gemarkeerd. De eerste start van Miniflux logt de schema-migraties, wat wordt geactiveerd door RUN_MIGRATIONS=1. docker stats --no-stream toont het actuele geheugengebruik; dit is het getal dat u moet vergelijken met de limieten in de bovenstaande tabel. Als de Miniflux-container in een lus blijft herstarten, raadpleeg dan het logbestand: connect: connection refused betekent dat de container startte voordat PostgreSQL verbindingen kon accepteren. Dit is precies wat de service_healthy-conditie voorkomt, dus controleer of deze conditie na uw wijzigingen behouden is gebleven. Als Compose nieuw voor u is, behandelt Docker Compose basics on a VPS eerst de structuur van het bestand.

Wat past niet op een 1 GB server

Tiny Tiny RSS is de applicatie die u moet overslaan. De officiële stack van vier services draait op een 1 GB VPS wanneer die VPS niets anders doet, en het draait daar niet naast een andere applicatie met een database en een reverse proxy. Vier services betekenen vier sets overhead, en een daarvan is PostgreSQL.

CommaFeed past wel, maar alleen met de H2-image en de 256 MB limiet die het voorbeeld van het project zelf instelt. De combinatie die een kleine server overbelast, is CommaFeed naast een aparte databaseserver. De -jvm image-varianten maken dit erger, omdat de documentatie van het project waarschuwt dat een JVM standaard gulzig is en ongebruikt geheugen niet teruggeeft aan het besturingssysteem. De latest-h2 en latest-postgresql tags zijn native builds, die het project aanbeveelt vanwege hun lagere geheugengebruik. Gebruik deze, tenzij u een specifieke reden heeft om de JVM te draaien.

Wanneer een server onvoldoende geheugen heeft, kiest de out of memory killer van de kernel een proces en beëindigt dit. dmesg -T toont een regel zoals Out of memory: Killed process 1234 (java), en de container verdwijnt simpelweg uit docker compose ps zonder bericht in het applicatielogboek, omdat de applicatie nooit de kans kreeg om er een te schrijven.

Hoe upgrades zich bij elk pakket gedragen

• Miniflux: docker compose pull && docker compose up -d, waarbij schema-migraties worden toegepast bij het opstarten wanneer RUN_MIGRATIONS=1 is ingesteld. Het risico bij een upgrade ligt niet bij Miniflux zelf, maar bij de onderliggende PostgreSQL-majorversie.
• FreshRSS: haal de nieuwe image op. Bij SQLite is er geen database-engine die geüpgraded moet worden, dus problemen ontstaan meestal door extensies van derden die niet zijn bijgewerkt.
• CommaFeed: haal de image-variant op die overeenkomt met uw database. Overschakelen van latest-h2 naar latest-postgresql migreert uw gegevens niet.
• yarr: vervang het binaire bestand en behoud het databasebestand. Releases verschenen in juni, juli en september 2026, waarbij v2.9 de nieuwste is per oktober 2026; controleer daarom regelmatig de releasepagina.
• Tiny Tiny RSS: docker compose pull && docker compose up -d. De applicatiecontainer werkt zichzelf bij tijdens het opstarten. De FAQ van het project koppelt fouten bij schema-updates aan een beschadigd volume of een onjuiste override-configuratie; controleer deze als eerste bij problemen. Als uw compose-bestand nog steeds images ophaalt van het stopgezette tt-rss.org-project, schakel dan over naar de images van de fork (supahgreg/tt-rss op Docker Hub of ghcr.io/tt-rss/tt-rss).

Maak een database-dump vóór elk van deze acties, niet erna.

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

Wat een verversingsinterval kost aan bandbreedte

De onderstaande cijfers zijn rekenkundig, geen metingen. Ze gaan uit van 100 feeds, één verzoek per feed per interval en 40 KB per antwoord. Het werkelijke verkeer ligt lager wanneer een server voorwaardelijke verzoeken honoreert, en hoger wanneer feeds de volledige tekst van artikelen bevatten.

[
  {
    "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
  }
]

Een interval van vijf minuten op 100 feeds resulteert in 864,000 verzoeken en ongeveer 34.6 GB per maand. Polling per uur resulteert in 72,000 verzoeken en ongeveer 2.9 GB. Miniflux wordt geleverd met POLLING_FREQUENCY ingesteld op 60 minuten; dit is de laatste rij van de tabel en deze standaardinstelling is voor bijna iedereen correct. Een artikel komt niet eerder aan omdat u er vaker om vraagt.

Voorwaardelijke verzoeken zorgen ervoor dat het werkelijke aantal onder het rekenkundige gemiddelde blijft. Een reader die de headers ETag en Last-Modified van een feed opslaat, stuurt deze terug als If-None-Match en If-Modified-Since. Een server zonder nieuwe inhoud antwoordt dan met 304 Not Modified zonder body. De verbinding kost nog steeds een handshake, maar niet de payload. Feeds die voorwaardelijke verzoeken negeren, sturen elke keer het volledige document; enkele grote feeds kunnen daardoor uw datagebruik domineren.

Te vaak pollen leidt bovendien tot blokkades. Een server die besluit dat u het systeem overbelast, antwoordt met 429 Too Many Requests, en sommige sites antwoorden in plaats daarvan met 403. Miniflux registreert de laatste fout bij de feed zelf; de feedlijst is daarom de eerste plek om te controleren wanneer één feed stopt met updaten terwijl de rest blijft werken.

Feeds sterven af, en een OPML-bestand is geen back-up

Feeds verouderen sneller dan u verwacht. Domeinen verlopen, sites verhuizen naar een platform zonder feed, en een URL die voorheen XML serveerde, geeft nu een HTML-foutpagina met een 200 OK status. Dat laatste geval is lastig: het ophalen slaagt, het parsen mislukt, en uw reader registreert een parse-fout in plaats van een netwerkfout. Sorteer eenmaal per jaar de feedlijst op 'laatst bijgewerkt' en verwijder wat stil is komen te staan.

Een OPML-export is uw abonnementslijst. Een standaard OPML-bestand bevat feed-URL's en mapnamen. FreshRSS voegt een eigen XML-namespace toe die ook per-feed instellingen bevat, zoals het verversingsinterval, XPath scraping-selectors en filters voor automatisch als gelezen markeren, maar geen enkele OPML-export bevat de leesstatus, artikelen met een ster of de tekst van artikelen die u heeft opgeslagen. Importeert u die OPML in een nieuwe installatie, dan krijgt u uw feeds terug, maar wordt elk artikel dat u ooit heeft gelezen weer als ongelezen gemarkeerd.

De back-up die er echt toe doet, is de database. Voor PostgreSQL is het pg_dump-commando hierboven de volledige taak. Voor een SQLite-reader zoals FreshRSS of yarr stopt u de writer en kopieert u het bestand, of u maakt een consistente kopie terwijl deze draait met sqlite3 yarr.db ".backup '/tmp/yarr-backup.db'". Een simpele cp van een database waarnaar op dat moment wordt geschreven, kan een bestand opleveren dat later niet opent, omdat de kopie een halfvoltooide schrijfactie bevat. Verplaats die bestanden vervolgens volgens een schema van de server af; dat is waar restic back-ups op een VPS voor zijn. Herstel er minstens één naar een testcontainer zodat u weet dat de procedure werkt.

Een feed reader is een van de goedkoopste services om zelf te draaien, en daarom staat deze op elke lijst van dingen die de moeite waard zijn om in 2026 zelf te hosten. Plaats een zelf-gehoste SearXNG-instantie ernaast en zowel uw lees- als zoekgedrag blijft op hardware die u zelf beheert.

FAQ

Welke zelfgehoste RSS-lezer verbruikt het minste geheugen?

yarr. Het is een enkel Go-binarybestand met ingebouwde SQLite, waardoor er geen databaseserver of extra language runtime nodig is. Een limiet van 128 MB is ruim voldoende. De keerzijde is het beperkte aantal functies: het ondersteunt alleen de Fever API en de nieuwste release is v2.9 van september 2026. Als u ondersteuning voor de Google Reader API en full-text search wilt met een vergelijkbaar verbruik, is Miniflux in combinatie met PostgreSQL op 320 MB een betere keuze.

Kan ik een zelfgehoste RSS-lezer draaien op een 1 GB VPS?

Ja. Miniflux met PostgreSQL past binnen ongeveer 320 MB als u mem_limit instelt op beide containers, en FreshRSS met SQLite past in één container. De stack die u op 1 GB moet vermijden is de officiële Tiny Tiny RSS-stack, die uit 4 services bestaat, inclusief een eigen PostgreSQL-instantie. Stel altijd geheugenlimieten in, omdat een container zonder limiet op een volle server door de kernel wordt beëindigd. Het proces dat wordt gekozen is vaak de database in plaats van de applicatie die de fout veroorzaakt.

Welke van deze werken met RSS-apps voor iOS en Android?

Miniflux, FreshRSS en CommaFeed 7.3.0 of nieuwer ondersteunen zowel een Fever-compatibele API als een Google Reader-compatibele API, waardoor bijna elke mobiele client verbinding kan maken. yarr biedt alleen de Fever API. Tiny Tiny RSS gebruikt een eigen API, dus daarvoor heeft u een specifieke client nodig. Bij FreshRSS moet u bovendien API-toegang inschakelen onder Authentication en een apart API-wachtwoord instellen in het profiel, anders kan de app niet inloggen terwijl de website wel blijft werken.

Is een OPML-export een back-up van mijn RSS-lezer?

Nee. OPML herbouwt alleen uw abonnementslijst. De uitgebreide export van FreshRSS bevat ook instellingen en filters per feed, maar de leesstatus, sterren en artikelteksten staan in de database. Maak een back-up van de database zelf met pg_dump voor PostgreSQL, of een .backup-commando voor SQLite, en kopieer het resultaat naar een locatie buiten de server.

Ondersteunt Miniflux SQLite?

Nee. Volgens de documentatie van het project werkt het "alleen met PostgreSQL". Full-text search is geïmplementeerd met PostgreSQL-specifieke functies, dus er is geen lichtere modus beschikbaar. Als u een feed-lezer wilt zonder aparte databasecontainer, gebruik dan FreshRSS met de standaard SQLite-backend of yarr met het ingebouwde databasebestand.