Comment auto-héberger FreshRSS en 2026 : actualisation des flux, API mobile et sauvegardes

Un déploiement FreshRSS défaillant ne plante pas toujours. Il peut afficher une page de connexion alors que les flux ne sont jamais actualisés parce que cron est désactivé ou que le DNS sortant échoue. Commencez plutôt par une vérification de bout en bout : ajoutez des flux, lancez une actualisation planifiée, marquez un élément comme lu et synchronisez cet état via l’API mobile.

Cette vérification correspond à la fonction répertoriée de FreshRSS : un lecteur RSS auto-hébergé avec une API mobile compatible. Elle révèle également plus tôt les dépendances manquantes, les mauvaises hypothèses concernant le proxy et les données éphémères qu’un simple probe de disponibilité.

Cartographier FreshRSS avant de toucher à Docker

Séparez quatre aspects de FreshRSS : l’ingress, le listener sur le port 80, l’état durable et les services de support ou la capacité locale. L’exigence externe de FreshRSS concerne l’actualisation planifiée des flux et l’accès sortant aux hôtes qui les fournissent. Testez le DNS sortant, TLS et le comportement du fournisseur sans publier un autre service entrant.

Exécutez la transaction de référence — ajouter des flux, lancer une actualisation planifiée, marquer un élément comme lu et synchroniser cet état via l’API mobile — avant de considérer cette séparation comme terminée. Mesurez le nombre de flux, l’intervalle d’actualisation, les éditeurs lents, les écritures en base de données et les clients API simultanés, puis conservez le résultat avec l’enregistrement du déploiement. Vous disposez ainsi à la fois d’un critère d’acceptation et de la première référence de capacité.

Sauvegarder l’état que FreshRSS ne peut pas recréer

Créez un manifeste de récupération pour FreshRSS : données, extensions et base de données sélectionnée. Montez /var/www/FreshRSS/data avant le bootstrap, écrivez des données d’exemple inoffensives et remplacez le conteneur pour vérifier que ce chemin est réellement persistant. Vérifiez dès maintenant le propriétaire et l’espace disponible, car un chemin monté mais non accessible en écriture se comporte comme s’il n’y avait aucune persistance.

Sauvegardez vers un failure domain distinct du serveur en fonctionnement. Recréez FreshRSS à partir de son image épinglée et vérifiez que les abonnements, catégories, états de lecture, filtres et extensions sont restaurés et que l’actualisation planifiée récupère un nouvel élément. Le guide des volumes persistants vous aide à transformer cet exercice en politique de snapshots et de rétention.

Choisir la trust boundary de FreshRSS

Modélisez les actions effectuées par FreshRSS, pas seulement son formulaire de connexion. Ici, l’erreur la plus risquée consiste à laisser la configuration initiale ou l’utilisateur par défaut accessible sur un hôte public. Mettez en place cette limite : terminez la configuration en privé, protégez les mots de passe de l’API et configurez les trusted proxies avant d’activer la synchronisation mobile.

CRON_MIN contrôle le comportement, pas la confidentialité ; validez son type et sa valeur, et stockez les véritables identifiants FreshRSS séparément. Ne corrigez pas une erreur de permission en exécutant le conteneur en tant que root ou en montant largement l’hôte. Les limites de ressources font également partie de la conception de sécurité lorsque le nombre de flux, l’intervalle d’actualisation, les éditeurs lents, les écritures en base de données et les clients API simultanés peuvent être déclenchés par les utilisateurs.

Ce qui doit réussir avant l’arrivée des vraies données FreshRSS

Transformez le smoke test FreshRSS en commande de release reproductible ou en runbook court. Sa sortie doit démontrer le résultat suivant : ajouter des flux, lancer une actualisation planifiée, marquer un élément comme lu et synchroniser cet état via l’API mobile. Enregistrez la version de l’application, le digest du conteneur, le hostname de routage et l’identifiant des données de test avec le résultat.

Exécutez la même vérification après un remplacement courant du conteneur et après avoir restauré les données, les extensions et la base de données sélectionnée ailleurs. La restauration a réussi lorsque les abonnements, catégories, états de lecture, filtres et extensions sont revenus et que l’actualisation planifiée récupère un nouvel élément. Comparez le temps d’exécution et la consommation liés au nombre de flux, à l’intervalle d’actualisation, aux éditeurs lents, aux écritures en base de données et aux clients API simultanés ; une variation importante mérite une investigation, même si l’action finale réussit toujours.

Exercez ensuite une défaillance sans danger : refusez temporairement le chemin de test utilisé par l’actualisation planifiée des flux et l’accès sortant aux hôtes qui les fournissent. Vérifiez que FreshRSS signale le problème et revient à la normale sans modifications manuelles destructrices. Ne conservez que l’extrait de log nécessaire, après l’avoir expurgé. Cette validation en quatre parties couvre le démarrage, la persistance, la récupération et la gestion des défaillances.

Une base Docker pour FreshRSS

Un lancement adapté à la production est volontairement sobre : état nommé, port explicite et aucun secret dans l’image.

docker run -d \
  --name freshrss \
  --restart unless-stopped \
  -p 127.0.0.1:80:80 \
  -v freshrss-data:/var/www/FreshRSS/data \
  -e CRON_MIN=15 \
  freshrss/freshrss:latest

L’exemple constitue une base, et non une stack complète de services de support. Autorisez et vérifiez le chemin sortant ou côté client requis pour l’actualisation planifiée des flux et l’accès sortant aux hôtes qui les fournissent. Vérifiez les montages effectifs et le listener, puis essayez d’ajouter des flux, de lancer une actualisation planifiée, de marquer un élément comme lu et de synchroniser cet état via l’API mobile. Épinglez l’image fonctionnelle avant le prochain redémarrage.

Empêcher le succès du proxy de masquer une défaillance de l’application

Le navigateur, le client API et FreshRSS doivent utiliser une même origin. Pour y parvenir, déclarez les trusted proxies et la base HTTPS canonique. Préservez l’hôte et le protocole d’origine tout en maintenant le port 80 indisponible comme adresse publique concurrente.

Le guide de dépannage d’un site inaccessible aide à distinguer une route injoignable d’une application qui répond. Cette distinction est importante ici : les flux ne sont jamais actualisés parce que cron est désactivé ou que le DNS sortant échoue. Seul le premier problème se corrige par des modifications de l’ingress ; le second nécessite d’examiner les logs FreshRSS, l’état ou la charge de travail.

Surveiller la charge de travail, pas seulement le conteneur

Observez le travail effectué par FreshRSS : nombre de flux, intervalle d’actualisation, éditeurs lents, écritures en base de données et clients API simultanés. Définissez les limites avec une marge suffisante pour cette charge et évitez un liveness probe qui entre en concurrence avec elle. La vérification opérateur doit toujours tenter d’ajouter des flux, de lancer une actualisation planifiée, de marquer un élément comme lu et de synchroniser cet état via l’API mobile selon une fréquence définie.

Pour les mises à jour, gardez à l’esprit que les extensions, les migrations de base de données et les changements de feed parser peuvent affecter les actualisations même lorsque la connexion fonctionne encore. Déployez la version candidate sur une copie restaurée et répétez le test de référence. Si les flux ne sont jamais actualisés parce que cron est désactivé ou que le DNS sortant échoue, utilisez les logs runtime et la requête réseau réelle pour déterminer quelle hypothèse a changé.

Déplacer le travail d’infrastructure reproductible vers Dockup

Le déploiement FreshRSS en un clic de Dockup doit rendre le remplacement sûr : la route continue de cibler le port 80, les secrets ne sont pas intégrés à l’image et les chemins persistants sont restaurés sur le nouveau conteneur. Le même déploiement peut s’exécuter sur le compute Dockup ou sur une machine attachée.

Terminez le travail spécifique à l’application en autorisant et en vérifiant l’actualisation planifiée des flux et l’accès sortant aux hôtes qui les fournissent, en appliquant l’adresse publique canonique et en exécutant cette vérification d’acceptation : ajouter des flux, lancer une actualisation planifiée, marquer un élément comme lu et synchroniser cet état via l’API mobile. Ajoutez le résultat de la restauration au runbook avant l’arrivée des vrais utilisateurs.

Questions fréquemment posées

De quoi FreshRSS a-t-il besoin pour un déploiement en production ?

Faites passer le conteneur FreshRSS sur le port 80 via une seule origin HTTPS. L’exigence de distribution externe concerne l’actualisation planifiée des flux et l’accès sortant aux hôtes qui les fournissent. Ne considérez pas FreshRSS comme prêt tant que vous ne pouvez pas ajouter des flux, lancer une actualisation planifiée, marquer un élément comme lu et synchroniser cet état via l’API mobile.

Quelles données FreshRSS doivent être incluses dans une sauvegarde ?

Conservez /var/www/FreshRSS/data et incluez les données, les extensions et la base de données sélectionnée dans le même manifeste de récupération. Une restauration FreshRSS vierge n’est validée que lorsque les abonnements, catégories, états de lecture, filtres et extensions sont revenus et que l’actualisation planifiée récupère un nouvel élément.

FreshRSS nécessite-t-il HTTPS derrière un reverse proxy ?

Utilisez HTTPS pour l’origin publique FreshRSS et conservez le port 80 sur la route interne. Appliquez correctement le paramètre FreshRSS : déclarez les trusted proxies et la base HTTPS canonique. Pour FreshRSS, HTTPS protège les identifiants ou le contenu utilisateur en transit et garantit un comportement cohérent des clients dépendant de l’origin.

Comment tester une mise à niveau de FreshRSS ?

Restaurez l’état actuel de FreshRSS dans un déploiement isolé, appliquez la version candidate et répétez sa transaction d’acceptation. Soyez particulièrement attentif, car les extensions, les migrations de base de données et les changements de feed parser peuvent affecter les actualisations même lorsque la connexion fonctionne encore. Conservez l’image FreshRSS précédente jusqu’à ce que les limites de migration des données et de rollback soient comprises.