Sådan self-hoster du Change Detection i 2026: Browser fetching, alerts og persistence

En Change Detection-container kan være grøn, selv om det job, brugerne er interesserede i, er gået i stykker. For Change Detection er den skjulte fejl typisk, at plain requests møder bot challenges, eller at browser-servicen ikke kan nås. Denne guide bruger følgende acceptance test: “overvåg én statisk side og én JavaScript-renderet side, introducér en kontrolleret ændring, og modtag en diff-notifikation for hver” – og bygger deploymentet baglæns ud fra dette resultat.

Change Detection har en specifik rolle i stacken: overvågning af ændringer på sider uden at skrive en scraper. Produktionsspørgsmålet er derfor ikke, om port 5000 svarer én gang, men om state, dependencies og den offentlige adresse fortsat stemmer overens efter en restart, update og restore.

Adskil Change Detection fra dets dependencies

Den mindste ansvarlige Change Detection-topologi indeholder én privat listener på 5000, en ingress-route og en dokumenteret state-boundary. Netværkskontrakten for Change Detection er en remote browser som Playwright til JavaScript-tunge sider. Hold private endpoints på intern DNS, tillad kun nødvendige outbound-kald, og giv Change Detection en afgrænset service credential.

Validér topologien ved at bede en ren klient om at overvåge én statisk side og én JavaScript-renderet side, introducere en kontrolleret ændring og modtage en diff-notifikation for hver. Overvåg browser-worker concurrency, screenshot history, target latency og anti-bot challenges, mens den kører. Resultatet fortæller dig, om den næste forbedring hører hjemme i memory, storage, networking eller en separat worker, i stedet for at tilskynde til vilkårlig container-sizing.

Gør recovery for Change Detection målbar

Definér recovery point og recovery time for Change Detection med udgangspunkt i watch definitions, history, snapshots og notification settings. Mount /datastore før bootstrap, skriv harmløse eksempeldata, og erstat containeren for at bevise, at stien faktisk er persistent. En named volume løser persistence ved redeploy; den løser ikke kompromittering eller tab af serveren.

Byg et rent restore-miljø, brug den samme pinnede application version, og bevis, at watch definitions, history og notification targets kommer tilbage, og at den kontrollerede ændring registreres igen. Notér commands, ownership fixes og den forløbne tid. Backup-guiden er en nyttig standard: En backup er først troværdig efter en restore, ikke efter en upload.

Lås Change Detection ned efter bootstrap

Overfør ikke sikkerhedsantagelser fra en lokal tutorial. Den specifikke bekymring ved Change Detection er at eksponere watch history og notification tokens uden authentication. Production bør derfor beskytte watch history, fordi den kan indeholde private URLs, cookies og notification credentials.

BASE_URL er configuration og ikke en secret; hold dens værdi eksplicit, mens de separate credentials, som Change Detection bruger, beskyttes. Afgræns filesystem- og network access, beskyt setup endpoints, og definér upload-, request- eller execution limits omkring browser-worker concurrency, screenshot history, target latency og anti-bot challenges.

Dokumentation, der skal indsamles, før Change Detection går live

Før de rigtige brugere kommer til, skal du lave et release worksheet for Change Detection. Det skal angive det pinnede image, port 5000, den canonical origin, persistente paths og ejeren af en remote browser som Playwright til JavaScript-tunge sider. Vedlæg det forventede resultat af denne transaktion: overvåg én statisk side og én JavaScript-renderet side, introducér en kontrolleret ændring, og modtag en diff-notifikation for hver.

Brug worksheetet efter en normal replacement og efter en clean restore. Recovery accepteres kun, hvis watch definitions, history og notification targets kommer tilbage, og den kontrollerede ændring registreres igen. Indsaml også et kort resource trace, der dækker browser-worker concurrency, screenshot history, target latency og anti-bot challenges; opbevar det sammen med releaset, så fremtidige kapacitetsændringer kan sammenlignes med den samme workload.

Medtag én kontrolleret fejl: Afvis midlertidigt test identity’ens adgang til en remote browser som Playwright til JavaScript-tunge sider. Bekræft, at Change Detection rapporterer problemet ved den korrekte boundary, genskab den gyldige tilstand, og kør transaktionen igen. Det tester error visibility, ikke kun succes, og forhindrer, at et interface, der ser sundt ud, skjuler en defekt worker, callback eller databaseforbindelse.

Gør Change Detection-start reproducible

En minimal command er nyttig, når den afslører, hvad platformen senere vil administrere.

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

Her forbliver port 5000 privat på hosten, og alle nødvendige paths er eksplicitte. Tilføj de gennemgåede connection settings for en remote browser som Playwright til JavaScript-tunge sider; brug private navne til private services. Bekræft startup med både logs og det applikationsspecifikke proof: overvåg én statisk side og én JavaScript-renderet side, introducér en kontrolleret ændring, og modtag en diff-notifikation for hver. Når det er verificeret, skal image-versionen låses, så en rutinemæssig replacement ikke ændrer adfærden ubemærket.

Domæner, proxy headers og port 5000

Betragt den eksterne Change Detection-URL som configuration, der skal overleve redeploys. Sæt først BASE_URL og eventuelle browser endpoints til adresser, som containeren kan nå; rout derefter hostname til port 5000 med den oprindelige host og scheme intakt.

Deployment reachability-checklisten kan bevise, at requests kommer ind i containeren. Derefter skal den kendte fejl – plain requests møder bot challenges, eller browser-servicen ikke kan nås – undersøges i Change Detection, dets state eller dets workload i stedet for i certificate automation.

Driftssæt Change Detection omkring den reelle bottleneck

Byg dashboards omkring browser-worker concurrency, screenshot history, target latency og anti-bot challenges. En CPU-graf uden denne workload-kontekst kan ikke forklare, hvorfor Change Detection er langsom. Tilføj et synthetic eller scheduled check, der forsøger at overvåge én statisk side og én JavaScript-renderet side, introducere en kontrolleret ændring og modtage en diff-notifikation for hver ved hjælp af harmløse testdata.

Før en upgrade skal du tage højde for denne applikationsspecifikke risiko: Playwright image versions, datastore migrations og notification integrations bør flyttes samlet. Restore en nyere backup til et isolated deployment, kør migrations dér, og sammenlign adfærden. Hvis plain requests møder bot challenges, eller browser-servicen ikke kan nås, skal du undersøge den relevante boundary – public origin, storage eller dependency – før du ændrer uvedkommende settings.

Hvad Dockup bør automatisere for Change Detection

En Dockup-template bør indeholde image, port 5000, mounts, health timing, domain, TLS og secret delivery. Dockup bør holde private dele af en remote browser som Playwright til JavaScript-tunge sider på intern networking og ikke eksponere en ekstra public port. Det samme deployment kan målrettes Dockup-servere eller kundetilknyttet capacity.

Når routen er live, skal du anvende den offentlige setting og forsøge at overvåge én statisk side og én JavaScript-renderet side, introducere en kontrolleret ændring og modtage en diff-notifikation for hver. Tag backup af watch definitions, history, snapshots og notification settings, og behold restore-øvelsen i driftsplanen; det er Change Detection-ansvar, som fortsat skal være synligt efter infrastructure provisioning.

Ofte stillede spørgsmål

Hvad skal Change Detection bruge til et production deployment?

Rout Change Detection-containeren på port 5000 gennem én HTTPS-origin. Det understøttende netværkskrav er en remote browser som Playwright til JavaScript-tunge sider. Erklær ikke Change Detection for klar, før du kan overvåge én statisk side og én JavaScript-renderet side, introducere en kontrolleret ændring og modtage en diff-notifikation for hver.

Hvilke Change Detection-data skal med i en backup?

Persistér /datastore, og medtag watch definitions, history, snapshots og notification settings i det samme recovery manifest. En clean Change Detection-restore er kun godkendt, når watch definitions, history og notification targets kommer tilbage, og den kontrollerede ændring registreres igen.

Kræver Change Detection HTTPS bag en reverse proxy?

Brug HTTPS for den offentlige Change Detection-origin, og hold port 5000 på den interne route. Anvend Change Detection-settingen korrekt: Sæt BASE_URL og eventuelle browser endpoints til adresser, som containeren kan nå. For Change Detection beskytter HTTPS credentials eller brugerindhold under transport og sikrer ensartet origin-sensitive client behavior.

Hvordan skal en Change Detection-upgrade testes?

Restore den aktuelle Change Detection-state til et isolated deployment, anvend candidate-versionen, og gentag dens acceptance transaction. Vær særligt opmærksom, fordi Playwright image versions, datastore migrations og notification integrations bør flyttes samlet. Behold det tidligere Change Detection-image, indtil dets data-migration- og rollback-boundary er forstået.