Comment auto-héberger Wallabag en 2026 : imports, base de données et tâches en arrière-plan

La démonstration Wallabag la plus simple prouve qu’un processus écoute sur le port 80. La production exige des preuves plus solides. Elle doit réussir ce scénario même après le remplacement du conteneur : enregistrer un article standard et une page difficile, lancer la récupération en arrière-plan, synchroniser un client mobile et rechercher du contenu archivé.

Wallabag est déployé dans un objectif précis : constituer une archive de lecture différée qui élimine le superflu des pages. Le piège de déploiement le plus courant vient du fait que les ressources ou les redirections de connexion utilisent HTTP parce que la variable de domaine est incorrecte. La gestion de l’URL publique et la persistance de l’état doivent donc recevoir la même attention que le démarrage de l’image.

Transformer la commande locale en service inspectable

La commande suivante rend la limite du conteneur visible sans prétendre provisionner tous les services externes.

docker run -d \
  --name wallabag \
  --restart unless-stopped \
  -p 127.0.0.1:80:80 \
  -v wallabag-data:/var/www/wallabag/data \
  -e SYMFONY__ENV__DOMAIN_NAME=https://app.example.com \
  wallabag/wallabag:latest

Avant d’ouvrir l’accès entrant, inspectez l’environnement résolu, les montages et le processus en écoute. Ajoutez les paramètres de connexion validés pour Postgres ou MariaDB, Redis et les workers d’import planifiés ; utilisez des noms privés pour les services privés. Un démarrage réussi ne se termine que lorsque vous pouvez enregistrer un article standard et une page difficile, lancer la récupération en arrière-plan, synchroniser un client mobile et rechercher du contenu archivé, et non lorsque docker ps affiche Up.

Ce dont Wallabag dépend

Délimitez trois zones autour de Wallabag : l’accès entrant vers le port 80, l’état persistant et les prérequis de support. Le conteneur est remplaçable, mais les deux autres éléments doivent avoir des responsables clairement désignés. Le contrat réseau de Wallabag repose sur Postgres ou MariaDB, Redis et des workers d’import planifiés. Conservez les endpoints privés sur un DNS interne, n’autorisez que les appels sortants nécessaires et attribuez à Wallabag un identifiant de service aux permissions limitées.

Le schéma est complet lorsqu’un client vierge peut enregistrer un article standard et une page difficile, lancer la récupération en arrière-plan, synchroniser un client mobile et rechercher du contenu archivé. Collectez les données de durée et de ressources pour la récupération des pages, le traitement par l’analyseur, les téléchargements d’images, les files d’attente et la croissance de la base de données. Si la transaction échoue, la première limite qui ne se comporte pas comme documenté indique s’il faut examiner le routage, la capacité locale ou un service de support.

Sécuriser Wallabag après l’amorçage

N’héritez pas des hypothèses de sécurité d’un tutoriel local. Le problème spécifique à Wallabag consiste notamment à conserver les identifiants par défaut ou à ignorer la configuration du proxy de confiance. En production, supprimez donc les identifiants par défaut, protégez les tokens d’import et configurez les proxies de confiance avant d’exposer le lecteur.

SYMFONY__ENV__DOMAIN_NAME est un paramètre de configuration, pas un secret ; gardez sa valeur explicite tout en protégeant les identifiants distincts utilisés par Wallabag. Limitez les accès au système de fichiers et au réseau, protégez les endpoints de configuration et définissez des limites d’upload, de requête ou d’exécution autour de la récupération des pages, du traitement par l’analyseur, des téléchargements d’images, des files d’attente et de la croissance de la base de données.

Rendre l’origine publique non ambiguë

Exposez un seul hostname HTTPS pour Wallabag ; gardez le port 80 brut privé. Définissez le nom de domaine sur l’URL HTTPS finale. Les navigateurs et les clients d’API ne pourront ainsi pas découvrir deux adresses concurrentes.

Depuis un client vierge, exécutez la transaction de référence et inspectez la première requête qui échoue. Utilisez le guide consacré aux domaines personnalisés lorsque le DNS ou le TLS est incorrect. Considérez que « les ressources ou les redirections de connexion utilisent HTTP parce que la variable de domaine est incorrecte » relève d’un diagnostic applicatif distinct une fois la route validée.

Séparer les conteneurs remplaçables des données durables

L’ensemble nécessaire à la récupération comprend la base de données, les images, le contenu importé et la configuration. Montez /var/www/wallabag/data avant l’amorçage, écrivez des données d’exemple sans danger et remplacez le conteneur pour vérifier que ce chemin est réellement persistant. Un volume protège les données contre le remplacement du conteneur, mais pas contre la perte de l’hôte, une suppression accidentelle ou une corruption au niveau applicatif.

Effectuez des sauvegardes adaptées à la source de données : utilisez des dumps logiques pour les bases de données actives lorsque c’est nécessaire et ne copiez les fichiers qu’à partir d’un état cohérent. Conservez une copie chiffrée hors de l’hôte Wallabag. Le critère d’acceptation d’une restauration est précis : les articles, tags, annotations, utilisateurs et tokens d’API réapparaissent et le client mobile se synchronise. Le guide des sauvegardes restaurées avec succès explique pourquoi la réussite d’un job ne suffit pas.

Les preuves à réunir avant la mise en production de Wallabag

Pour Wallabag, définissez une transaction de référence avant le lancement : enregistrer un article standard et une page difficile, lancer la récupération en arrière-plan, synchroniser un client mobile et rechercher du contenu archivé. Placez ses prérequis, la réponse attendue et les étapes de nettoyage sous contrôle de version, sans valeurs secrètes. Épinglez l’image utilisée pour établir cette référence.

Utilisez la transaction pour valider un remplacement et une restauration indépendante. Le service restauré n’est acceptable que lorsque les articles, tags, annotations, utilisateurs et tokens d’API réapparaissent et que le client mobile se synchronise. En parallèle, observez la récupération des pages, le traitement par l’analyseur, les téléchargements d’images, les files d’attente et la croissance de la base de données, puis transformez la partie la plus lente ou la plus contrainte en alerte de niveau de service.

Le contrôle doit également inclure un cas négatif : refusez temporairement à l’identité de test l’accès à Postgres ou MariaDB, Redis et aux workers d’import planifiés. Vérifiez que Wallabag produit une erreur exploitable tout en préservant les données, rétablissez la configuration valide et répétez la transaction de référence. Conserver les deux résultats évite qu’un endpoint de health check superficiel devienne l’unique preuve de bon fonctionnement en production.

Exploiter Wallabag en fonction de son véritable goulot d’étranglement

Construisez des dashboards autour de la récupération des pages, du traitement par l’analyseur, des téléchargements d’images, des files d’attente et de la croissance de la base de données. Un graphique du CPU sans le contexte de cette charge ne peut pas expliquer pourquoi Wallabag est lent. Ajoutez un check synthétique ou planifié qui tente d’enregistrer un article standard et une page difficile, de lancer la récupération en arrière-plan, de synchroniser un client mobile et de rechercher du contenu archivé à l’aide de données de test sans danger.

Avant une mise à niveau, tenez compte de ce risque propre à l’application : les migrations de Wallabag, le comportement de l’analyseur et la configuration des workers doivent être testés avec des pages enregistrées représentatives. Restaurez une sauvegarde récente dans un déploiement isolé, exécutez-y les migrations et comparez le comportement. Si les ressources ou les redirections de connexion utilisent HTTP parce que la variable de domaine est incorrecte, examinez la limite concernée — origine publique, stockage ou dépendance — avant de modifier des paramètres sans rapport.

Utiliser Dockup pour la couche plateforme

Pour Wallabag, Dockup peut créer la route et le certificat TLS, préserver les montages, distribuer les secrets et placer Postgres ou MariaDB, Redis et les workers d’import planifiés sur un réseau privé, tout en déployant sur Dockup ou sur des serveurs rattachés.

Le contrôle de mise en production reste la transaction Wallabag concrète : enregistrer un article standard et une page difficile, lancer la récupération en arrière-plan, synchroniser un client mobile et rechercher du contenu archivé. Vérifiez également la restauration : les articles, tags, annotations, utilisateurs et tokens d’API réapparaissent et le client mobile se synchronise. Ces deux contrôles montrent si le déploiement fonctionne et s’il peut être récupéré.

Foire aux questions

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

Acheminez le conteneur Wallabag sur le port 80 via une seule origine HTTPS. Le prérequis réseau de support comprend Postgres ou MariaDB, Redis et des workers d’import planifiés. Ne considérez pas Wallabag comme prêt tant que vous ne pouvez pas enregistrer un article standard et une page difficile, lancer la récupération en arrière-plan, synchroniser un client mobile et rechercher du contenu archivé.

Quelles données Wallabag doivent figurer dans une sauvegarde ?

Rendez /var/www/wallabag/data persistant et incluez la base de données, les images, le contenu importé et la configuration dans le même manifeste de récupération. Une restauration Wallabag propre n’est validée que lorsque les articles, tags, annotations, utilisateurs et tokens d’API réapparaissent et que le client mobile se synchronise.

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

Utilisez HTTPS pour l’origine publique de Wallabag et conservez le port 80 sur la route interne. Appliquez correctement le paramètre Wallabag : définissez le nom de domaine sur l’URL HTTPS finale. Pour Wallabag, HTTPS protège les identifiants ou le contenu utilisateur en transit et garantit un comportement cohérent des clients vis-à-vis de l’origine.

Comment tester une mise à niveau de Wallabag ?

Restaurez l’état actuel de Wallabag dans un déploiement isolé, appliquez la version candidate et répétez sa transaction d’acceptation. Soyez particulièrement attentif, car les migrations de Wallabag, le comportement de l’analyseur et la configuration des workers doivent être testés avec des pages enregistrées représentatives. Conservez l’image précédente de Wallabag jusqu’à ce que les limites de migration des données et de rollback soient comprises.