Cómo alojar Change Detection por tu cuenta en 2026: navegación con browser, alertas y persistencia

Un contenedor de Change Detection puede aparecer en verde mientras la tarea que realmente importa a los usuarios está fallando. En Change Detection, este fallo oculto suele deberse a que las solicitudes directas encuentran desafíos anti-bot o a que el servicio de browser no está accesible. Esta guía considera como prueba de aceptación “monitorizar una página estática y una página renderizada con JavaScript, introducir un cambio controlado y recibir una notificación con las diferencias de cada una” y diseña el despliegue partiendo de ese resultado.

Change Detection cumple una función concreta en el stack: monitorizar cambios en páginas sin tener que escribir un scraper. Por tanto, la pregunta en producción no es si el puerto 5000 responde una vez, sino si el estado, las dependencias y la dirección pública siguen siendo coherentes después de un reinicio, una actualización y una restauración.

Separa Change Detection de sus dependencias

La topología mínima responsable de Change Detection contiene un único listener privado en el puerto 5000, una ruta de ingress y un límite de estado documentado. El contrato de red de Change Detection consiste en un browser remoto como Playwright para páginas con mucho JavaScript. Mantén los endpoints privados en DNS interno, permite únicamente las conexiones salientes necesarias y proporciona a Change Detection una credencial de servicio con permisos acotados.

Valida la topología pidiendo a un cliente limpio que monitorice una página estática y una página renderizada con JavaScript, introduzca un cambio controlado y reciba una notificación con las diferencias de cada una. Mientras se ejecuta, observa la concurrencia de los browser workers, el historial de capturas de pantalla, la latencia de los objetivos y los desafíos anti-bot. El resultado te indicará si la siguiente mejora corresponde a la memoria, el almacenamiento, la red o un worker independiente, en lugar de fomentar un dimensionamiento arbitrario del contenedor.

Haz medible la recuperación de Change Detection

Define el punto de recuperación y el tiempo de recuperación de Change Detection en términos de definiciones de monitorización, historial, snapshots y configuración de notificaciones. Monta /datastore antes del bootstrap, escribe datos de ejemplo inocuos y reemplaza el contenedor para demostrar que esa ruta es realmente persistente. Un volumen con nombre resuelve la persistencia durante los redeploys; no resuelve un compromiso ni la pérdida del servidor.

Crea un entorno de restauración limpio, utiliza la misma versión fijada de la aplicación y demuestra que las definiciones de monitorización, el historial y los objetivos de notificación vuelven a estar disponibles y que el cambio controlado se detecta de nuevo. Registra los comandos, las correcciones de ownership y el tiempo transcurrido. La guía de backups ofrece un estándar útil: un backup se considera fiable después de restaurarlo, no después de subirlo.

Refuerza la seguridad de Change Detection después del bootstrap

No heredes las suposiciones de seguridad de un tutorial local. La preocupación específica de Change Detection es exponer el historial de monitorización y los tokens de notificación sin autenticación. Por tanto, en producción debes proteger el historial de monitorización, ya que puede contener URLs privadas, cookies y credenciales de notificación.

BASE_URL es configuración, no un secreto; mantén su valor explícito y protege por separado las credenciales que utiliza Change Detection. Limita el acceso al sistema de archivos y a la red, protege los endpoints de configuración y define límites de upload, solicitudes o ejecución en torno a la concurrencia de los browser workers, el historial de capturas de pantalla, la latencia de los objetivos y los desafíos anti-bot.

Evidencias que debes recopilar antes de poner Change Detection en producción

Antes de que lleguen usuarios reales, prepara una hoja de verificación de release para Change Detection. Debe indicar la imagen fijada, el puerto 5000, el origen canónico, las rutas persistentes y el responsable de un browser remoto como Playwright para páginas con mucho JavaScript. Adjunta el resultado esperado de esta transacción: monitorizar una página estática y una página renderizada con JavaScript, introducir un cambio controlado y recibir una notificación con las diferencias de cada una.

Utiliza la hoja después de un reemplazo normal y después de una restauración limpia. La recuperación solo se acepta si las definiciones de monitorización, el historial y los objetivos de notificación vuelven a estar disponibles y el cambio controlado se detecta de nuevo. Recopila también una traza breve de recursos que cubra la concurrencia de los browser workers, el historial de capturas de pantalla, la latencia de los objetivos y los desafíos anti-bot; guárdala junto al release para comparar futuras variaciones de capacidad con la misma carga de trabajo.

Incluye un fallo controlado: deniega temporalmente a la identidad de prueba el acceso a un browser remoto como Playwright para páginas con mucho JavaScript. Confirma que Change Detection informa del problema en el límite correcto, restablece la condición válida y vuelve a ejecutar la transacción. Esto comprueba la visibilidad de los errores, no solo el éxito, y evita que una interfaz que parece saludable oculte un worker, un callback o una conexión a la base de datos que no funcionan.

Haz reproducible el arranque de Change Detection

Un comando mínimo resulta útil cuando muestra lo que la plataforma gestionará más adelante.

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

Aquí el puerto 5000 sigue siendo privado para el host y todas las rutas necesarias están especificadas de forma explícita. Añade la configuración de conexión revisada para un browser remoto como Playwright para páginas con mucho JavaScript; utiliza nombres privados para los servicios privados. Verifica el arranque tanto con los logs como con la prueba específica de la aplicación: monitorizar una página estática y una página renderizada con JavaScript, introducir un cambio controlado y recibir una notificación con las diferencias de cada una. Una vez verificado, fija la versión de la imagen para que un reemplazo rutinario no cambie el comportamiento silenciosamente.

Dominios, headers del proxy y puerto 5000

Trata la URL externa de Change Detection como una configuración que debe sobrevivir a los redeploys. Primero establece BASE_URL y cualquier endpoint del browser con direcciones accesibles para el contenedor; después dirige el hostname al puerto 5000 conservando intactos el host y el scheme originales.

La checklist de reachability del despliegue puede demostrar que las solicitudes llegan al contenedor. A partir de ahí, el fallo conocido —las solicitudes directas encuentran desafíos anti-bot o el servicio de browser no está accesible— debe investigarse en Change Detection, en su estado o en su carga de trabajo, no en la automatización de certificados.

Opera Change Detection en torno a su cuello de botella real

Construye los dashboards en torno a la concurrencia de los browser workers, el historial de capturas de pantalla, la latencia de los objetivos y los desafíos anti-bot. Un gráfico de CPU sin el contexto de esa carga de trabajo no puede explicar por qué Change Detection funciona lentamente. Añade una comprobación sintética o programada que intente monitorizar una página estática y una página renderizada con JavaScript, introduzca un cambio controlado y reciba una notificación con las diferencias de cada una usando datos de prueba inocuos.

Antes de actualizar, ten en cuenta este riesgo específico de la aplicación: las versiones de las imágenes de Playwright, las migraciones del datastore y las integraciones de notificaciones deben avanzar juntas. Restaura un backup reciente en un despliegue aislado, ejecuta allí las migraciones y compara el comportamiento. Si las solicitudes directas encuentran desafíos anti-bot o el servicio de browser no está accesible, inspecciona el límite implicado —origen público, almacenamiento o dependencia— antes de modificar configuraciones no relacionadas.

Qué debería automatizar Dockup para Change Detection

Una plantilla de Dockup debería codificar la imagen, el puerto 5000, los mounts, los tiempos de health check, el dominio, TLS y la entrega de secretos. Dockup debería mantener las partes privadas de un browser remoto como Playwright para páginas con mucho JavaScript en la red interna y no exponer ningún puerto público adicional. El mismo despliegue puede dirigirse a servidores de Dockup o a capacidad conectada por el cliente.

Una vez activa la ruta, aplica la configuración pública e intenta monitorizar una página estática y una página renderizada con JavaScript, introducir un cambio controlado y recibir una notificación con las diferencias de cada una. Haz backup de las definiciones de monitorización, el historial, los snapshots y la configuración de notificaciones, y mantén el ejercicio de restauración en el plan operativo; estas son responsabilidades de Change Detection que siguen siendo visibles después del aprovisionamiento de la infraestructura.

Preguntas frecuentes

¿Qué necesita Change Detection para un despliegue en producción?

Dirige el contenedor de Change Detection del puerto 5000 a través de un único origen HTTPS. El requisito de red de soporte es un browser remoto como Playwright para páginas con mucho JavaScript. No consideres que Change Detection está listo hasta que puedas monitorizar una página estática y una página renderizada con JavaScript, introducir un cambio controlado y recibir una notificación con las diferencias de cada una.

¿Qué datos de Change Detection deben incluirse en un backup?

Persiste /datastore e incluye las definiciones de monitorización, el historial, los snapshots y la configuración de notificaciones en el mismo manifiesto de recuperación. Una restauración limpia de Change Detection solo se considera correcta cuando las definiciones de monitorización, el historial y los objetivos de notificación vuelven a estar disponibles y el cambio controlado se detecta de nuevo.

¿Change Detection necesita HTTPS detrás de un reverse proxy?

Utiliza HTTPS para el origen público de Change Detection y mantén el puerto 5000 en la ruta interna. Aplica correctamente la configuración de Change Detection: establece BASE_URL y cualquier endpoint del browser con direcciones accesibles para el contenedor. En Change Detection, HTTPS protege las credenciales o el contenido de los usuarios durante el tránsito y mantiene coherente el comportamiento del cliente dependiente del origen.

¿Cómo debe probarse una actualización de Change Detection?

Restaura el estado actual de Change Detection en un despliegue aislado, aplica la versión candidata y repite su transacción de aceptación. Presta especial atención porque las versiones de las imágenes de Playwright, las migraciones del datastore y las integraciones de notificaciones deben avanzar juntas. Conserva la imagen anterior de Change Detection hasta comprender sus límites de migración de datos y rollback.