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 est distribué sous la forme d’un binaire unique compilé statiquement. Sa documentation est claire sur l’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’importation et l’exportation OPML. La recherche en texte intégral est prise en charge par 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, donc cette page le compare sans reprendre cette procédure.

CommaFeed est écrit en Java et s’exécute sur Quarkus, avec une interface qui reprend le fonctionnement 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. CommaFeed expose une API REST et une API compatible avec Fever.

yarr (yet another rss reader) est un binaire Go unique avec SQLite intégré. Il ne nécessite aucun conteneur. La commande simple ./yarr écoute sur 127.0.0.1:7070. Les options sont courtes : -addr 0.0.0.0:7070 -auth alice:secret l’expose 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 marquée est v2.8, publiée en juillet 2024 et vérifiée en août 2026. Considérez-le donc comme un logiciel terminé plutôt que comme un projet activement développé.

Tiny Tiny RSS est le plus ancien des cinq et le plus lourd à déployer. La configuration Docker officielle 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 configuration utilise PostgreSQL ». Tiny Tiny RSS possède sa propre API JSON, utilisée par son client Android et par 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 chaque lecteur vous impose

La base de données est la principale différence opérationnelle entre ces cinq lecteurs. C’est une décision plus importante que les différences d’interface utilisateur, car elle détermine votre procédure de sauvegarde et le risque lors des mises à niveau.

PostgreSQL est requis par Miniflux et par l’installation officielle de Tiny Tiny RSS. Vous bénéficiez ainsi 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 peuvent pas migrer les données entre versions majeures sur place. 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 ». Vos options réalistes sont de conserver l’ancienne version majeure ou d’effectuer un dump et une restauration avec pg_dump et pg_restore. 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 fonctionne bien pour une personne qui suit quelques centaines de flux. Elle ralentit lorsque plusieurs utilisateurs écrivent simultanément. C’est alors 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 cette décision avant d’avoir une année d’historique de lecture dans le système.

L’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 propose 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 propose les deux mêmes API et précise leur niveau de prise en charge dans sa documentation : l’API Google Reader est « best », avec la prise en charge complète des fonctionnalités, tandis que l’API Fever offre des « limited features and less efficient » comportements. FreshRSS nécessite également deux étapes avant qu’une application puisse s’authentifier. 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. Le problème est déroutant tant que vous ne savez pas où chercher.

CommaFeed et yarr exposent tous deux une API compatible avec Fever, et aucune autre. Ils fonctionnent donc avec les clients compatibles avec Fever, mais pas avec les applications qui parlent uniquement à Google Reader. Tiny Tiny RSS possède sa propre API. Vous devez donc utiliser un client conçu pour ce logiciel. Vérifiez que l’application de votre choix 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 fourni par le projet en août 2026. Le port publié est lié à l’interface 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 posent généralement problème. LISTEN_ADDR=0.0.0.0:8080 est défini parce que la valeur par défaut documentée du binaire est 127.0.0.1:8080. Un processus lié à l’interface loopback dans un conteneur n’est pas accessible via le port publié. Vous obtenez donc une réinitialisation de la connexion alors que le conteneur semble fonctionner. 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. Monter le mauvais chemin signifie que le répertoire de données ne se trouve pas du tout sur le volume. Toutes les données disparaissent donc à la prochaine recréation du conteneur. 127.0.0.1:8080:8080 maintient le port hors de l’Internet public, car publier un port sans préciser d’adresse ajoute une règle dans une chain que 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, avec la base de données marquée healthy. Au premier démarrage, Miniflux journalise ses migrations de schéma. C’est ce que déclenche RUN_MIGRATIONS=1. 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 la condition est toujours présente après vos modifications. Si Compose est nouveau pour vous, Les bases de Docker Compose sur un VPS présente d’abord la structure du fichier.

Ce qui ne tient pas sur un serveur de 1 GB

Tiny Tiny RSS est le service à éviter. Sa stack officielle de quatre services fonctionne sur un VPS de 1 GB lorsque ce VPS n’exécute rien d’autre. Elle ne fonctionne pas sur ce même VPS à côté d’une autre application utilisant une base de données et d’un reverse proxy. Quatre services impliquent quatre ensembles de ressources nécessaires, dont PostgreSQL.

CommaFeed tient, mais uniquement avec l’image H2 et la limite de 256 MB définie dans l’exemple fourni par le projet. Ce qui fait dépasser les capacités d’un petit serveur, c’est l’association d’une JVM et d’un serveur de base de données distinct, car la JVM utilise toute la mémoire disponible que vous lui laissez. La documentation de CommaFeed indique que -Xmx256m constitue une limite stricte et présente OpenJ9 comme « une alternative plus économe en mémoire à la JVM HotSpot ». Cela indique où part la mémoire.

Lorsqu’un serveur n’a plus de mémoire, l’out of memory killer du kernel sélectionne un processus et le termine. dmesg -T affiche alors une ligne telle que Out of memory: Killed process 1234 (java), puis le conteneur disparaît simplement de docker compose ps sans message dans le log 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 lors de la 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. Comme aucune version n’est sortie depuis v2.8 en juillet 2024, vérification effectuée en août 2026, il n’y a généralement rien à mettre à niveau.
• Tiny Tiny RSS : docker compose pull && docker compose up -d. Les migrations de schéma s’exécutent automatiquement. L’interface vous redirige vers un écran de migration lorsqu’une confirmation est nécessaire.

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 statut 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 signe de vie.

Un export OPML est votre liste d’abonnements. Il contient les URL des flux et les noms des dossiers. Il ne contient pas l’état de lecture, les articles marqués d’une étoile, les paramètres propres à chaque flux, les règles de filtrage ni le texte des articles que vous avez enregistré. Importez cet OPML dans une nouvelle installation : vous récupérerez vos flux, mais tous les articles que vous avez déjà lus seront de nouveau marqués comme non lus.

La sauvegarde importante est celle de la base de données. Pour 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 ensuite, car la copie capture une écriture incomplète. Transférez ensuite ces fichiers hors du serveur selon une planification régulière. C’est le rôle des sauvegardes restic sur un VPS. Restaurez-en une dans un conteneur de test au moins une fois, 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 des services qui méritent d’être auto-hébergés en 2026. Installez une instance SearXNG auto-hébergée à côté : votre lecture comme vos recherches resteront 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 de langage supplémentaire, et une limite de 128 Mo lui suffit largement. Le compromis concerne la maintenance et les fonctionnalités : sa dernière release est la v2.8, publiée en juillet 2024, et il prend uniquement en charge l’API Fever. Si vous recherchez un projet activement développé avec une empreinte 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. Lorsqu’un conteneur sans limite s’exécute sur une machine saturée, le kernel tue un processus. Il s’agit souvent de la base de données plutôt que de l’application responsable du problème.

Lesquels sont compatibles avec les applications RSS iOS et Android ?

Miniflux et FreshRSS prennent en charge une API compatible Fever et une API compatible Google Reader. Presque tous les clients mobiles peuvent donc s’y connecter. CommaFeed et yarr proposent 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 peut pas se connecter alors que le site web continue de fonctionner.

Une exportation OPML constitue-t-elle une sauvegarde de mon lecteur RSS ?

Non. OPML contient les URL des flux et les dossiers. Il permet donc de reconstruire votre liste d’abonnements, mais rien de plus. L’état de lecture, les éléments marqués, les règles de filtrage 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 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é.