Quel lecteur RSS auto-héberger sur un petit VPS ?

Quel lecteur RSS auto-hébergé convient à un petit VPS

Miniflux est le lecteur RSS auto-hébergé à installer sur un petit VPS. Il se compose d’un seul binaire Go et de PostgreSQL. Il prend en charge les API Fever et Google Reader, ce qui permet de le connecter à des applications mobiles tierces. Une mise à niveau consiste en un seul docker compose pull. Choisissez plutôt FreshRSS si vous voulez des extensions et un seul conteneur contenant SQLite.

Cinq lecteurs justifient l’espace disque utilisé sur un VPS : Miniflux, FreshRSS, CommaFeed, yarr et Tiny Tiny RSS. Cette page compare leurs différences concrètes : la mémoire nécessaire à chaque stack, la base de données imposée par chacun, l’API de synchronisation requise par votre application mobile et le comportement lors d’une mise à niveau. Chaque chiffre indiqué ici est soit publié par le projet, soit obtenu par un simple calcul, et le texte précise lequel. Ces chiffres ne constituent pas un benchmark de votre matériel. Mesurez donc votre propre serveur avec docker stats.

Les cinq lecteurs, un paragraphe chacun

Miniflux est écrit en Go et distribué sous la forme d’un binaire unique compilé statiquement. Sa documentation est claire sur son unique dépendance obligatoire : il « fonctionne uniquement avec PostgreSQL ». Il n’existe pas de mode SQLite. Miniflux propose une API REST, une API compatible avec Fever et une API compatible avec Google Reader, ainsi que l’import et l’export OPML. La recherche en texte intégral est confiée à PostgreSQL, ce qui explique notamment pourquoi la base de données est obligatoire.

FreshRSS est écrit en PHP et s’exécute dans un conteneur unique qui contient à la fois le serveur web et l’application. SQLite est la base de données par défaut et ne nécessite aucun service supplémentaire. PostgreSQL et MySQL sont pris en charge pour les installations plus importantes. FreshRSS prend en charge l’API Google Reader et l’API Fever. Son installation est déjà décrite dans notre guide d’installation de FreshRSS sur un VPS, cette page le compare donc aux autres lecteurs sans reprendre la procédure d’installation.

CommaFeed est écrit en Java avec Quarkus et utilise une interface inspirée de Google Reader. La base de données est choisie au moment de la compilation, et non à l’exécution. Le projet publie donc une image par base de données : athou/commafeed:latest-h2 pour la base H2 intégrée, athou/commafeed:latest-postgresql pour PostgreSQL, ainsi que d’autres variantes pour MySQL et MariaDB. Ces tags correspondent à des builds compilés nativement. Le suffixe -jvm désigne les variantes qui s’exécutent sur une JVM. CommaFeed expose une API REST et une API compatible avec Fever. Depuis la version 7.3.0 (août 2026), il propose également une API compatible avec Google Reader.

yarr (yet another rss reader) est un binaire Go unique qui intègre SQLite et ne nécessite aucun conteneur. La commande ./yarr écoute sur 127.0.0.1:7070. Les options sont courtes : -addr 0.0.0.0:7070 -auth alice:secret permet de l’exposer sur le réseau derrière un mot de passe, et -db /data/yarr.db permet de choisir l’emplacement de la base de données. yarr propose une API compatible avec Fever. Sa dernière release taguée est v2.9, publiée en septembre 2026 et vérifiée en octobre 2026, après v2.7 en juin et v2.8 en juillet. Le projet fait donc de nouveau l’objet d’un développement actif.

Tiny Tiny RSS est le plus ancien des cinq lecteurs et le plus lourd à exploiter. Le projet d’origine, hébergé sur tt-rss.org, a été retiré le 1 novembre 2025. Le développement se poursuit dans un fork communautaire à l’adresse github.com/tt-rss/tt-rss, dont la documentation constitue désormais la procédure d’installation officielle. Cette installation comprend quatre services : un conteneur PostgreSQL, un conteneur applicatif PHP-FPM, un conteneur updater séparé qui récupère les flux, et un conteneur nginx en frontal. La documentation indique clairement que « cette installation utilise PostgreSQL ». Tiny Tiny RSS possède sa propre API JSON, utilisée par son client Android et plusieurs applications tierces. Fever n’en fait pas partie.

Besoins en mémoire de chaque stack

Les chiffres ci-dessous sont des budgets, pas des mesures : il s’agit du plafond mémoire sous lequel chaque stack doit rester sur un petit VPS. Le chiffre de CommaFeed correspond à l’exemple publié par le projet, qui limite le conteneur à 256 MB. Les autres plafonds laissent une marge pour le feed fetcher, qui est le composant dont la consommation augmente fortement au début d’un cycle d’actualisation.

[
  {
    "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 reste le plus économe, à 128 MB, car il se compose d’un binaire et d’un fichier SQLite, sans serveur de base de données ni runtime de langage sous-jacent. Miniflux nécessite 320 MB pour 2 conteneurs, dont la plus grande partie est consommée par PostgreSQL, et non par Miniflux. Tiny Tiny RSS est l’exception, avec 640 MB pour 4 conteneurs, car l’application, l’updater, la base de données et le serveur web sont quatre processus distincts, chacun avec son propre heap.

Définissez ces valeurs comme de véritables limites, et non comme de simples objectifs. Limites mémoire dans Docker Compose présente la syntaxe et le comportement d’un conteneur lorsqu’il atteint le plafond. Un conteneur sans limite ne s’arrête pas proprement lorsque le système est à court de mémoire : le kernel choisit un processus à tuer, et ce n’est souvent pas le conteneur à l’origine de la pression mémoire.

Quelle base de données s’impose à chaque lecteur

La base de données est la principale différence opérationnelle entre ces cinq solutions. C’est un choix plus important que les différences d’interface utilisateur, car il détermine votre procédure de sauvegarde et le risque lié aux mises à niveau.

PostgreSQL est requis par Miniflux et par l’installation officielle de Tiny Tiny RSS. Vous bénéficiez d’une véritable recherche en texte intégral et d’écritures concurrentes sûres. En contrepartie, vous devez gérer un deuxième conteneur, un volume et un problème récurrent : les images PostgreSQL officielles ne permettent pas de migrer les données sur place entre versions majeures. La documentation de Tiny Tiny RSS le précise directement et avertit que « les conteneurs PostgreSQL officiels ne prennent pas en charge la migration des données entre versions majeures ». Pour un lecteur de flux, vos options réalistes consistent à conserver l’ancienne version majeure ou à effectuer un dump et une restauration avec pg_dump et pg_restore. PostgreSQL documente également pg_upgrade et les mises à niveau fondées sur la réplication. Ces méthodes justifient leur configuration supplémentaire sur les grandes bases de données lorsque l’interruption de service est importante, ce qui est rarement le cas pour la base d’un lecteur de flux. Prévoyez cette opération tous les un ou deux ans.

SQLite est la base par défaut de FreshRSS et de yarr. Un seul fichier, aucun serveur, aucun port et aucun mot de passe. Elle convient bien à une personne qui gère quelques centaines de flux. Elle ralentit lorsque plusieurs utilisateurs écrivent simultanément ; c’est dans ce cas que l’option PostgreSQL de FreshRSS devient intéressante. yarr a ajouté la prise en charge facultative de PostgreSQL dans la version v2.7, mais le fichier intégré reste la méthode habituelle pour l’exécuter.

H2 est la base intégrée par défaut de CommaFeed. Vous devez y réfléchir avant de commencer, car CommaFeed choisit sa base de données lors de la construction de l’image. Passer ensuite de H2 à PostgreSQL n’est pas une simple modification de configuration. Il faut utiliser une autre image et effectuer vous-même une migration des données. Prenez donc votre décision avant d’avoir accumulé un an d’historique de lecture sur le serveur.

Votre application mobile fonctionnera-t-elle

Cette question est plus importante qu’on ne le pense, car l’interface web ne représente qu’une partie de l’utilisation d’un lecteur de flux.

Miniflux fournit une API compatible avec Fever et une API compatible avec Google Reader. La plupart des clients iOS et Android peuvent donc s’y connecter. FreshRSS fournit les mêmes deux API et précise leur niveau de prise en charge dans sa documentation : l’API Google Reader est la « meilleure », avec une prise en charge complète des fonctionnalités, tandis que l’API Fever offre des « fonctionnalités limitées et un fonctionnement moins efficace ». FreshRSS nécessite également deux étapes avant qu’une application puisse s’y connecter. Activez « Allow API access (required for mobile apps) » dans la section Authentication, puis créez un mot de passe d’API dans le profil utilisateur. Si vous ne créez pas ce mot de passe d’API, l’application affiche une erreur d’authentification alors que la connexion web continue de fonctionner. Ce comportement est déroutant tant que vous ne savez pas où chercher.

CommaFeed fournit désormais les deux API également : il propose depuis longtemps une API compatible avec Fever, et la version 7.3.0 a ajouté une API compatible avec Google Reader pour les applications qui ne prennent pas en charge Fever. Utilisez donc la version 7.3.0 ou une version ultérieure si votre application ne prend en charge que Google Reader. yarr expose uniquement une API compatible avec Fever. Il fonctionne donc avec les clients compatibles avec Fever, mais pas avec les applications qui ne prennent en charge que Google Reader. Tiny Tiny RSS possède sa propre API. Vous devez donc utiliser un client conçu pour ce logiciel. Vérifiez que votre application préférée prend en charge le lecteur avant d’y importer 300 flux.

Un fichier Compose fonctionnel pour un serveur de 1 GB

Voici la stack Miniflux, adaptée de l’exemple Docker du projet lui-même en octobre 2026. Le port publié est lié à loopback, l’adresse d’écoute est définie explicitement et les deux conteneurs ont une limite de mémoire.

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:

Trois lignes de ce fichier sont souvent mal configurées. LISTEN_ADDR=0.0.0.0:8080 répète ce que l’image officielle définit déjà dans son Dockerfile. Avec miniflux/miniflux, c’est donc une mesure de précaution sans effet correctif. Cette configuration est importante si vous construisez votre propre image ou si vous exécutez un binaire fourni par un paquet, car la valeur par défaut documentée du binaire est 127.0.0.1:8080. Un processus lié à loopback dans un conteneur ne peut pas être joint via le port publié. Vous obtenez alors une réinitialisation de la connexion avec un conteneur qui semble sain. Le chemin du volume, /var/lib/postgresql, correspond à PostgreSQL 18. Les versions 17 et antérieures stockent les données dans /var/lib/postgresql/data. Si vous montez le mauvais chemin, le répertoire de données n’est pas du tout placé sur le volume. Toutes les données disparaissent donc lors de la prochaine recréation du conteneur. 127.0.0.1:8080:8080 empêche l’exposition du port sur Internet, car publier un port sans adresse ajoute une règle dans une chaîne qu’ufw ne gère pas. Les ports Docker contournent ufw explique ce mécanisme. Un reverse proxy Traefik permet de placer TLS devant le service.

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

docker compose ps doit afficher les deux services comme actifs, la base de données étant marquée healthy. Lors du premier démarrage, Miniflux journalise ses migrations de schéma. C’est ce que RUN_MIGRATIONS=1 déclenche. docker stats --no-stream affiche la colonne de mémoire utilisée en temps réel. C’est cette valeur qu’il faut comparer aux limites du tableau ci-dessus. Si le conteneur Miniflux redémarre en boucle, consultez son journal. connect: connection refused signifie qu’il a démarré avant que PostgreSQL soit prêt à accepter les connexions. C’est précisément ce que la condition service_healthy empêche. Vérifiez donc que cette condition a été conservée après vos modifications. Si Compose vous est encore peu familier, Les bases de Docker Compose sur un VPS présente d’abord la structure du fichier.

Ce qui ne tiendra pas sur un serveur de 1 GB

Tiny Tiny RSS est le seul service à écarter. Sa stack officielle de quatre services fonctionne sur un VPS de 1 GB si ce VPS n’exécute rien d’autre. Elle ne fonctionne pas à côté d’une autre application utilisant une base de données et d’un reverse proxy. Quatre services signifient quatre ensembles de surcoûts, dont un pour PostgreSQL.

CommaFeed tient, mais uniquement avec l’image H2 et la limite de 256 MB définie dans l’exemple du projet. L’association qui met un petit serveur en difficulté est CommaFeed à côté d’un serveur de base de données distinct. Les variantes d’image -jvm aggravent la situation, car la documentation du projet précise qu’une JVM consomme beaucoup de mémoire par défaut et ne restitue pas la mémoire inutilisée au système d’exploitation. Les tags latest-h2 et latest-postgresql correspondent à des builds natifs. Le projet les recommande pour leur consommation mémoire plus faible. Utilisez-les donc, sauf si vous devez exécuter la JVM.

Lorsqu’un serveur n’a plus de mémoire disponible, le kernel out of memory killer sélectionne un processus et le termine. dmesg -T affiche une ligne comme Out of memory: Killed process 1234 (java), puis le conteneur disparaît simplement de docker compose ps sans message dans le journal de l’application, car celle-ci n’a jamais pu en écrire un.

Comportement des mises à niveau pour chacun

• Miniflux : docker compose pull && docker compose up -d, avec application des migrations de schéma au démarrage lorsque RUN_MIGRATIONS=1 est défini. Le risque de mise à niveau ne vient pas de Miniflux, mais de la version majeure de PostgreSQL utilisée en dessous.
• FreshRSS : récupérez la nouvelle image. Avec SQLite, il n’y a pas de moteur de base de données à mettre à niveau. Les problèmes habituels viennent donc d’extensions tierces qui n’ont pas suivi les évolutions.
• CommaFeed : récupérez la variante d’image correspondant à votre base de données. Le passage de latest-h2 à latest-postgresql ne transfère pas vos données.
• yarr : remplacez le binaire et conservez le fichier de base de données. Des versions sont sorties en juin, juillet et septembre 2026. La v2.9 était la plus récente en octobre 2026. Consultez donc régulièrement la page des releases.
• Tiny Tiny RSS : docker compose pull && docker compose up -d. Le conteneur de l’application se met à jour au démarrage. La FAQ du projet associe les erreurs de mise à jour du schéma à un volume ou à une configuration d’override défectueux. Vérifiez donc ces éléments en premier si une erreur apparaît. Si votre fichier compose récupère encore des images depuis l’ancien projet tt-rss.org, utilisez les images du fork (supahgreg/tt-rss sur Docker Hub ou ghcr.io/tt-rss/tt-rss).

Effectuez un dump de la base de données avant chacune de ces opérations, et non après.

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

Coût d’un intervalle d’actualisation en bande passante

Les chiffres ci-dessous sont un calcul, pas une mesure. Ils supposent 100 feeds, une requête par feed et par intervalle, et 40 KB par réponse. Le trafic réel est inférieur lorsqu’un serveur honore les requêtes conditionnelles, et supérieur lorsque les feeds contiennent le texte intégral des articles.

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

Un intervalle de cinq minutes pour 100 feeds représente 864,000 requêtes et environ 34.6 GB par mois. Une vérification horaire représente 72,000 requêtes et environ 2.9 GB. Miniflux est fourni avec POLLING_FREQUENCY réglé sur 60 minutes. Cette valeur correspond à la dernière ligne du graphique et convient à presque tout le monde. Un article n’arrive pas plus tôt parce que vous le demandez plus souvent.

Les requêtes conditionnelles permettent de maintenir le volume réel sous le résultat du calcul. Un lecteur qui conserve les en-têtes ETag et Last-Modified renvoyés par un feed les renvoie sous la forme If-None-Match et If-Modified-Since. Si le serveur n’a rien de nouveau, il répond 304 Not Modified sans corps de réponse. La connexion entraîne toujours le coût d’une négociation, mais pas celui de la charge utile. Les feeds qui ignorent les requêtes conditionnelles vous renvoient le document complet à chaque fois. Quelques feeds volumineux peuvent donc représenter à eux seuls la majeure partie de votre trafic facturé.

Des vérifications trop fréquentes peuvent également entraîner un blocage. Un serveur qui considère que vous le sollicitez excessivement répond 429 Too Many Requests. Certains sites répondent plutôt 403. Miniflux enregistre la dernière erreur associée au feed concerné. La liste des feeds est donc le premier endroit à consulter lorsqu’un feed cesse de s’actualiser alors que les autres continuent de fonctionner.

Les flux disparaissent, et un fichier OPML n’est pas une sauvegarde

Les flux deviennent obsolètes plus vite que prévu. Des domaines expirent, des sites migrent vers une plateforme sans flux, et une URL qui renvoyait auparavant du XML commence à renvoyer une page d’erreur HTML avec un code 200 OK. Ce dernier cas est le plus délicat : la récupération réussit, l’analyse échoue, et votre lecteur enregistre une erreur d’analyse plutôt qu’une erreur réseau. Une fois par an, triez la liste des flux par date de dernière mise à jour et supprimez ceux qui ne donnent plus aucun signe de vie.

Un export OPML est votre liste d’abonnements. Un fichier OPML standard contient les URL des flux et les noms des dossiers. FreshRSS ajoute son propre espace de noms XML, qui contient également des paramètres propres à chaque flux, comme l’intervalle d’actualisation, les sélecteurs XPath d’extraction et les filtres de lecture automatique. En revanche, aucun export OPML ne contient l’état de lecture, les articles marqués d’une étoile ni le texte des articles que vous avez enregistré. Importez cet OPML dans une nouvelle installation : vous récupérez vos flux, mais tous les articles déjà lus sont de nouveau marqués comme non lus.

La sauvegarde importante est celle de la base de données. Avec PostgreSQL, la commande pg_dump ci-dessus suffit. Pour un lecteur SQLite comme FreshRSS ou yarr, arrêtez le processus qui écrit dans la base et copiez le fichier, ou créez une copie cohérente pendant son fonctionnement avec sqlite3 yarr.db ".backup '/tmp/yarr-backup.db'". Un simple cp d’une base de données en cours d’écriture peut produire un fichier qui ne s’ouvrira plus tard, car la copie capture une écriture incomplète. Transférez ensuite ces fichiers hors du serveur selon un calendrier. C’est le rôle de restic pour sauvegarder un VPS. Restaurez-en au moins un dans un conteneur de test afin de vérifier que la procédure fonctionne.

Un lecteur de flux est l’un des services les moins coûteux à auto-héberger. C’est pourquoi il figure dans toutes les listes de services qui valent la peine d’être auto-hébergés en 2026. Installez une instance SearXNG auto-hébergée à côté : votre lecture et vos recherches restent ainsi sur du matériel que vous contrôlez.

FAQ

Quel lecteur RSS auto-hébergé utilise le moins de mémoire ?

yarr. Il s’agit d’un binaire Go unique avec SQLite intégré. Il n’a donc besoin ni d’un serveur de base de données ni d’un runtime supplémentaire, et une limite de 128 Mo lui suffit largement. Le compromis concerne les fonctionnalités : il prend uniquement en charge l’API Fever, et sa version la plus récente est la v2.9 de septembre 2026. Si vous avez besoin de la prise en charge de l’API Google Reader et de la recherche en texte intégral avec une empreinte mémoire similaire, Miniflux avec PostgreSQL et une limite de 320 Mo constitue un meilleur choix.

Puis-je exécuter un lecteur RSS auto-hébergé sur un VPS de 1 GB ?

Oui. Miniflux avec PostgreSQL tient dans environ 320 Mo lorsque vous définissez mem_limit sur les deux conteneurs. FreshRSS avec SQLite tient dans un seul conteneur. Sur un VPS de 1 GB, évitez la stack officielle Tiny Tiny RSS, qui comprend 4 services, dont son propre PostgreSQL. Définissez toujours des limites mémoire. Un conteneur sans limite sur un serveur saturé peut faire tuer un processus par le kernel, et le processus choisi est souvent la base de données plutôt que l’application réellement en cause.

Lesquels fonctionnent avec les applications RSS iOS et Android ?

Miniflux, FreshRSS et CommaFeed 7.3.0 ou ultérieur prennent en charge une API compatible Fever et une API compatible Google Reader. Presque tous les clients mobiles peuvent donc s’y connecter. yarr propose uniquement l’API Fever. Tiny Tiny RSS utilise sa propre API. Vous devez donc utiliser un client conçu pour ce logiciel. Dans FreshRSS, vous devez également activer l’accès à l’API dans Authentication et définir un mot de passe API distinct dans le profil. Sinon, l’application ne parvient pas à se connecter alors que le site web fonctionne toujours.

Un export OPML constitue-t-il une sauvegarde de mon lecteur RSS ?

Non. OPML permet de reconstituer votre liste d’abonnements. L’export étendu de FreshRSS inclut également les paramètres et les filtres propres à chaque flux. En revanche, l’état de lecture, les éléments favoris et le texte des articles sont stockés dans la base de données. Sauvegardez directement la base de données avec pg_dump pour PostgreSQL, ou avec une commande .backup pour SQLite, puis copiez le résultat hors du serveur.

Miniflux prend-il en charge SQLite ?

Non. La documentation du projet indique qu’il « fonctionne uniquement avec PostgreSQL ». La recherche en texte intégral repose également sur des fonctionnalités de PostgreSQL. Il n’existe donc pas de mode plus léger vers lequel basculer. Si vous voulez un lecteur de flux sans conteneur de base de données, utilisez FreshRSS avec son backend SQLite par défaut ou yarr avec son fichier intégré.