How to Self-Host Change Detection in 2026: Browser Fetching, Alerts and Persistence

A Change Detection container can be green while the job users care about is broken. For Change Detection, that hidden failure is usually that plain requests see bot challenges or the browser service is unreachable. This guide treats “watch one static page and one JavaScript-rendered page, introduce a controlled change and receive a diff notification for each” as the acceptance test and builds the deployment backward from that result.

Change Detection has a specific role in the stack: page-change monitoring without writing a scraper. The production question is therefore not whether port 5000 answers once, but whether state, dependencies and the public address continue to agree after a restart, update and restore.

Separate Change Detection from its dependencies

The smallest responsible Change Detection topology contains one private listener on 5000, an ingress route and a documented state boundary. The network contract for Change Detection is a remote browser such as Playwright for JavaScript-heavy pages. Keep private endpoints on internal DNS, permit only required outbound calls and give Change Detection a scoped service credential.

Validate the topology by asking a clean client to watch one static page and one JavaScript-rendered page, introduce a controlled change and receive a diff notification for each. Watch browser-worker concurrency, screenshot history, target latency and anti-bot challenges while it runs. The result tells you whether the next improvement belongs in memory, storage, networking or a separate worker instead of encouraging arbitrary container sizing.

Make Change Detection recovery measurable

Define recovery point and recovery time for Change Detection in terms of watch definitions, history, snapshots and notification settings. Mount /datastore before bootstrap, write harmless sample data and replace the container to prove that path is actually persistent. A named volume solves redeploy persistence; it does not solve compromise or server loss.

Build a clean restore environment, use the same pinned application version and prove that watch definitions, history and notification targets return and the controlled change is detected again. Record commands, ownership fixes and elapsed time. The backup guide is a useful standard: a backup is trusted after restoration, not after upload.

Lock down Change Detection after bootstrap

Do not inherit security assumptions from a local tutorial. Change Detection's specific concern is exposing watch history and notification tokens without authentication. Production should therefore protect watch history because it can contain private URLs, cookies and notification credentials.

BASE_URL is configuration rather than a secret; keep its value explicit while protecting the separate credentials used by Change Detection. Scope filesystem and network access, protect setup endpoints and define upload, request or execution limits around browser-worker concurrency, screenshot history, target latency and anti-bot challenges.

Evidence to collect before Change Detection goes live

Before real users arrive, make a release worksheet for Change Detection. It must name the pinned image, port 5000, canonical origin, persistent paths and the owner of a remote browser such as Playwright for JavaScript-heavy pages. Attach the expected result of this transaction: watch one static page and one JavaScript-rendered page, introduce a controlled change and receive a diff notification for each.

Use the worksheet after a normal replacement and after a clean restore. Recovery is accepted only if watch definitions, history and notification targets return and the controlled change is detected again. Also collect a short resource trace covering browser-worker concurrency, screenshot history, target latency and anti-bot challenges; keep it beside the release so future capacity changes are compared with the same workload.

Include one controlled failure: temporarily deny the test identity access to a remote browser such as Playwright for JavaScript-heavy pages. Confirm Change Detection reports the problem at the correct boundary, put the valid condition back and rerun the transaction. This checks error visibility, not merely success, and prevents a healthy-looking interface from concealing a broken worker, callback or database connection.

Make Change Detection startup reproducible

A minimal command is useful when it reveals what the platform will later manage.

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

Here port 5000 remains host-private and every required path is explicit. Add the reviewed connection settings for a remote browser such as Playwright for JavaScript-heavy pages; use private names for private services. Verify startup with both logs and the application-specific proof: watch one static page and one JavaScript-rendered page, introduce a controlled change and receive a diff notification for each. Once verified, lock the image version so a routine replacement does not silently change behavior.

Domains, proxy headers and port 5000

Treat the external Change Detection URL as configuration that survives redeploys. First set BASE_URL and any browser endpoint to addresses the container can reach; then route the hostname to port 5000 with the original host and scheme intact.

The deployment reachability checklist can prove that requests enter the container. After that point, the known failure — plain requests see bot challenges or the browser service is unreachable — should be investigated in Change Detection, its state or its workload rather than in certificate automation.

Operate Change Detection around its real bottleneck

Build dashboards around browser-worker concurrency, screenshot history, target latency and anti-bot challenges. A CPU graph without that workload context cannot explain why Change Detection is slow. Add a synthetic or scheduled check that tries to watch one static page and one JavaScript-rendered page, introduce a controlled change and receive a diff notification for each using harmless test data.

Before upgrading, account for this application-specific hazard: Playwright image versions, datastore migrations and notification integrations should move together. Restore a recent backup into an isolated deployment, run migrations there and compare behavior. If plain requests see bot challenges or the browser service is unreachable, inspect the boundary involved — public origin, storage or dependency — before touching unrelated settings.

What Dockup should automate for Change Detection

A Dockup template should encode the image, port 5000, mounts, health timing, domain, TLS and secret delivery. Dockup should keep private portions of a remote browser such as Playwright for JavaScript-heavy pages on internal networking and expose no extra public port. The same deployment can target Dockup servers or customer-attached capacity.

After the route is live, apply the public setting and try to watch one static page and one JavaScript-rendered page, introduce a controlled change and receive a diff notification for each. Back up watch definitions, history, snapshots and notification settings and keep the restore exercise in the operating plan; those are Change Detection responsibilities that remain visible after infrastructure provisioning.

Frequently asked questions

What does Change Detection need for a production deployment?

Route the Change Detection container on port 5000 through one HTTPS origin. The supporting network requirement is a remote browser such as Playwright for JavaScript-heavy pages. Do not call Change Detection ready until you can watch one static page and one JavaScript-rendered page, introduce a controlled change and receive a diff notification for each.

Which Change Detection data belongs in a backup?

Persist /datastore and include watch definitions, history, snapshots and notification settings in the same recovery manifest. A clean Change Detection restore passes only when watch definitions, history and notification targets return and the controlled change is detected again.

Does Change Detection require HTTPS behind a reverse proxy?

Use HTTPS for the public Change Detection origin and keep port 5000 on the internal route. Apply the Change Detection setting correctly: set BASE_URL and any browser endpoint to addresses the container can reach. For Change Detection, HTTPS protects credentials or user content in transit and keeps origin-sensitive client behavior consistent.

How should a Change Detection upgrade be tested?

Restore current Change Detection state into an isolated deployment, apply the candidate version and repeat its acceptance transaction. Pay particular attention because Playwright image versions, datastore migrations and notification integrations should move together. Keep the previous Change Detection image until its data-migration and rollback boundary are understood.