Como fazer self-hosting do Change Detection em 2026: fetching no navegador, alertas e persistência

Um container do Change Detection pode estar green enquanto o job que realmente importa para os usuários está quebrado. No Change Detection, essa falha oculta geralmente significa que requisições simples encontram desafios anti-bot ou que o browser service está inacessível. Este guia considera como teste de aceitação “monitorar uma página estática e uma página renderizada com JavaScript, introduzir uma alteração controlada e receber uma notificação de diff para cada uma” e estrutura o deployment a partir desse resultado.

O Change Detection tem uma função específica na stack: monitorar alterações em páginas sem escrever um scraper. Portanto, a questão em produção não é se a porta 5000 responde uma vez, mas se o estado, as dependências e o endereço público continuam consistentes depois de um restart, update e restore.

Separe o Change Detection das dependências

A menor topologia responsável para o Change Detection contém um único listener privado na porta 5000, uma rota de ingress e uma fronteira de estado documentada. O contrato de rede do Change Detection é um browser remoto, como o Playwright, para páginas com uso intenso de JavaScript. Mantenha endpoints privados no DNS interno, permita apenas as chamadas de saída necessárias e forneça ao Change Detection uma credencial de serviço com escopo restrito.

Valide a topologia solicitando a um client limpo que monitore uma página estática e uma página renderizada com JavaScript, introduza uma alteração controlada e receba uma notificação de diff para cada uma. Monitore a concorrência dos workers do navegador, o histórico de screenshots, a latência dos alvos e os desafios anti-bot enquanto o processo é executado. O resultado mostra se a próxima melhoria deve ser feita em memória, storage, networking ou em um worker separado, em vez de incentivar um dimensionamento arbitrário do container.

Torne a recuperação do Change Detection mensurável

Defina o recovery point e o recovery time do Change Detection em termos de definições de monitoramento, histórico, snapshots e configurações de notificação. Monte /datastore antes do bootstrap, grave dados de exemplo inofensivos e substitua o container para provar que esse caminho é realmente persistente. Um named volume resolve a persistência durante redeploys; não resolve comprometimento nem perda do servidor.

Prepare um ambiente de restore limpo, use a mesma versão fixada da aplicação e prove que as definições de monitoramento, o histórico e os destinos de notificação retornam e que a alteração controlada é detectada novamente. Registre comandos, correções de ownership e o tempo decorrido. O guia de backup é um padrão útil: um backup só é confiável depois do restore, não depois do upload.

Proteja o Change Detection após o bootstrap

Não herde as premissas de segurança de um tutorial local. A preocupação específica do Change Detection é expor o histórico de monitoramento e os tokens de notificação sem autenticação. Por isso, em produção, o histórico de monitoramento deve ser protegido, pois pode conter URLs privadas, cookies e credenciais de notificação.

BASE_URL é configuração, não um secret; mantenha seu valor explícito e proteja as credenciais separadas usadas pelo Change Detection. Restrinja o acesso ao filesystem e à rede, proteja os endpoints de setup e defina limites de upload, requests ou execução em torno da concorrência dos workers do navegador, do histórico de screenshots, da latência dos alvos e dos desafios anti-bot.

Evidências a coletar antes de colocar o Change Detection em produção

Antes da chegada dos usuários reais, crie uma release worksheet para o Change Detection. Ela deve indicar a image fixada, a porta 5000, a origem canônica, os caminhos persistentes e o responsável por um browser remoto, como o Playwright, para páginas com uso intenso de JavaScript. Anexe o resultado esperado desta transação: monitorar uma página estática e uma página renderizada com JavaScript, introduzir uma alteração controlada e receber uma notificação de diff para cada uma.

Use a worksheet depois de uma substituição normal e de um restore limpo. A recuperação só é aceita quando as definições de monitoramento, o histórico e os destinos de notificação retornam e a alteração controlada é detectada novamente. Colete também um breve resource trace cobrindo a concorrência dos workers do navegador, o histórico de screenshots, a latência dos alvos e os desafios anti-bot; mantenha-o junto da release para que futuras alterações de capacidade sejam comparadas com a mesma carga de trabalho.

Inclua uma falha controlada: negue temporariamente à identidade de teste o acesso a um browser remoto, como o Playwright, para páginas com uso intenso de JavaScript. Confirme que o Change Detection reporta o problema na fronteira correta, restaure a condição válida e execute novamente a transação. Isso verifica a visibilidade dos erros, não apenas o sucesso, e impede que uma interface aparentemente saudável oculte um worker, callback ou conexão com o banco de dados quebrado.

Torne o startup do Change Detection reproduzível

Um comando mínimo é útil quando revela o que a plataforma gerenciará posteriormente.

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

Aqui, a porta 5000 permanece privada no host e todos os caminhos necessários estão explícitos. Adicione as configurações de conexão revisadas para um browser remoto, como o Playwright, destinado a páginas com uso intenso de JavaScript; use nomes privados para serviços privados. Verifique o startup com os logs e também com a prova específica da aplicação: monitorar uma página estática e uma página renderizada com JavaScript, introduzir uma alteração controlada e receber uma notificação de diff para cada uma. Depois da verificação, fixe a versão da image para que uma substituição rotineira não altere o comportamento silenciosamente.

Domínios, proxy headers e a porta 5000

Trate a URL externa do Change Detection como uma configuração que sobrevive a redeploys. Primeiro, defina BASE_URL e qualquer browser endpoint com endereços que o container consiga alcançar; depois, direcione o hostname para a porta 5000 preservando o host e o scheme originais.

O checklist de reachability do deployment pode provar que as requisições entram no container. Depois disso, a falha conhecida — requisições simples encontram desafios anti-bot ou o browser service está inacessível — deve ser investigada no Change Detection, em seu estado ou em sua carga de trabalho, e não na automação de certificados.

Opere o Change Detection em torno do gargalo real

Crie dashboards em torno da concorrência dos workers do navegador, do histórico de screenshots, da latência dos alvos e dos desafios anti-bot. Um gráfico de CPU sem o contexto dessa carga de trabalho não consegue explicar por que o Change Detection está lento. Adicione um check sintético ou agendado que tente monitorar uma página estática e uma página renderizada com JavaScript, introduza uma alteração controlada e receba uma notificação de diff para cada uma usando dados de teste inofensivos.

Antes de fazer um upgrade, considere este risco específico da aplicação: as versões das images do Playwright, as migrações do datastore e as integrações de notificação devem avançar juntas. Restaure um backup recente em um deployment isolado, execute as migrações nesse ambiente e compare o comportamento. Se requisições simples encontrarem desafios anti-bot ou o browser service estiver inacessível, inspecione a fronteira envolvida — origem pública, storage ou dependência — antes de alterar configurações não relacionadas.

O que o Dockup deve automatizar para o Change Detection

Um template do Dockup deve codificar a image, a porta 5000, os mounts, o timing de health check, o domínio, o TLS e a entrega de secrets. O Dockup deve manter as partes privadas de um browser remoto, como o Playwright, para páginas com uso intenso de JavaScript na rede interna e não expor nenhuma porta pública adicional. O mesmo deployment pode ser direcionado a servidores do Dockup ou a capacidade conectada pelo cliente.

Depois que a rota estiver ativa, aplique a configuração pública e tente monitorar uma página estática e uma página renderizada com JavaScript, introduza uma alteração controlada e receba uma notificação de diff para cada uma. Faça backup das definições de monitoramento, do histórico, dos snapshots e das configurações de notificação e mantenha o exercício de restore no plano operacional; essas são responsabilidades do Change Detection que continuam visíveis depois do provisionamento da infraestrutura.

Perguntas frequentes

O que o Change Detection precisa para um deployment em produção?

Direcione o container do Change Detection na porta 5000 por meio de uma única origem HTTPS. O requisito de rede de suporte é um browser remoto, como o Playwright, para páginas com uso intenso de JavaScript. Não considere o Change Detection pronto até conseguir monitorar uma página estática e uma página renderizada com JavaScript, introduzir uma alteração controlada e receber uma notificação de diff para cada uma.

Quais dados do Change Detection devem fazer parte de um backup?

Persista /datastore e inclua as definições de monitoramento, o histórico, os snapshots e as configurações de notificação no mesmo recovery manifest. Um restore limpo do Change Detection só é aprovado quando as definições de monitoramento, o histórico e os destinos de notificação retornam e a alteração controlada é detectada novamente.

O Change Detection precisa de HTTPS atrás de um reverse proxy?

Use HTTPS para a origem pública do Change Detection e mantenha a porta 5000 na rota interna. Aplique corretamente a configuração do Change Detection: defina BASE_URL e qualquer browser endpoint com endereços que o container consiga alcançar. No Change Detection, o HTTPS protege credenciais ou conteúdo de usuários em trânsito e mantém consistente o comportamento do client que depende da origem.

Como testar um upgrade do Change Detection?

Restaure o estado atual do Change Detection em um deployment isolado, aplique a versão candidata e repita sua transação de aceitação. Tenha atenção especial, pois as versões das images do Playwright, as migrações do datastore e as integrações de notificação devem avançar juntas. Mantenha a image anterior do Change Detection até que os limites de migração de dados e rollback estejam compreendidos.