Comment auto-héberger Change Detection en 2026 : navigation via navigateur, alertes et persistance

Un conteneur Change Detection peut être opérationnel alors que la fonction qui intéresse les utilisateurs est défaillante. Avec Change Detection, cette panne invisible vient généralement du fait que les requêtes simples rencontrent des challenges anti-bot ou que le service de navigateur est inaccessible. Ce guide prend comme test d’acceptation le scénario suivant : « surveiller une page statique et une page rendue en JavaScript, introduire une modification contrôlée et recevoir une notification de différence pour chacune », puis construit le déploiement à rebours à partir de ce résultat.

Change Detection joue un rôle précis dans la stack : surveiller les changements de pages sans écrire de scraper. La question à se poser en production n’est donc pas de savoir si le port 5000 répond une fois, mais si l’état, les dépendances et l’adresse publique restent cohérents après un redémarrage, une mise à jour et une restauration.

Séparer Change Detection de ses dépendances

La topologie minimale et responsable de Change Detection comprend un listener privé sur le port 5000, une route d’ingress et une limite d’état documentée. Le contrat réseau de Change Detection repose sur un navigateur distant tel que Playwright pour les pages qui utilisent intensivement JavaScript. Gardez les endpoints privés sur un DNS interne, n’autorisez que les appels sortants nécessaires et attribuez à Change Detection un credential de service avec une portée limitée.

Validez la topologie en demandant à un client vierge de surveiller une page statique et une page rendue en JavaScript, d’introduire une modification contrôlée et de recevoir une notification de différence pour chacune. Pendant l’exécution, surveillez la concurrence des browser workers, l’historique des captures d’écran, la latence des cibles et les challenges anti-bot. Le résultat vous indiquera si la prochaine amélioration doit concerner la mémoire, le stockage, le réseau ou un worker séparé, plutôt que de pousser arbitrairement la taille du conteneur.

Rendre la reprise de Change Detection mesurable

Définissez le recovery point et le recovery time de Change Detection en fonction des définitions de surveillance, de l’historique, des snapshots et des paramètres de notification. Montez /datastore avant le bootstrap, écrivez des données d’exemple sans risque, puis remplacez le conteneur pour prouver que ce chemin est réellement persistant. Un named volume résout la persistance lors d’un redeploy ; il ne protège ni contre une compromission ni contre la perte du serveur.

Créez un environnement de restauration vierge, utilisez la même version d’application épinglée et vérifiez que les définitions de surveillance, l’historique et les cibles de notification sont restaurés, puis que la modification contrôlée est à nouveau détectée. Consignez les commandes, les corrections de propriétaire et le temps écoulé. Le guide des sauvegardes constitue une bonne référence : une sauvegarde est considérée comme fiable après sa restauration, pas après son upload.

Sécuriser Change Detection après le bootstrap

Ne reprenez pas telles quelles les hypothèses de sécurité d’un tutoriel local. Le risque spécifique de Change Detection est d’exposer l’historique des surveillances et les tokens de notification sans authentification. En production, il faut donc protéger cet historique, car il peut contenir des URL privées, des cookies et des credentials de notification.

BASE_URL est une configuration, pas un secret ; gardez sa valeur explicite tout en protégeant les credentials distincts utilisés par Change Detection. Limitez les accès au système de fichiers et au réseau, protégez les endpoints de setup et définissez des limites d’upload, de requête ou d’exécution autour de la concurrence des browser workers, de l’historique des captures d’écran, de la latence des cibles et des challenges anti-bot.

Éléments à réunir avant la mise en production de Change Detection

Avant l’arrivée des vrais utilisateurs, préparez une release worksheet pour Change Detection. Elle doit indiquer l’image épinglée, le port 5000, l’origine canonique, les chemins persistants et le responsable d’un navigateur distant tel que Playwright pour les pages qui utilisent intensivement JavaScript. Joignez le résultat attendu de cette transaction : surveiller une page statique et une page rendue en JavaScript, introduire une modification contrôlée et recevoir une notification de différence pour chacune.

Utilisez cette worksheet après un remplacement normal et après une restauration vierge. La reprise n’est validée que si les définitions de surveillance, l’historique et les cibles de notification sont restaurés et que la modification contrôlée est à nouveau détectée. Réunissez également une courte trace des ressources couvrant la concurrence des browser workers, l’historique des captures d’écran, la latence des cibles et les challenges anti-bot ; conservez-la avec la release afin que les futures évolutions de capacité soient comparées avec la même charge de travail.

Incluez un échec contrôlé : refusez temporairement à l’identité de test l’accès à un navigateur distant tel que Playwright pour les pages qui utilisent intensivement JavaScript. Vérifiez que Change Detection signale le problème à la bonne frontière, rétablissez la condition valide et relancez la transaction. Cela teste la visibilité des erreurs, pas seulement le succès, et évite qu’une interface apparemment saine ne masque un worker, un callback ou une connexion à la base de données défaillant.

Rendre le démarrage de Change Detection reproductible

Une commande minimale est utile lorsqu’elle révèle ce que la plateforme gérera ensuite.

docker run -d \
  --name change-detection \
  --restart unless-stopped \
  -p 127.0.0.1:5000:5000 \
  -v change-detection-data:/datastore \
  -e BASE_URL=https://app.example.com \
  dgtlmoon/changedetection.io:latest

Ici, le port 5000 reste privé sur l’hôte et chaque chemin requis est explicite. Ajoutez les paramètres de connexion validés pour un navigateur distant tel que Playwright pour les pages qui utilisent intensivement JavaScript ; utilisez des noms privés pour les services privés. Vérifiez le démarrage à la fois dans les logs et avec la preuve propre à l’application : surveiller une page statique et une page rendue en JavaScript, introduire une modification contrôlée et recevoir une notification de différence pour chacune. Une fois le fonctionnement vérifié, épinglez la version de l’image afin qu’un remplacement courant ne modifie pas silencieusement le comportement.

Domaines, headers de proxy et port 5000

Traitez l’URL externe de Change Detection comme une configuration qui doit survivre aux redeploys. Commencez par définir BASE_URL et tout endpoint de navigateur avec des adresses accessibles depuis le conteneur ; acheminez ensuite le hostname vers le port 5000 en conservant l’hôte et le scheme d’origine.

La checklist de reachability du déploiement permet de prouver que les requêtes entrent bien dans le conteneur. Une fois ce point établi, le problème connu — les requêtes simples rencontrent des challenges anti-bot ou le service de navigateur est inaccessible — doit être recherché dans Change Detection, son état ou sa charge de travail, plutôt que dans l’automatisation des certificats.

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

Construisez les dashboards autour de la concurrence des browser workers, de l’historique des captures d’écran, de la latence des cibles et des challenges anti-bot. Un graphique CPU dépourvu de ce contexte de charge ne peut pas expliquer pourquoi Change Detection est lent. Ajoutez un contrôle synthetic ou planifié qui tente de surveiller une page statique et une page rendue en JavaScript, introduit une modification contrôlée et reçoit une notification de différence pour chacune avec des données de test sans risque.

Avant une mise à niveau, tenez compte du risque propre à cette application : les versions des images Playwright, les migrations du datastore et les intégrations de notification doivent évoluer ensemble. Restaurez une sauvegarde récente dans un déploiement isolé, exécutez-y les migrations et comparez le comportement. Si les requêtes simples rencontrent des challenges anti-bot ou si le service de navigateur est inaccessible, inspectez d’abord la frontière concernée — origine publique, stockage ou dépendance — avant de modifier des paramètres sans rapport.

Ce que Dockup devrait automatiser pour Change Detection

Un template Dockup doit intégrer l’image, le port 5000, les mounts, le timing de health check, le domaine, le TLS et la transmission des secrets. Dockup doit conserver les parties privées d’un navigateur distant tel que Playwright pour les pages qui utilisent intensivement JavaScript sur le réseau interne et n’exposer aucun port public supplémentaire. Le même déploiement peut cibler des serveurs Dockup ou une capacité rattachée par le client.

Une fois la route active, appliquez le paramètre public et essayez de surveiller une page statique et une page rendue en JavaScript, d’introduire une modification contrôlée et de recevoir une notification de différence pour chacune. Sauvegardez les définitions de surveillance, l’historique, les snapshots et les paramètres de notification, et inscrivez l’exercice de restauration dans le plan d’exploitation ; ces responsabilités de Change Detection restent visibles une fois le provisioning de l’infrastructure terminé.

Foire aux questions

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

Acheminez le conteneur Change Detection sur le port 5000 via une seule origine HTTPS. Le besoin réseau associé est un navigateur distant tel que Playwright pour les pages qui utilisent intensivement JavaScript. Ne considérez pas Change Detection comme prêt tant que vous ne pouvez pas surveiller une page statique et une page rendue en JavaScript, introduire une modification contrôlée et recevoir une notification de différence pour chacune.

Quelles données de Change Detection doivent figurer dans une sauvegarde ?

Rendez /datastore persistant et incluez les définitions de surveillance, l’historique, les snapshots et les paramètres de notification dans le même recovery manifest. Une restauration propre de Change Detection n’est validée que lorsque les définitions de surveillance, l’historique et les cibles de notification sont restaurés et que la modification contrôlée est à nouveau détectée.

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

Utilisez HTTPS pour l’origine publique de Change Detection et gardez le port 5000 sur la route interne. Appliquez correctement le paramètre de Change Detection : définissez BASE_URL et tout endpoint de navigateur avec des adresses accessibles depuis le conteneur. Pour Change Detection, HTTPS protège les credentials ou le contenu utilisateur en transit et garantit la cohérence du comportement client dépendant de l’origine.

Comment tester une mise à niveau de Change Detection ?

Restaurez l’état actuel de Change Detection 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 images Playwright, les migrations du datastore et les intégrations de notification doivent évoluer ensemble. Conservez l’image précédente de Change Detection jusqu’à ce que les limites de migration des données et de rollback soient comprises.