Index du journalDockup / note de terrain
Note / self-host-etherpad

Comment auto-héberger Etherpad en 2026 : pads, plugins et sauvegardes de base de données

Un guide pratique pour auto-héberger Etherpad avec Docker, couvrant les ports, les données persistantes, TLS, la sécurité, les sauvegardes et les problèmes qui empêchent une utilisation en production. Avec des vérifications.

Si vous avez déjà essayé d’auto-héberger Etherpad, cet état frustrant vous est probablement familier : l’interface s’affiche, mais les sessions se déconnectent parce que les timeouts du proxy sont trop courts. Recréer le conteneur résout rarement un désaccord entre les URLs, l’état et les dépendances.

Cette procédure s’appuie sur un critère de réussite concret : ouvrir un pad dans deux navigateurs, le modifier simultanément, examiner les révisions et exporter le résultat dans le format requis. Chaque choix de configuration est évalué par rapport à ce critère, plutôt qu’à la présence d’un badge indiquant que le conteneur est actif.

Choisir la plus petite topologie Etherpad viable

La plus petite topologie Etherpad responsable comprend un listener privé sur le port 9001, une route d’ingress et une limite d’état documentée. Le contrat réseau d’Etherpad repose sur Postgres ou une autre base de données prise en charge pour une utilisation durable multi-utilisateur. Gardez les endpoints privés sur un DNS interne, n’autorisez que les appels sortants nécessaires et attribuez à Etherpad un identifiant de service aux permissions limitées.

Validez la topologie en demandant à un client vierge d’ouvrir un pad dans deux navigateurs, de le modifier simultanément, d’examiner les révisions et d’exporter le résultat dans le format requis. Surveillez les sessions WebSocket, le nombre de révisions, les écritures en base de données et l’exécution des plugins pendant l’opération. Le résultat vous indique si la prochaine amélioration doit concerner la mémoire, le stockage, le réseau ou un worker séparé, au lieu de vous pousser à dimensionner arbitrairement le conteneur.

Construire un conteneur Etherpad remplaçable

Utilisez le conteneur comme un runtime remplaçable, et non comme la source de vérité.

docker run -d \
  --name etherpad \
  --restart unless-stopped \
  -p 127.0.0.1:9001:9001 \
  -v etherpad-data:/opt/etherpad-lite/var \
  -e ADMIN_PASSWORD=replace-with-a-long-random-value \
  etherpad/etherpad:latest

Ajoutez les paramètres de connexion validés pour Postgres ou une autre base de données prise en charge pour une utilisation durable multi-utilisateur ; utilisez des noms privés pour les services privés. Inspectez l’utilisateur du conteneur, les chemins accessibles en écriture et le listener associé avant de l’exposer. Exécutez l’action complète — ouvrir un pad dans deux navigateurs, le modifier simultanément, examiner les révisions et exporter le résultat dans le format requis — puis enregistrez la référence exacte de l’image ayant produit ce résultat.

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

Le navigateur, le client API et Etherpad doivent utiliser une même origin. Pour cela, définissez l’URL publique et activez la prise en charge de WebSocket par le proxy. Conservez l’hôte et le protocole d’origine tout en gardant le port 9001 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 sessions se déconnectent parce que les timeouts du proxy sont trop courts. Seule la première situation se corrige avec des changements au niveau de l’ingress ; la seconde nécessite d’examiner les logs, l’état ou la charge de travail d’Etherpad.

Concevoir la restauration d’Etherpad avant le lancement

Protégez l’état d’Etherpad avant d’optimiser son conteneur. L’ensemble requis comprend la base de données, les plugins téléversés et les paramètres. Montez /opt/etherpad-lite/var avant le bootstrap, écrivez des données d’exemple inoffensives et remplacez le conteneur pour vérifier que ce chemin est réellement persistant. Si plusieurs stores doivent rester cohérents, documentez l’ordre dans lequel les écritures sont suspendues et les sauvegardes effectuées.

Conservez des copies en dehors du serveur de déploiement et chiffrez les éléments contenant des identifiants ou du contenu privé. La récupération est réussie lorsque les pads, les auteurs, les révisions et les plugins sont restaurés et que les modifications concurrentes convergent toujours. La différence entre un mount persistant et une copie indépendante est expliquée dans stockage persistant et snapshots.

Choisir la limite de confiance d’Etherpad

Fermez la fenêtre de bootstrap dès que le premier administrateur de confiance existe. Le piège concret d’Etherpad consiste à livrer un mot de passe administrateur connu ou à laisser tout le monde modifier les pads ; la limite plus sûre consiste à définir un véritable mot de passe administrateur, à décider qui peut créer des pads et à ne pas considérer une URL de pad difficile à deviner comme privée.

Remplacez immédiatement l’exemple de valeur de ADMIN_PASSWORD, stockez-le en dehors de l’image et faites-le tourner comme un identifiant administrateur s’il est exposé. Le réseau privé doit transporter les identifiants des dépendances, et les rôles dans Etherpad doivent accorder l’action utile la plus limitée possible. Excluez des logs courants les corps de requête sensibles et les réponses des providers.

Mettre Etherpad à niveau sans deviner

Observez le travail effectué par Etherpad : sessions WebSocket, nombre de révisions, écritures en base de données et exécution des plugins. Définissez les limites avec une marge suffisante pour ce travail et évitez une liveness probe qui entrerait en concurrence avec lui. La vérification opérateur doit toujours tenter, selon un calendrier défini, d’ouvrir un pad dans deux navigateurs, de le modifier simultanément, d’examiner les révisions et d’exporter le résultat dans le format requis.

Pour les mises à jour, souvenez-vous que les versions des plugins Etherpad, la syntaxe des paramètres et les migrations de base de données doivent être testées ensemble. Déployez la candidate sur une copie restaurée et répétez le test connu. Si les sessions se déconnectent parce que les timeouts du proxy sont trop courts, utilisez les logs du runtime et la requête réseau réelle pour déterminer quelle hypothèse a changé.

Ce qui doit réussir avant l’arrivée de vraies données Etherpad

Pour Etherpad, définissez une transaction de référence avant le lancement : ouvrir un pad dans deux navigateurs, le modifier simultanément, examiner les révisions et exporter le résultat dans le format requis. Placez ses prérequis, sa réponse attendue et ses étapes de nettoyage sous contrôle de version, sans valeurs secrètes. Épinglez l’image utilisée pour établir cette référence.

Utilisez cette transaction pour valider un remplacement et une restauration indépendante. Le service restauré n’est acceptable que lorsque les pads, les auteurs, les révisions et les plugins sont restaurés et que les modifications concurrentes convergent toujours. Dans le même temps, surveillez les sessions WebSocket, le nombre de révisions, les écritures en base de données et l’exécution des plugins, puis transformez la partie la plus lente ou la plus contrainte en alerte de niveau de service.

La validation doit également inclure un cas négatif : refusez temporairement à l’identité de test l’accès à Postgres ou à une autre base de données prise en charge pour une utilisation durable multi-utilisateur. Vérifiez qu’Etherpad 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 empêche un endpoint de health check superficiel de devenir la seule preuve disponible en production.

Déployer Etherpad sur Dockup sans perdre ses limites

Pour Etherpad, Dockup est particulièrement utile à la frontière entre une image et un service durable. Il conserve la route vers le port 9001, TLS, les valeurs secrètes et le stockage lors des remplacements de conteneur, que le compute appartienne à Dockup ou à votre serveur connecté.

Terminez avec la connaissance de l’application : définissez l’URL publique et activez la prise en charge de WebSocket par le proxy ; connectez et testez Postgres ou une autre base de données prise en charge pour une utilisation durable multi-utilisateur ; puis exécutez cette vérification : ouvrir un pad dans deux navigateurs, le modifier simultanément, examiner les révisions et exporter le résultat dans le format requis. Conservez le résultat comme contrôle de déploiement afin que la prochaine mise à jour de l’image soit évaluée sur son comportement plutôt que sur l’état du conteneur.

Foire aux questions

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

Routez le conteneur Etherpad sur le port 9001 via une origin HTTPS unique. La dépendance réseau associée est Postgres ou une autre base de données prise en charge pour une utilisation durable multi-utilisateur. Ne considérez pas Etherpad comme prêt tant que vous ne pouvez pas ouvrir un pad dans deux navigateurs, le modifier simultanément, examiner les révisions et exporter le résultat dans le format requis.

Quelles données Etherpad doivent figurer dans une sauvegarde ?

Rendez /opt/etherpad-lite/var persistant et incluez la base de données, les plugins téléversés et les paramètres dans le même manifest de restauration. Une restauration Etherpad propre est validée uniquement lorsque les pads, les auteurs, les révisions et les plugins sont restaurés et que les modifications concurrentes convergent toujours.

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

Utilisez HTTPS pour l’origin Etherpad publique et gardez le port 9001 sur la route interne. Appliquez correctement le paramètre Etherpad : définissez l’URL publique et activez la prise en charge de WebSocket par le proxy. Pour Etherpad, HTTPS protège les identifiants ou le contenu utilisateur pendant leur transport et garantit un comportement cohérent du client vis-à-vis de l’origin.

Comment tester une mise à niveau d’Etherpad ?

Restaurez l’état actuel d’Etherpad dans un déploiement isolé, appliquez la version candidate et répétez sa transaction d’acceptation. Soyez particulièrement attentif, car les versions des plugins Etherpad, la syntaxe des paramètres et les migrations de base de données doivent être testées ensemble. Conservez l’image Etherpad précédente jusqu’à ce que les limites de migration des données et de rollback soient comprises.