Change Detection zelf hosten in 2026: browser-fetching, meldingen en persistentie

Een Change Detection-container kan groen zijn terwijl de taak die gebruikers belangrijk vinden niet werkt. Bij Change Detection is die verborgen fout meestal dat gewone requests bot challenges tegenkomen of dat de browser service onbereikbaar is. In deze handleiding gebruiken we “één statische pagina en één JavaScript-gerenderde pagina monitoren, een gecontroleerde wijziging aanbrengen en voor beide een diff-melding ontvangen” als acceptatietest. De deployment wordt vervolgens vanuit dat resultaat terug opgebouwd.

Change Detection heeft een specifieke rol in de stack: wijzigingen op pagina's monitoren zonder zelf een scraper te schrijven. De vraag voor productie is daarom niet of poort 5000 één keer antwoord geeft, maar of state, dependencies en het publieke adres na een restart, update en restore met elkaar blijven overeenstemmen.

Scheid Change Detection van zijn dependencies

De kleinst verantwoorde Change Detection-topologie bevat één private listener op poort 5000, een ingress-route en een gedocumenteerde stategrens. Het netwerkcontract voor Change Detection is een remote browser zoals Playwright voor JavaScript-zware pagina's. Houd private endpoints op interne DNS, sta alleen de benodigde uitgaande verbindingen toe en geef Change Detection een service credential met beperkte scope.

Valideer de topologie door een clean client opdracht te geven één statische pagina en één JavaScript-gerenderde pagina te monitoren, een gecontroleerde wijziging aan te brengen en voor beide een diff-melding te ontvangen. Monitor tijdens het uitvoeren de browser-worker-concurrency, screenshot history, target latency en anti-bot challenges. Zo zie je of de volgende verbetering in memory, storage, networking of een aparte worker moet worden gezocht, in plaats van willekeurig de container groter te maken.

Maak recovery van Change Detection meetbaar

Definieer het recovery point en de recovery time voor Change Detection aan de hand van watch-definities, history, snapshots en notification settings. Mount /datastore vóór de bootstrap, schrijf onschuldige voorbeelddata en vervang de container om te bewijzen dat dit pad daadwerkelijk persistent is. Een named volume lost persistentie bij redeployment op, maar beschermt niet tegen een compromise of het verlies van de server.

Bouw een clean restore-omgeving, gebruik dezelfde gepinde applicatieversie en bewijs dat watch-definities, history en notification targets terugkeren en dat de gecontroleerde wijziging opnieuw wordt gedetecteerd. Leg commando's, fixes voor ownership en de verstreken tijd vast. De back-uphandleiding biedt een bruikbare standaard: een back-up is pas betrouwbaar na een restore, niet na het uploaden.

Beveilig Change Detection na de bootstrap

Neem beveiligingsaannames uit een lokale tutorial niet zomaar over. De specifieke zorg bij Change Detection is dat watch history en notification tokens zonder authenticatie worden blootgesteld. In productie moet je watch history daarom beschermen, omdat deze private URL's, cookies en notification credentials kan bevatten.

BASE_URL is configuratie en geen secret; houd de waarde expliciet en bescherm de afzonderlijke credentials die Change Detection gebruikt. Beperk filesystem- en network access, beveilig setup-endpoints en definieer upload-, request- of execution-limits rond browser-worker-concurrency, screenshot history, target latency en anti-bot challenges.

Bewijs dat je moet verzamelen voordat Change Detection live gaat

Maak voordat echte gebruikers arriveren een release-worksheet voor Change Detection. Deze moet de gepinde image, poort 5000, de canonical origin, persistente paden en de eigenaar van een remote browser zoals Playwright voor JavaScript-zware pagina's benoemen. Voeg het verwachte resultaat van deze transactie toe: één statische pagina en één JavaScript-gerenderde pagina monitoren, een gecontroleerde wijziging aanbrengen en voor beide een diff-melding ontvangen.

Gebruik de worksheet na een normale vervanging en na een clean restore. Recovery wordt alleen geaccepteerd als watch-definities, history en notification targets terugkeren en de gecontroleerde wijziging opnieuw wordt gedetecteerd. Verzamel ook een korte resource trace met browser-worker-concurrency, screenshot history, target latency en anti-bot challenges; bewaar deze naast de release zodat toekomstige capaciteitswijzigingen met dezelfde workload worden vergeleken.

Neem één gecontroleerde fout op: ontzeg de test identity tijdelijk de toegang tot een remote browser zoals Playwright voor JavaScript-zware pagina's. Controleer of Change Detection het probleem op de juiste grens rapporteert, herstel de geldige situatie en voer de transactie opnieuw uit. Hiermee test je de zichtbaarheid van fouten, niet alleen succes, en voorkom je dat een gezond ogende interface een kapotte worker, callback of databaseverbinding verbergt.

Maak de startup van Change Detection reproduceerbaar

Een minimaal commando is nuttig wanneer het laat zien wat het platform later zal beheren.

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

Hier blijft poort 5000 privé op de host en is elk vereist pad expliciet. Voeg de beoordeelde connection settings toe voor een remote browser zoals Playwright voor JavaScript-zware pagina's; gebruik private namen voor private services. Controleer de startup met zowel logs als het applicatiespecifieke bewijs: één statische pagina en één JavaScript-gerenderde pagina monitoren, een gecontroleerde wijziging aanbrengen en voor beide een diff-melding ontvangen. Vergrendel zodra dit is geverifieerd de imageversie, zodat een normale vervanging het gedrag niet ongemerkt verandert.

Domeinen, proxy headers en poort 5000

Behandel de externe Change Detection-URL als configuratie die redeployments overleeft. Stel eerst BASE_URL en eventuele browser endpoint in op adressen die de container kan bereiken; routeer vervolgens de hostname naar poort 5000, waarbij de oorspronkelijke host en scheme intact blijven.

De deployment-reachabilitychecklist kan bewijzen dat requests de container binnenkomen. Daarna moet de bekende fout — gewone requests komen bot challenges tegen of de browser service is onbereikbaar — in Change Detection, de state of de workload worden onderzocht, en niet in certificate automation.

Richt de operatie rond de echte bottleneck van Change Detection in

Bouw dashboards rond browser-worker-concurrency, screenshot history, target latency en anti-bot challenges. Een CPU-grafiek zonder context van die workload kan niet verklaren waarom Change Detection traag is. Voeg een synthetic of geplande check toe die met onschuldige testdata één statische pagina en één JavaScript-gerenderde pagina probeert te monitoren, een gecontroleerde wijziging aanbrengt en voor beide een diff-melding ontvangt.

Houd vóór een upgrade rekening met dit applicatiespecifieke risico: Playwright imageversies, datastore-migraties en notification-integraties moeten gezamenlijk worden bijgewerkt. Restore een recente back-up naar een geïsoleerde deployment, voer daar de migraties uit en vergelijk het gedrag. Als gewone requests bot challenges tegenkomen of de browser service onbereikbaar is, controleer dan eerst de betrokken grens — public origin, storage of dependency — voordat je niet-gerelateerde instellingen wijzigt.

Wat Dockup voor Change Detection moet automatiseren

Een Dockup-template moet de image, poort 5000, mounts, health timing, het domein, TLS en secret delivery vastleggen. Dockup moet private onderdelen van een remote browser zoals Playwright voor JavaScript-zware pagina's op het interne netwerk houden en geen extra publieke poort blootstellen. Dezelfde deployment kan gericht worden op Dockup-servers of door klanten gekoppelde capaciteit.

Pas na het live gaan van de route de publieke instelling toe en probeer één statische pagina en één JavaScript-gerenderde pagina te monitoren, een gecontroleerde wijziging aan te brengen en voor beide een diff-melding te ontvangen. Maak back-ups van watch-definities, history, snapshots en notification settings en houd de restore-oefening in het operationele plan; dit zijn verantwoordelijkheden van Change Detection die ook na het provisionen van de infrastructuur zichtbaar blijven.

Veelgestelde vragen

Wat heeft Change Detection nodig voor een production deployment?

Routeer de Change Detection-container op poort 5000 via één HTTPS-origin. De bijbehorende netwerkvereiste is een remote browser zoals Playwright voor JavaScript-zware pagina's. Verklaar Change Detection pas gereed wanneer je één statische pagina en één JavaScript-gerenderde pagina kunt monitoren, een gecontroleerde wijziging kunt aanbrengen en voor beide een diff-melding kunt ontvangen.

Welke Change Detection-data hoort in een back-up?

Maak /datastore persistent en neem watch-definities, history, snapshots en notification settings op in hetzelfde recovery manifest. Een clean Change Detection-restore is alleen geslaagd wanneer watch-definities, history en notification targets terugkeren en de gecontroleerde wijziging opnieuw wordt gedetecteerd.

Heeft Change Detection HTTPS achter een reverse proxy nodig?

Gebruik HTTPS voor de publieke Change Detection-origin en houd poort 5000 op de interne route. Pas de Change Detection-instelling correct toe: stel BASE_URL en eventuele browser endpoint in op adressen die de container kan bereiken. Voor Change Detection beschermt HTTPS credentials of gebruikerscontent tijdens transport en zorgt het ervoor dat origin-gevoelig clientgedrag consistent blijft.

Hoe moet een Change Detection-upgrade worden getest?

Restore de actuele Change Detection-state naar een geïsoleerde deployment, pas de kandidaatversie toe en herhaal de acceptatietransactie. Let hierbij extra goed op, omdat Playwright imageversies, datastore-migraties en notification-integraties gezamenlijk moeten worden bijgewerkt. Houd de vorige Change Detection-image beschikbaar totdat de grenzen voor datamigratie en rollback duidelijk zijn.