Instalación de ChangeDetection.io en un VPS: monitorización de cambios en sitios web, notificaciones de Telegram y copias de seguridad de Docker

Qué configuramos y por qué

ChangeDetection.io es una aplicación web de código abierto para rastrear cambios en sitios web. Carga regularmente las URL indicadas, compara la nueva versión de la página con la anterior y envía una notificación si el contenido ha cambiado. A diferencia de la monitorización HTTP simple, el servicio puede comprobar específicamente texto, HTML, un selector CSS individual, una respuesta JSON de API y el contenido visual de las páginas.

Los casos de uso prácticos suelen ser los siguientes:

• seguimiento del precio de un producto, billete de avión, entradas para un evento o tipo de cambio;
• control de la disponibilidad de un producto;
• monitorización de nuevas vacantes en la página de una empresa;
• seguimiento de cambios en ofertas públicas, normas, tarifas y documentación;
• control de cambios en el sitio de un competidor;
• comprobación de licitaciones públicas, compras, registros y portales gubernamentales;
• monitorización del estado de un servicio cloud, CDN, API o página de estado;
• recepción de una notificación sobre el lanzamiento de una actualización de software.

Tras la configuración, tendrá su propia instancia de ChangeDetection.io disponible mediante un dominio HTTPS. Podrá crear comprobaciones a través de la interfaz web, elegir el intervalo de ejecución, configurar filtros de texto y recibir mensajes en Telegram. Los datos de monitorización permanecerán bajo su control: el historial, las URL, las capturas de páginas y los tokens de notificación no se transmitirán a un servicio SaaS externo.

Cómo funciona la comprobación de cambios

Para cada página observada, ChangeDetection.io guarda el resultado anterior. En la siguiente comprobación, el servicio vuelve a cargar la página, normaliza el contenido y calcula la diferencia. Si las diferencias cumplen las reglas definidas, se crea un evento de cambio. Puede abrir su diff en el navegador, ver el texto añadido y eliminado, y después recibir una notificación mediante Telegram, e-mail, Discord, Slack, Matrix, webhook u otros canales compatibles con Apprise.

Para páginas HTML simples se utiliza una solicitud HTTP normal. Esto es suficiente para catálogos, documentación, páginas de productos y la mayoría de los sitios sin renderizado complejo del lado del cliente. Si el contenido aparece solo después de ejecutar JavaScript, se necesitará el motor de navegador Playwright. Conviene conectarlo solo cuando sea necesario: un navegador completo consume considerablemente más memoria y CPU que una comprobación HTTP normal.

Servicios cloud-managed y opción self-hosted

La instalación self-hosted es especialmente útil si necesita monitorizar decenas o cientos de páginas, no desea entregar a terceros la lista de recursos monitorizados o requiere integración con sistemas internos. Sin embargo, un VPS no elimina la responsabilidad: debe actualizar el sistema operativo, cerrar puertos innecesarios, hacer copias de seguridad y no generar una carga excesiva en sitios ajenos.

No configure un intervalo de sondeo demasiado corto sin necesidad. Comprobar una página pública cada 5–15 minutos suele ser suficiente. Las solicitudes frecuentes pueden provocar CAPTCHA, bloqueo de IP o incumplimiento de las reglas de un sitio concreto.

Qué configuración de VPS se necesita para esta tarea

La carga de ChangeDetection.io depende no tanto de la cantidad de URL guardadas como de la frecuencia de las comprobaciones y del tipo de páginas. Cien páginas HTML simples comprobadas una vez por hora apenas cargan el servidor. Decenas de páginas con JavaScript, autenticación o protección antibots pueden requerir más CPU y memoria, especialmente si se ejecuta simultáneamente el renderizado en navegador.

Para monitorización personal, un equipo de varias personas o 50–100 páginas sencillas, un punto de partida razonable es 2 vCPU, 4 GB de RAM, 50 GB NVMe y una dirección IPv4. Por ejemplo, puede contratar un VPS con las características indicadas, instalar Ubuntu Server 24.04 LTS y desplegar toda la pila en Docker Compose.

Por qué es importante disponer de espacio libre en disco

El servicio guarda el historial de cambios y capturas de las páginas comprobadas. Una página de texto ocupa poco espacio, pero los documentos HTML grandes, las imágenes, un historial de diff extenso y un gran número de URL incrementan gradualmente el volume. No llene el disco hasta el límite: Docker y la base de datos necesitan espacio libre para archivos temporales, registros y la escritura correcta de datos.

Una regla útil es mantener al menos un 20–30% de espacio libre. Una vez al mes, compruebe el tamaño del Docker volume y elimine las imágenes Docker que no utilice. No realice una limpieza agresiva de volumes: allí se encuentran los datos de usuario de la aplicación.

Cuándo se necesita un dedicated en lugar de un VPS

Un VPS normal es adecuado para casi todas las instalaciones personales y comerciales pequeñas. Un servidor dedicated se justifica si ejecuta muchos workers de navegador, procesa constantemente miles de páginas JavaScript, necesita CPU garantizada sin influencia de vecinos o almacena un historial amplio de capturas. También puede ser útil cuando ChangeDetection.io se convierte en parte de una plataforma interna de monitorización con varios operadores y proxies independientes.

No cambie a un dedicated solo por unas pocas páginas lentas. Primero aumente la RAM a 4–8 GB, reduzca el paralelismo, alargue los intervalos de comprobación y verifique si todas las URL realmente necesitan renderizado en navegador.

Cómo elegir la ubicación

La ubicación afecta a la latencia, la versión geográfica del sitio y la probabilidad de comprobaciones antibot. Si sigue sitios rusos, europeos o estadounidenses, elija un servidor más cercano a su audiencia principal. Algunas tiendas y servicios muestran precios, monedas, disponibilidad y contenido diferentes según la dirección IP. En ese caso, el servidor debe estar ubicado en el país o región para el que desea obtener los datos.

Para el panel de administración, la ubicación es menos crítica: la interfaz es ligera y funciona mediante HTTPS. Son más importantes la estabilidad de la red, IPv4 disponible, tráfico suficiente y la posibilidad de configurar un registro DNS para el dominio.

Preparación del servidor

A continuación se utiliza Ubuntu Server 24.04 LTS. En el momento de preparar esta guía, es una versión LTS estable adecuada para hosts Docker. Los comandos también son similares para Debian 12, pero los nombres de algunos paquetes y la configuración del firewall pueden diferir.

Se supone que el servidor ya dispone de una dirección IPv4 pública y que se ha creado un registro A en el panel DNS, por ejemplo changes.example.com, que apunta a esta dirección. Sin un registro DNS correcto, Caddy no podrá emitir automáticamente un certificado Let's Encrypt.

Primer acceso y actualización del sistema

Conéctese como usuario root solo para la configuración inicial. Actualice inmediatamente el sistema, cree un usuario normal y transfiera su clave SSH a este usuario. En adelante, no trabaje en el panel de ChangeDetection.io ni con Docker como root sin motivo.

ssh root@SERVER_IP

apt update && apt upgrade -y
apt install -y ca-certificates curl gnupg ufw fail2ban vim jq unzip
reboot

Después de reiniciar, conéctese de nuevo y cree un usuario. En el ejemplo se utiliza el nombre deploy; sustitúyalo por el suyo.

adduser deploy
usermod -aG sudo deploy
mkdir -p /home/deploy/.ssh
chmod 700 /home/deploy/.ssh

Copie su clave pública desde el equipo local. El comando se ejecuta en la máquina local, no en el servidor.

ssh-copy-id deploy@SERVER_IP

Compruebe el acceso en una nueva sesión antes de desactivar el acceso root.

ssh deploy@SERVER_IP
sudo whoami

El resultado esperado del último comando es root. Esto significa que el usuario puede realizar acciones administrativas mediante sudo.

Protección de SSH

Abra una sesión SSH independiente y no cierre la anterior hasta asegurarse de que el acceso mediante clave funciona. A continuación, cree un archivo de configuración SSH independiente. Este enfoque es más seguro que editar el archivo principal del paquete.

sudo tee /etc/ssh/sshd_config.d/99-hardening.conf > /dev/null <<'EOF'
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
X11Forwarding no
MaxAuthTries 3
EOF

sudo sshd -t
sudo systemctl restart ssh

El comando sshd -t comprueba la sintaxis antes de reiniciar el servicio. Si la prueba finaliza sin errores, la configuración es correcta. Ahora el acceso root y la autenticación por contraseña están desactivados, y la conexión solo es posible mediante clave SSH.

Firewall y Fail2ban

ChangeDetection.io no debe escuchar directamente en un puerto público. Desde el exterior solo estarán disponibles SSH, HTTP para emitir el certificado TLS y HTTPS para el panel. El puerto Docker de la aplicación permanecerá accesible únicamente en 127.0.0.1.

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

Compruebe que la salida solo permita los puertos 22, 80 y 443. Si SSH funciona en un puerto no estándar, permita primero ese puerto; de lo contrario, podría perder el acceso al servidor.

Fail2ban bloquea direcciones IP tras una serie de intentos de acceso fallidos. Para Ubuntu, basta con activar el servicio y añadir una configuración local sencilla.

sudo tee /etc/fail2ban/jail.d/sshd.local > /dev/null <<'EOF'
[sshd]
enabled = true
maxretry = 5
findtime = 10m
bantime = 1h
EOF

sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd

Comprobaciones básicas del host

Antes de instalar Docker, asegúrese de que la hora esté sincronizada, haya suficiente espacio libre en disco y el dominio DNS ya apunte al servidor. Una hora incorrecta provoca problemas con los certificados TLS y los registros.

timedatectl status
df -h /
free -h
getent hosts changes.example.com

Sustituya changes.example.com por su dominio. El resultado del último comando debe mostrar la IP pública de su VPS.

Instalación del software — paso a paso

Para la ejecución aislada se utilizan Docker Engine 28.x y Docker Compose Plugin v2. Docker permite actualizar la aplicación con un solo comando, no mezclar las dependencias con el sistema operativo y guardar cómodamente los datos en un volume independiente. Las imágenes de la aplicación se cargarán desde GitHub Container Registry.

Instalación de Docker Engine desde el repositorio oficial

Elimine los paquetes antiguos de Docker si se instalaron desde el repositorio estándar de Ubuntu. El comando es seguro en un servidor nuevo.

sudo apt remove -y docker.io docker-compose docker-compose-v2 podman-docker containerd runc || true

Añada la clave y el repositorio de Docker. Se utiliza el repositorio oficial de Docker para Ubuntu 24.04.

sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg

echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
  $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

sudo apt update

Instale Docker Engine, Buildx y Compose Plugin. En 2026 se recomienda utilizar Compose como el subcomando docker compose, en lugar de la antigua utilidad independiente docker-compose.

sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
sudo systemctl enable --now docker
sudo docker version
sudo docker compose version

Permita que el usuario deploy trabaje con Docker sin utilizar sudo constantemente. Después deberá volver a iniciar sesión.

sudo usermod -aG docker deploy
exit

Vuelva a conectarse y compruebe el acceso.

ssh deploy@SERVER_IP
docker run --rm hello-world

Creación de la estructura de directorios

No almacene los archivos del proyecto en el directorio personal de root. Crearemos el directorio /opt/changedetection, accesible para el usuario deploy. Contendrá la configuración de Compose, las variables de entorno, el Caddyfile y un directorio local de copias de seguridad.

sudo mkdir -p /opt/changedetection/{caddy,data,backups,scripts}
sudo chown -R deploy:deploy /opt/changedetection
cd /opt/changedetection
pwd

Creación del archivo de variables de entorno

El archivo .env no debe incluirse en un repositorio Git público. Aquí se definen el dominio, la zona horaria y la URL base. No es obligatorio añadir los secretos de Telegram a este archivo: puede guardarlos en la interfaz de la aplicación, y los tokens se almacenarán en sus datos. Si aun así automatiza la configuración, guarde los tokens únicamente en un archivo privado con permisos 600.

cd /opt/changedetection

cat > .env <<'EOF'
CD_DOMAIN=changes.example.com
TZ=Europe/Moscow
BASE_URL=https://changes.example.com
EOF

chmod 600 .env

Cambie el dominio y la zona horaria por sus propios valores. Puede consultar la lista de zonas horarias con el comando timedatectl list-timezones.

Creación de la configuración de Docker Compose

El contenedor principal de ChangeDetection.io escuchará únicamente en la dirección local 127.0.0.1:5000. Caddy accederá a él a través de la red interna de Docker. Esta restricción impide eludir el proxy HTTPS mediante el acceso directo al puerto 5000 desde el exterior.

cat > docker-compose.yml <<'EOF'
services:
  changedetection:
    image: ghcr.io/dgtlmoon/changedetection.io:latest
    container_name: changedetection
    restart: unless-stopped
    environment:
      - TZ=${TZ}
      - BASE_URL=${BASE_URL}
      - USE_X_SETTINGS=1
    volumes:
      - ./data:/datastore
    expose:
      - "5000"
    networks:
      - monitor_net

  caddy:
    image: caddy:2.10-alpine
    container_name: changedetection-caddy
    restart: unless-stopped
    env_file:
      - .env
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./caddy/Caddyfile:/etc/caddy/Caddyfile:ro
      - ./caddy/data:/data
      - ./caddy/config:/config
    networks:
      - monitor_net

networks:
  monitor_net:
    driver: bridge
EOF

La etiqueta latest resulta práctica para el primer inicio, pero en una instalación crítica es mejor fijar una versión concreta o el digest de la imagen después de realizar pruebas satisfactorias. Esto hace que las actualizaciones sean reproducibles y reduce el riesgo de cambios inesperados de comportamiento en el siguiente pull.

Primer inicio de los contenedores

En esta etapa aún no se ha creado el Caddyfile, por lo que debe prepararlo primero en la sección siguiente. Después de crear los archivos, ejecute el inicio. Docker descargará las imágenes y creará la red y los directorios de volume.

cd /opt/changedetection
docker compose config
docker compose pull
docker compose up -d
docker compose ps

El comando docker compose config comprueba la sintaxis y la sustitución de variables. En docker compose ps, ambos contenedores deben tener el estado running.

Configuración

Configuración de HTTPS mediante Caddy

Caddy obtiene y renueva automáticamente los certificados TLS de Let's Encrypt. Para ello, el dominio debe estar disponible desde Internet a través de los puertos 80 y 443. En el Caddyfile no es necesario indicar manualmente las rutas de los certificados.

cd /opt/changedetection

cat > caddy/Caddyfile <<'EOF'
{
    email [email protected]
}

{$CD_DOMAIN} {
    encode zstd gzip

    reverse_proxy changedetection:5000 {
        header_up Host {host}
        header_up X-Real-IP {remote_host}
        header_up X-Forwarded-For {remote_host}
        header_up X-Forwarded-Proto {scheme}
    }

    log {
        output stdout
        format json
    }
}
EOF

Sustituya [email protected] por una dirección operativa para recibir notificaciones sobre problemas con el certificado. Después, reinicie el stack.

cd /opt/changedetection
docker compose up -d
docker compose logs -f caddy

En los registros de Caddy, busque el mensaje que confirma la obtención satisfactoria del certificado. Para salir de la vista de registros, pulse Ctrl+C; el contenedor continuará funcionando. Después, abra https://changes.example.com en el navegador.

Comprobación del funcionamiento

Compruebe la respuesta del servidor desde el propio VPS y desde un ordenador local. La comprobación por dominio debe devolver el código HTTP 200 o una redirección a la página de la aplicación.

curl -I http://127.0.0.1:5000
curl -I https://changes.example.com
docker compose ps
docker compose logs --tail=100 changedetection

Si el primer comando no funciona, el problema está dentro del contenedor de ChangeDetection.io. Si la comprobación local es correcta, pero el dominio no se abre, compruebe el DNS, el firewall, los puertos 80/443 y los registros de Caddy.

Configuración inicial en la interfaz web

Abra el dominio en el navegador. En la versión actual de ChangeDetection.io verá un formulario para añadir una nueva URL. Para la primera prueba, utilice una página pública estable, como la página de documentación del proyecto o la página de estado de un servicio. No comience las pruebas con un sitio que utilice activamente CAPTCHA y protección antibots.

1. Pulse el botón para añadir una nueva comprobación.
2. Indique la URL de la página.
3. Seleccione el intervalo de comprobación: para la prueba, 30–60 minutos son suficientes.
4. Guarde la monitorización.
5. Inicie una comprobación manual con el botón de comprobación.
6. Abra el historial y asegúrese de que se ha creado la primera captura.

Por lo general, el primer guardado de la página no se considera un cambio, porque el servicio debe crear una versión inicial para la comparación. La notificación aparecerá después del siguiente resultado diferente.

Filtrado mediante selector CSS y texto

La monitorización de toda la página suele generar notificaciones innecesarias: cambian los banners, la fecha de publicación, los contadores, la publicidad y los bloques de recomendaciones. Es mejor extraer únicamente la parte relevante de la página. Para ello, utilice un selector CSS en la configuración de la monitorización.

Por ejemplo, para el precio de un producto, el selector puede ser similar a .product-price, [data-testid="price"] o span.price. Puede encontrarlo mediante las herramientas de desarrollo del navegador: abra la página, pulse F12, seleccione el elemento deseado y consulte sus clases, atributos y estructura HTML.

Después de añadir el selector, inicie manualmente una comprobación. Si en el historial aparece únicamente el fragmento esperado, la configuración funciona. Si el resultado está vacío, el selector es incorrecto o el elemento necesario se crea mediante código JavaScript después de cargar la página.

Conexión de un navegador JavaScript cuando sea necesario

No todos los sitios entregan el contenido final mediante una solicitud HTTP normal. Las tiendas en línea, las interfaces SPA y los paneles modernos suelen representar los datos en el navegador. Para estas URL, conecte un contenedor de navegador independiente basado en Playwright. Hágalo únicamente después de comprobar que es necesario: la representación en el navegador requiere muchos más recursos.

Añada al docker-compose.yml un servicio de navegador y la variable PLAYWRIGHT_DRIVER_URL al servicio changedetection. La imagen compatible concreta debe comprobarse en la documentación actualizada de ChangeDetection.io antes de realizar la actualización, ya que la compatibilidad del controlador del navegador depende de la versión de la aplicación.

  changedetection:
    environment:
      - TZ=${TZ}
      - BASE_URL=${BASE_URL}
      - USE_X_SETTINGS=1
      - PLAYWRIGHT_DRIVER_URL=ws://playwright:3000

  playwright:
    image: browserless/chromium:latest
    container_name: changedetection-playwright
    restart: unless-stopped
    environment:
      - TOKEN=change-this-browser-token
      - MAX_CONCURRENT_SESSIONS=2
      - CONNECTION_TIMEOUT=60000
    networks:
      - monitor_net

En una configuración de producción, no deje latest ni el token de demostración. Fije una versión comprobada de la imagen, establezca un token aleatorio mediante .env y limite el número de sesiones simultáneas según la RAM del servidor. En un VPS con 2 GB de memoria, comience con un solo worker del navegador.

Configuración de las notificaciones de Telegram

Telegram es un canal práctico para recibir notificaciones inmediatas. Cree un bot mediante la cuenta oficial @BotFather. Envíe el comando /newbot, indique el nombre y el username, y guarde el token de API proporcionado. Este token permite enviar mensajes en nombre del bot, por lo que no debe publicarlo en capturas de pantalla, repositorios Git ni en el historial de shell.

A continuación, abra un chat privado con el bot creado y envíele el comando /start. Para un grupo, añada el bot al grupo, envíe un mensaje y, si es necesario, concédale permisos de publicación. Para averiguar el chat_id, puede abrir temporalmente la URL de la API de Telegram después de enviar un mensaje al bot:

curl "https://api.telegram.org/botВАШ_ТОКЕН/getUpdates"

En la respuesta JSON, busque el campo chat y, después, el valor de id. En los chats grupales, el ID suele comenzar con un signo menos. Después de obtener el ID, elimine el comando del historial del terminal o utilice una variable temporal de shell para que el token no se guarde en el history.

export TG_TOKEN='ВАШ_ТОКЕН'
curl "https://api.telegram.org/bot${TG_TOKEN}/getUpdates"
unset TG_TOKEN

En ChangeDetection.io, abra la configuración de notificaciones. En el campo de URL de notificación, añada una dirección de Telegram de Apprise con el formato:

tgram://BOT_TOKEN/CHAT_ID

Sustituya el token y el ID del chat. Si la interfaz ofrece un botón para enviar una prueba, utilícelo antes de asociar la notificación a decenas de páginas. En condiciones normales, el bot enviará inmediatamente un mensaje de prueba. Para determinadas monitorizaciones, puede sobrescribir las notificaciones globales y dirigir distintas categorías de sitios a diferentes grupos de Telegram.

Protección básica de la interfaz web

ChangeDetection.io contiene una lista de sitios monitorizados y un historial de cambios, por lo que no deje la interfaz abierta a todo Internet si no es necesario que sea pública. La opción mínima consiste en utilizar la autenticación integrada de la aplicación, si está disponible en la versión actual. Como alternativa, añada Basic Auth en el nivel de Caddy.

docker run --rm caddy:2.10-alpine caddy hash-password --plaintext 'СЛОЖНЫЙ_ПАРОЛЬ'

Copie el hash obtenido y añádalo al bloque del sitio del Caddyfile antes de reverse_proxy.

basic_auth {
    monitor $2a$14$REPLACE_WITH_GENERATED_BCRYPT_HASH
}

Después de modificar el Caddyfile, aplique la configuración reiniciando el contenedor.

cd /opt/changedetection
docker compose restart caddy
docker compose logs --tail=50 caddy

Basic Auth crea una barrera adicional antes de acceder a la aplicación. Utilice una contraseña larga y única, y no la transmita en la URL. Si es necesario, restrinja el acceso por IP mediante un firewall o una VPN, especialmente si se trata de una herramienta de trabajo interna.

Copias de seguridad y mantenimiento

Los contenedores Docker se pueden volver a crear en cualquier momento, pero los datos de ChangeDetection.io no se pueden recuperar sin una copia de seguridad. En el esquema actual, el directorio crítico es /opt/changedetection/data. Contiene la base de datos, la configuración de las monitorizaciones, el historial de comprobaciones, las capturas de pantalla y otros datos de la aplicación. También hay que conservar docker-compose.yml, .env, Caddyfile y el directorio de Caddy con los certificados.

Qué incluir en la copia de seguridad

No considere una copia en el mismo disco como una copia de seguridad. Si se elimina el VPS, se daña el sistema de archivos o se bloquea la cuenta, el archivo local no servirá de ayuda. Conserve las copias de seguridad al menos en una ubicación externa: un bucket compatible con S3, un servidor separado mediante SFTP/SSH o un almacenamiento de backup especializado.

Instalación de Restic

Restic crea copias de seguridad cifradas y deduplicadas. Es adecuado para servidores pequeños: solo se transfieren los bloques de datos nuevos y el acceso al almacenamiento se protege con la contraseña del repositorio. A continuación se muestra una opción para un almacenamiento compatible con S3.

sudo apt update
sudo apt install -y restic
restic version

Cree un archivo privado con los parámetros. En el ejemplo se utilizan variables para S3. Sustituya el endpoint, el nombre del bucket, las claves y una contraseña larga y única. No utilice la contraseña de SSH ni la del panel de hosting.

sudo tee /etc/changedetection-backup.env > /dev/null <<'EOF'
export RESTIC_REPOSITORY="s3:https://s3.example.com/changedetection-backups"
export AWS_ACCESS_KEY_ID="S3_ACCESS_KEY"
export AWS_SECRET_ACCESS_KEY="S3_SECRET_KEY"
export RESTIC_PASSWORD="LONG_UNIQUE_RESTIC_PASSWORD"
EOF

sudo chmod 600 /etc/changedetection-backup.env
sudo chown root:root /etc/changedetection-backup.env

Inicialice el repositorio. Esta operación se realiza una sola vez.

sudo bash -c 'source /etc/changedetection-backup.env && restic init'

Script de backup automático

Para garantizar la coherencia, es mejor detener brevemente el contenedor de la aplicación antes de copiar su base de datos y volver a iniciarlo después. Con un volumen de datos pequeño, la detención normalmente dura unos segundos. Caddy seguirá respondiendo, pero la aplicación no estará disponible temporalmente.

sudo tee /opt/changedetection/scripts/backup.sh > /dev/null <<'EOF'
#!/usr/bin/env bash
set -euo pipefail

PROJECT_DIR="/opt/changedetection"
LOG_FILE="/var/log/changedetection-backup.log"

source /etc/changedetection-backup.env

echo "[$(date -Is)] Backup started" >> "$LOG_FILE"

cd "$PROJECT_DIR"

docker compose stop changedetection

trap 'docker compose start changedetection' EXIT

restic backup \
  "$PROJECT_DIR/data" \
  "$PROJECT_DIR/docker-compose.yml" \
  "$PROJECT_DIR/.env" \
  "$PROJECT_DIR/caddy/Caddyfile" \
  "$PROJECT_DIR/caddy/data" \
  --tag changedetection \
  --tag "$(hostname)"

restic forget \
  --keep-daily 7 \
  --keep-weekly 4 \
  --keep-monthly 6 \
  --prune

echo "[$(date -Is)] Backup completed" >> "$LOG_FILE"
EOF

sudo chmod 700 /opt/changedetection/scripts/backup.sh
sudo chown root:root /opt/changedetection/scripts/backup.sh

El script conserva siete puntos de recuperación diarios, cuatro semanales y seis mensuales. Esta política es adecuada para la mayoría de las instalaciones pequeñas. Si el historial de cambios es especialmente valioso, aumente la retención mensual o cree una copia mensual en un bucket separado.

Ejecute manualmente la copia de seguridad y asegúrese de que el contenedor vuelva a funcionar.

sudo /opt/changedetection/scripts/backup.sh
sudo bash -c 'source /etc/changedetection-backup.env && restic snapshots'
cd /opt/changedetection && docker compose ps

Programador cron

Ejecute el backup por la noche, por ejemplo diariamente a las 03:20. Abra el crontab del usuario root.

sudo crontab -e

Añada la línea:

20 3   * /opt/changedetection/scripts/backup.sh

Revise los registros después de la primera noche. Cron normalmente funciona con un entorno mínimo, por lo que el script carga explícitamente el archivo con las variables de S3.

sudo tail -n 100 /var/log/changedetection-backup.log
sudo grep CRON /var/log/syslog | tail -n 20

Comprobación de la restauración

Un backup sin una prueba de restauración es solo una suposición. Cada varios meses, restaure una copia en un directorio temporal separado o en un VPS de prueba. No restaure sobre los datos de producción antes de realizar la comprobación.

sudo mkdir -p /tmp/changedetection-restore-test
sudo bash -c 'source /etc/changedetection-backup.env && restic restore latest --target /tmp/changedetection-restore-test'
sudo find /tmp/changedetection-restore-test -maxdepth 3 -type f | head

Después de la comprobación, elimine el directorio temporal. Para una recuperación completa ante desastres, instale Docker en un servidor nuevo, copie los archivos de Compose, restaure el directorio en /opt/changedetection, configure el DNS y ejecute docker compose up -d.

Actualización de ChangeDetection.io e imágenes de Docker

Para una instancia de ChangeDetection.io suele ser suficiente una breve ventana de mantenimiento. Antes de actualizar, realice un backup, revise las release notes del proyecto y solo después descargue la nueva imagen. No actualice la aplicación automáticamente cuando no pueda comprobar el resultado.

cd /opt/changedetection
sudo /opt/changedetection/scripts/backup.sh
docker compose pull
docker compose up -d
docker image prune -f
docker compose ps
docker compose logs --tail=100 changedetection

Con una sola réplica no se puede realizar una actualización rolling completa sin una breve interrupción: el contenedor se vuelve a crear. Para la monitorización doméstica y de equipos esto es normal. Un esquema de alta disponibilidad requeriría una base de datos independiente, almacenamiento compartido, un balanceador y pruebas de compatibilidad, lo que normalmente resulta excesivo para esta tarea.

Actualice el sistema operativo con regularidad, por ejemplo una vez a la semana o al mes. Después de actualizar el kernel, reinicie el servidor durante una ventana programada.

sudo apt update
sudo apt upgrade -y
sudo reboot

Solución de problemas y FAQ

¿Por qué el dominio se abre por HTTP, pero no se emite el certificado HTTPS?

Primero compruebe que el registro A del dominio apunta a la IP del VPS: getent hosts ваш-домен. Después asegúrese de que los puertos 80 y 443 están permitidos en UFW y en el firewall de red del panel del proveedor. Consulte docker compose logs caddy: normalmente allí se indica la causa exacta, por ejemplo un DNS incorrecto, un puerto cerrado o demasiados intentos de emisión del certificado. Compruebe también que otro servidor web no esté ocupando los puertos 80 y 443.

El contenedor de ChangeDetection.io se reinicia constantemente. ¿Qué debo comprobar?

Ejecute docker compose logs --tail=200 changedetection y compruebe si hay errores de acceso al directorio data, una base de datos dañada o falta de espacio. El comando df -h mostrará el uso del disco y free -h la memoria disponible. Si el proceso fue terminado por el kernel debido a falta de RAM, en dmesg -T puede haber registros OOM. Aumente la memoria del VPS, desactive el contenedor del navegador o reduzca el número de comprobaciones simultáneas.

¿Por qué no llegan las notificaciones de Telegram?

Compruebe que el usuario o grupo haya enviado primero un mensaje al bot o el comando /start: el bot no puede escribir primero al usuario. Asegúrese de que el token y el chat_id sean correctos, especialmente en los grupos, donde el ID suele ser negativo. Compruebe la notificación mediante el botón de prueba integrado en la interfaz. Si la prueba no funciona, solicite de nuevo getUpdates a la API de Telegram y asegúrese de que la configuración contiene una URL de Apprise correcta con el formato tgram://BOT_TOKEN/CHAT_ID.

El sitio muestra un resultado vacío o no detecta un precio que aparece en el navegador. ¿Cómo lo soluciono?

Primero abra la captura guardada en ChangeDetection.io. Si el bloque necesario no aparece en ella, probablemente el sitio genere el contenido mediante código JavaScript, requiera cookies, geolocalización o bloquee la IP del servidor. Intente configurar un selector CSS para la parte estática, cambiar el user-agent en la configuración de la monitorización o conectar un navegador Playwright. No intente eludir CAPTCHA ni los mecanismos de protección del sitio sin permiso del propietario del recurso.

¿Qué configuración mínima de VPS es adecuada?

El mínimo para entre 10 y 30 comprobaciones HTML normales es 1 vCPU, 1–2 GB de RAM y 25 GB de SSD. Es más práctico comenzar con 2 vCPU, 4 GB de RAM y 50 GB de NVMe: habrá margen para Docker, el historial de cambios, el proxy TLS y varias páginas complejas. Si se utiliza Chromium o Playwright para renderizar JavaScript, 2 GB de memoria suelen ser insuficientes. Para las comprobaciones mediante navegador, el mínimo razonable es 4 GB de RAM.

¿Qué elegir: VPS o dedicated para esta tarea?

Para la mayoría de las instalaciones, elija un VPS. Es más barato, escala más rápido y gestiona sin problemas decenas o cientos de URL normales. Un dedicated tiene sentido con miles de comprobaciones frecuentes, numerosas sesiones de navegador simultáneas, un archivo grande de capturas o requisitos de rendimiento de CPU garantizado. Antes de pasar a un servidor dedicado, mida el consumo real de recursos mediante docker stats en lugar de basarse únicamente en el número de URL.

Después de la actualización desaparecieron la configuración o el historial de monitorizaciones. ¿Por qué?

La causa más frecuente es iniciar el contenedor sin el montaje anterior ./data:/datastore o ejecutar Compose desde otro directorio. Compruebe la ruta en docker-compose.yml, el directorio actual del proyecto y la existencia de archivos en /opt/changedetection/data. No elimine los volumes ni el directorio de datos al limpiar Docker. Si los datos se eliminaron realmente, detenga la aplicación y restaure la última copia de seguridad de Restic en la ruta original.

¿Por qué el servidor recibió un bloqueo o CAPTCHA del sitio monitorizado?

Lo más probable es que las solicitudes se ejecuten con demasiada frecuencia, de forma demasiado simultánea o que el sitio prohíba el acceso automatizado. Aumente el intervalo entre comprobaciones, reduzca el número de tareas simultáneas, desactive los reintentos rápidos y consulte las normas del recurso. Utilice la API oficial, el feed RSS o las notificaciones por correo electrónico del sitio si están disponibles. La monitorización debe ser respetuosa: la posibilidad técnica de cargar una página no siempre implica autorización para recopilar datos masivamente.

Conclusiones y próximos pasos

Ahora ChangeDetection.io funciona en su VPS con Docker, está disponible mediante HTTPS, envía los cambios a Telegram y está protegido mediante copias de seguridad externas. Este esquema es adecuado para la monitorización personal, las notificaciones de trabajo y los pequeños servicios internos.

1. Añada las primeras 5–10 monitorizaciones y configure para cada una un selector CSS preciso para eliminar los cambios falsos.
2. Compruebe el tamaño del directorio data después de un mes y ajuste el espacio del disco o el período de retención de las copias de seguridad.
3. Si aparecen sitios con JavaScript, pruebe por separado el contenedor de Playwright y aumente la RAM antes de activar masivamente el renderizado mediante navegador.