Встановлення ChangeDetection.io на VPS: моніторинг змін сайтів, Telegram-сповіщення та Docker-бекапи

Що ми налаштовуємо і навіщо

ChangeDetection.io — відкрита вебпрограма для відстеження змін на сайтах. Вона регулярно завантажує вказані URL-адреси, порівнює нову версію сторінки з попередньою та надсилає сповіщення, якщо вміст змінився. На відміну від простого HTTP-моніторингу, сервіс уміє перевіряти саме текст, HTML, окремий CSS-селектор, JSON-відповідь API та візуальний вміст сторінок.

Практичні сценарії використання зазвичай виглядають так:

• відстеження ціни товару, авіаквитка, квитків на захід або курсу валют;
• контроль появи товару в наявності;
• моніторинг нових вакансій на сторінці компанії;
• відстеження змін у публічних офертах, правилах, тарифах і документації;
• контроль змін на сайті конкурента;
• перевірка публічних тендерів, закупівель, реєстрів і державних порталів;
• моніторинг статусу хмарного сервісу, CDN, API або сторінки статусу;
• отримання сповіщення про вихід оновлення програмного продукту.

Після налаштування у вас буде власний екземпляр ChangeDetection.io, доступний через HTTPS-домен. У ньому можна створювати перевірки через вебінтерфейс, обирати інтервал запуску, налаштовувати текстові фільтри та отримувати повідомлення в Telegram. Дані моніторингу залишаться під вашим контролем: історія, URL, знімки сторінок і токени сповіщень не передаються до стороннього SaaS-сервісу.

Як працює перевірка змін

Для кожної сторінки, що відстежується, ChangeDetection.io зберігає попередній результат. Під час наступної перевірки сервіс завантажує сторінку знову, нормалізує вміст і обчислює різницю. Якщо відмінності відповідають заданим правилам, створюється подія зміни. Для неї можна відкрити diff у браузері, побачити доданий і видалений текст, а потім отримати сповіщення через Telegram, e-mail, Discord, Slack, Matrix, webhook або інші канали, які підтримує Apprise.

Для простих HTML-сторінок використовується звичайний HTTP-запит. Цього достатньо для каталогів, документації, сторінок товарів і більшості сайтів без складного клієнтського рендерингу. Якщо контент з'являється лише після виконання JavaScript, знадобиться браузерний рушій Playwright. Його варто підключати лише за потреби: повноцінний браузер споживає помітно більше пам'яті та CPU, ніж звичайна HTTP-перевірка.

Cloud-managed сервіси та self-hosted варіант

Self-hosted встановлення особливо корисне, якщо потрібно моніторити десятки або сотні сторінок, не хочеться передавати третій стороні список відстежуваних ресурсів або потрібна інтеграція з внутрішніми системами. Однак VPS не скасовує відповідальність: необхідно оновлювати ОС, закривати зайві порти, робити резервні копії та не створювати надмірне навантаження на чужі сайти.

Не встановлюйте надто короткий інтервал опитування без потреби. Перевірки публічної сторінки кожні 5–15 хвилин зазвичай достатньо. Часті запити можуть призвести до CAPTCHA, блокування IP або порушення правил конкретного сайту.

Яка VPS-конфігурація потрібна для цього завдання

Навантаження ChangeDetection.io залежить не стільки від кількості збережених URL, скільки від частоти перевірок і типу сторінок. Сто простих HTML-сторінок, що перевіряються раз на годину, майже не навантажують сервер. Десятки сторінок із JavaScript, авторизацією або антибот-захистом можуть потребувати більше CPU та пам'яті, особливо якщо одночасно запускається браузерний рендеринг.

Для особистого моніторингу, команди з кількох людей або 50–100 нескладних сторінок раціональний старт — 2 vCPU, 4 ГБ RAM, 50 ГБ NVMe та IPv4-адреса. Наприклад, можна взяти VPS із зазначеними характеристиками, встановити Ubuntu Server 24.04 LTS і розгорнути весь стек у Docker Compose.

Чому важливий запас дискового простору

Сервіс зберігає історію змін і знімки сторінок, що перевіряються. Одна текстова сторінка займає небагато місця, але великі HTML-документи, зображення, довга історія diff і велика кількість URL поступово збільшують volume. Не заповнюйте диск до межі: Docker і база даних потребують вільного простору для тимчасових файлів, журналів і коректного запису даних.

Корисне правило — тримати щонайменше 20–30% вільного простору. Раз на місяць перевіряйте розмір Docker volume і видаляйте невикористовувані Docker-образи. Не виконуйте агресивне очищення volumes: саме в них містяться користувацькі дані програми.

Коли потрібен dedicated, а не VPS

Звичайний VPS підходить майже для всіх особистих і невеликих комерційних інсталяцій. Dedicated-сервер виправданий, якщо ви запускаєте багато браузерних воркерів, постійно обробляєте тисячі JavaScript-сторінок, потребуєте гарантованого CPU без впливу сусідів або зберігаєте велику історію знімків. Він також може бути корисним, коли ChangeDetection.io стає частиною внутрішньої платформи моніторингу з кількома операторами та окремими проксі.

Не переходьте на dedicated лише через кілька повільних сторінок. Спочатку збільште RAM до 4–8 ГБ, зменште паралелізм, подовжте інтервали перевірок і перевірте, чи справді всім URL потрібен браузерний рендеринг.

Як вибрати локацію

Локація впливає на затримку, географічну версію сайту та ймовірність антибот-перевірок. Якщо ви стежите за російськими, європейськими або американськими сайтами, обирайте сервер ближче до їхньої основної аудиторії. Деякі магазини та сервіси показують різні ціни, валюти, наявність і контент залежно від IP-адреси. У такому разі сервер має перебувати в країні або регіоні, для якого ви хочете отримувати дані.

Для панелі керування локація менш критична: інтерфейс легкий і працює через HTTPS. Важливіші стабільність мережі, доступний IPv4, достатній трафік і можливість налаштувати DNS-запис для домену.

Підготовка сервера

Нижче використовується Ubuntu Server 24.04 LTS. На момент підготовки посібника це стабільний LTS-реліз, що підходить для Docker-хостів. Команди також схожі для Debian 12, але назви деяких пакетів і налаштування firewall можуть відрізнятися.

Передбачається, що сервер уже має публічну IPv4-адресу, а в панелі DNS створено A-запис, наприклад changes.example.com, що вказує на цю адресу. Без коректного DNS-запису Caddy не зможе автоматично випустити сертифікат Let's Encrypt.

Перший вхід і оновлення системи

Підключіться під користувачем root лише для початкового налаштування. Відразу оновіть систему, створіть звичайного користувача та перенесіть до нього SSH-ключ. Надалі не працюйте в панелі ChangeDetection.io і Docker від імені root без причини.

ssh root@SERVER_IP

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

Після перезавантаження підключіться знову та створіть користувача. У прикладі використовується ім'я deploy; замініть його на своє.

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

Скопіюйте свій публічний ключ із локального комп'ютера. Команда виконується на локальній машині, а не на сервері.

ssh-copy-id deploy@SERVER_IP

Перевірте вхід у новій сесії до вимкнення root-доступу.

ssh deploy@SERVER_IP
sudo whoami

Очікуваний результат останньої команди — root. Це означає, що користувач може виконувати адміністративні дії через sudo.

Захист SSH

Відкрийте окрему SSH-сесію та не закривайте стару, доки не переконаєтеся, що вхід за ключем працює. Потім створіть окремий конфігураційний файл SSH. Такий підхід безпечніший, ніж редагування основного файлу пакета.

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

Команда sshd -t перевіряє синтаксис перед перезапуском служби. Якщо тест завершився без помилок, конфігурація коректна. Тепер root-вхід і автентифікацію за паролем вимкнено, а підключення можливе лише за SSH-ключем.

Firewall і Fail2ban

ChangeDetection.io не повинен безпосередньо слухати публічний порт. Ззовні будуть доступні лише SSH, HTTP для випуску TLS-сертифіката та HTTPS для панелі. Docker-порт програми залишиться доступним лише на 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

Перевірте, що у виводі дозволені лише порти 22, 80 і 443. Якщо SSH працює на нестандартному порту, спочатку дозвольте саме його, інакше можна втратити доступ до сервера.

Fail2ban блокує IP-адреси після серії невдалих спроб входу. Для Ubuntu достатньо увімкнути сервіс і додати просту локальну конфігурацію.

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

Базові перевірки хоста

Перед встановленням Docker переконайтеся, що час синхронізовано, на диску достатньо вільного місця, а DNS-домен уже вказує на сервер. Неправильний час спричиняє проблеми з TLS-сертифікатами та журналами.

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

Замініть changes.example.com на свій домен. У результаті останньої команди має відображатися публічний IP вашого VPS.

Встановлення ПЗ — покроково

Для ізольованого запуску використовується Docker Engine 28.x і Docker Compose Plugin v2. Docker дає змогу оновлювати застосунок однією командою, не змішувати залежності з ОС і зручно зберігати дані в окремому volume. Образи застосунку завантажуватимуться з GitHub Container Registry.

Встановлення Docker Engine з офіційного репозиторію

Видаліть старі пакети Docker, якщо їх було встановлено зі стандартного репозиторію Ubuntu. Команда безпечна на новому сервері.

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

Додайте ключ і репозиторій Docker. Використовується офіційний репозиторій Docker для 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

Встановіть Docker Engine, Buildx і Compose Plugin. У 2026 році Compose рекомендовано використовувати як підкоманду docker compose, а не стару окрему утиліту 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

Дозвольте користувачу deploy працювати з Docker без постійного sudo. Після цього необхідно повторно увійти в систему.

sudo usermod -aG docker deploy
exit

Підключіться знову та перевірте доступ.

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

Створення структури каталогів

Не зберігайте файли проєкту в домашньому каталозі root. Створимо каталог /opt/changedetection, доступний користувачу deploy. У ньому будуть Compose-конфігурація, змінні середовища, Caddyfile та локальний каталог резервних копій.

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

Створення файлу змінних середовища

Файл .env не повинен потрапляти до публічного Git-репозиторію. Тут задаються домен, часовий пояс і базовий URL. Секрети Telegram додавати до цього файлу не обов’язково: їх можна зберегти в інтерфейсі застосунку, а токени перебуватимуть у його даних. Якщо ви все ж автоматизуєте конфігурацію, зберігайте токени лише в закритому файлі з правами 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

Змініть домен і часовий пояс на власні значення. Список часових поясів можна переглянути командою timedatectl list-timezones.

Створення Docker Compose-конфігурації

Основний контейнер ChangeDetection.io слухатиме лише локальну адресу 127.0.0.1:5000. Caddy отримає доступ до нього через внутрішню Docker-мережу. Таке обмеження виключає обхід HTTPS-проксі через прямий доступ до порту 5000 ззовні.

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

Тег latest зручний для першого запуску, але для критичної інсталяції краще після успішного тестування закріпити конкретний реліз або digest образу. Це робить оновлення відтворюваними та знижує ризик неочікуваної зміни поведінки під час наступного pull.

Перший запуск контейнерів

На цьому етапі Caddyfile ще не створено, тому спочатку підготуйте його в наступному розділі. Після створення файлів виконайте запуск. Docker завантажить образи, створить мережу та volume-каталоги.

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

Команда docker compose config перевіряє синтаксис і підстановку змінних. У docker compose ps обидва контейнери повинні мати стан running.

Конфігурація

Налаштування HTTPS через Caddy

Caddy автоматично отримує та продовжує TLS-сертифікати Let's Encrypt. Для цього домен має бути доступний з інтернету через порти 80 і 443. У Caddyfile не потрібно вручну вказувати шляхи до сертифікатів.

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

Замініть [email protected] на робочу адресу для сповіщень про проблеми із сертифікатом. Потім перезапустіть стек.

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

У логах Caddy знайдіть повідомлення про успішне отримання сертифіката. Щоб вийти з перегляду логів, натисніть Ctrl+C; контейнер продовжить працювати. Після цього відкрийте https://changes.example.com у браузері.

Перевірка працездатності

Перевірте відповідь сервера із самого VPS та з локального комп’ютера. Перевірка за доменом має повернути HTTP-код 200 або перенаправлення на сторінку застосунку.

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

Якщо перша команда не працює, проблема всередині контейнера ChangeDetection.io. Якщо локальна перевірка успішна, але домен не відкривається, перевірте DNS, firewall, порти 80/443 і логи Caddy.

Початкове налаштування у вебінтерфейсі

Відкрийте домен у браузері. У поточній версії ChangeDetection.io ви побачите форму додавання нового URL. Для першого тесту використовуйте стабільну публічну сторінку, наприклад сторінку документації проєкту або сторінку зі статусом сервісу. Не починайте тестування із сайту, який активно використовує CAPTCHA та антибот-захист.

1. Натисніть додавання нової перевірки.
2. Вкажіть URL сторінки.
3. Виберіть інтервал перевірки: для тесту достатньо 30–60 хвилин.
4. Збережіть спостереження.
5. Запустіть ручну перевірку кнопкою перевірки.
6. Відкрийте історію та переконайтеся, що створено перший знімок.

Перше збереження сторінки зазвичай не вважається зміною, оскільки сервісу потрібно створити початкову версію для порівняння. Сповіщення з’явиться після наступного відмінного результату.

Фільтрація за CSS-селектором і текстом

Моніторинг усієї сторінки часто створює зайві сповіщення: змінюються банери, дата публікації, лічильники, реклама та блоки рекомендацій. Краще витягувати лише значущу частину сторінки. Для цього використовуйте CSS-селектор у налаштуваннях спостереження.

Наприклад, для ціни товару селектор може бути схожим на .product-price, [data-testid="price"] або span.price. Знайти його можна через інструменти розробника браузера: відкрийте сторінку, натисніть F12, виберіть потрібний елемент і перегляньте його класи, атрибути та структуру HTML.

Після додавання селектора вручну запустіть перевірку. Якщо в історії відображається лише очікуваний фрагмент, налаштування працює. Якщо результат порожній, селектор неправильний або потрібний елемент створюється JavaScript-кодом після завантаження сторінки.

Підключення JavaScript-браузера за потреби

Не всі сайти віддають кінцевий контент звичайними HTTP-запитами. Інтернет-магазини, SPA-інтерфейси та сучасні особисті кабінети часто відмальовують дані в браузері. Для таких URL підключіть окремий контейнер браузера на базі Playwright. Робіть це лише після перевірки: браузерний рендеринг помітно важчий.

Додайте до docker-compose.yml сервіс браузера та змінну PLAYWRIGHT_DRIVER_URL до сервісу changedetection. Конкретний підтримуваний образ слід звірити з актуальною документацією ChangeDetection.io перед оновленням, оскільки сумісність браузерного драйвера залежить від версії застосунку.

  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

Для production-конфігурації не залишайте latest і демонстраційний токен. Закріпіть перевірену версію образу, задайте випадковий токен через .env та обмежте кількість одночасних сесій відповідно до RAM сервера. На VPS з 2 ГБ пам’яті почніть з одного браузерного воркера.

Налаштування Telegram-сповіщень

Telegram — зручний канал для негайних сповіщень. Створіть бота через офіційний акаунт @BotFather. Надішліть команду /newbot, задайте ім’я, username і збережіть виданий API-токен. Цей токен надає доступ до надсилання повідомлень від імені бота, тому не публікуйте його на скриншотах, у Git-репозиторіях і shell history.

Потім відкрийте особистий діалог зі створеним ботом і надішліть йому команду /start. Для групи додайте бота до групи, надішліть повідомлення та за потреби надайте права на публікацію. Щоб дізнатися chat_id, можна тимчасово відкрити URL Telegram API після надсилання повідомлення боту:

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

У JSON-відповіді знайдіть поле chat, потім значення id. Для групових чатів ID часто починається з мінуса. Після отримання ID видаліть команду з історії термінала або використайте тимчасову shell-змінну, щоб токен не зберігався в history.

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

У ChangeDetection.io відкрийте налаштування сповіщень. У поле URL сповіщення додайте Apprise-адресу Telegram у форматі:

tgram://BOT_TOKEN/CHAT_ID

Підставте токен та ID чату. Якщо інтерфейс пропонує кнопку тестового надсилання, використайте її до прив’язування сповіщення до десятків сторінок. У нормальному випадку бот одразу надішле тестове повідомлення. Для окремих спостережень можна перевизначати глобальні сповіщення та спрямовувати різні категорії сайтів до різних Telegram-груп.

Базовий захист вебінтерфейсу

ChangeDetection.io містить список відстежуваних сайтів та історію змін, тому не залишайте інтерфейс відкритим для всього інтернету, якщо він не потрібен публічно. Мінімальний варіант — використовувати вбудовану автентифікацію застосунку, якщо вона доступна в поточному релізі. Альтернативно додайте Basic Auth на рівні Caddy.

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

Скопіюйте отриманий хеш і додайте його до блоку сайту Caddyfile перед reverse_proxy.

basic_auth {
    monitor $2a$14$REPLACE_WITH_GENERATED_BCRYPT_HASH
}

Після зміни Caddyfile застосуйте конфігурацію перезапуском контейнера.

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

Basic Auth створює додатковий бар’єр перед входом у застосунок. Використовуйте довгий унікальний пароль і не передавайте його в URL. За потреби обмежте доступ за IP через firewall або VPN, особливо якщо це внутрішній робочий інструмент.

Резервні копії та обслуговування

Контейнери Docker можна перестворити будь-якої миті, але дані ChangeDetection.io неможливо відновити без резервної копії. У поточній схемі критичний каталог — /opt/changedetection/data. У ньому містяться база даних, налаштування спостережень, історія перевірок, скриншоти та інші дані застосунку. Також потрібно зберігати docker-compose.yml, .env, Caddyfile і каталог Caddy із сертифікатами.

Що включати до резервної копії

Не вважайте копіювання на той самий диск резервною копією. Якщо VPS видалено, файлова система пошкоджена або акаунт заблокований, локальний архів не допоможе. Зберігайте резервні копії щонайменше в одному зовнішньому місці: S3-сумісному бакеті, окремому сервері через SFTP/SSH або спеціалізованому backup-сховищі.

Встановлення Restic

Restic створює зашифровані дедупліковані резервні копії. Він добре підходить для невеликих серверів: передаються лише нові блоки даних, а доступ до сховища захищається паролем репозиторію. Нижче показано варіант для S3-сумісного сховища.

sudo apt update
sudo apt install -y restic
restic version

Створіть закритий файл із параметрами. У прикладі використовуються змінні для S3. Підставте endpoint, ім'я бакета, ключі та довгий унікальний пароль. Не використовуйте пароль від SSH або панелі хостингу.

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

Ініціалізуйте репозиторій. Цю операцію виконують один раз.

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

Скрипт автоматичного бекапу

Для узгодженості краще на короткий час зупинити контейнер застосунку перед копіюванням його бази, а потім запустити знову. За невеликого обсягу даних зупинка зазвичай триває секунди. Caddy продовжить відповідати, але застосунок у цей момент буде тимчасово недоступний.

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

Скрипт зберігає сім денних, чотири тижневих і шість місячних точок відновлення. Політика підходить для більшості невеликих установок. Якщо історія змін особливо цінна, збільште місячний термін зберігання або створюйте щомісячну копію в окремому бакеті.

Запустіть резервне копіювання вручну та переконайтеся, що контейнер знову працює.

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

Планувальник cron

Запускайте бекап уночі, наприклад щодня о 03:20. Відкрийте crontab користувача root.

sudo crontab -e

Додайте рядок:

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

Перевірте логи після першої ночі. Cron зазвичай працює з мінімальним оточенням, тому скрипт явно завантажує файл зі змінними S3.

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

Перевірка відновлення

Бекап без тесту відновлення — лише припущення. Раз на кілька місяців відновлюйте копію в окремий тимчасовий каталог або на тестовий VPS. Не відновлюйте поверх production-даних до перевірки.

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

Після перевірки видаліть тимчасовий каталог. Для повного аварійного відновлення встановіть Docker на новий сервер, скопіюйте Compose-файли, відновіть каталог до /opt/changedetection, налаштуйте DNS і виконайте docker compose up -d.

Оновлення ChangeDetection.io та Docker-образів

Для одного екземпляра ChangeDetection.io зазвичай підходить коротке вікно обслуговування. Перед оновленням виконайте бекап, вивчіть release notes проєкту й лише потім завантажуйте новий образ. Не оновлюйте застосунок автоматично в момент, коли ви не можете перевірити результат.

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

За однієї репліки неможливо виконати повноцінне rolling-оновлення без короткої перерви: контейнер перестворюється. Для домашнього та командного моніторингу це нормально. Високодоступна схема потребуватиме окремої бази, спільного сховища, балансувальника та тестування сумісності, що зазвичай надмірно для цього завдання.

ОС оновлюйте регулярно, наприклад раз на тиждень або місяць. Після оновлення ядра перезавантажте сервер у заплановане вікно.

sudo apt update
sudo apt upgrade -y
sudo reboot

Troubleshooting і FAQ

Чому домен відкривається через HTTP, але HTTPS-сертифікат не випускається?

Спочатку перевірте, що A-запис домену вказує на IP VPS: getent hosts ваш-домен. Потім переконайтеся, що порти 80 і 443 дозволені в UFW та в мережевому firewall панелі провайдера. Перегляньте docker compose logs caddy: там зазвичай вказано точну причину, наприклад неправильний DNS, закритий порт або забагато спроб випуску сертифіката. Також переконайтеся, що інший вебсервер не займає порти 80 і 443.

Контейнер ChangeDetection.io постійно перезапускається. Що перевіряти?

Виконайте docker compose logs --tail=200 changedetection і перевірте помилки доступу до каталогу data, пошкоджену базу або нестачу місця. Команда df -h покаже заповнення диска, а free -h — доступну пам'ять. Якщо процес було завершено ядром через нестачу RAM, у dmesg -T можуть бути записи OOM. Збільште пам'ять VPS, вимкніть браузерний контейнер або зменште паралельні перевірки.

Чому не надходять Telegram-сповіщення?

Перевірте, що користувач або група спочатку надіслали боту повідомлення чи команду /start: бот не може першим написати користувачу. Переконайтеся в правильності токена та chat_id, особливо для груп, де ID часто від'ємний. Перевірте сповіщення вбудованою тестовою кнопкою в інтерфейсі. Якщо тест не працює, повторно запитайте getUpdates Telegram API та переконайтеся, що в налаштуванні вказано коректний Apprise URL формату tgram://BOT_TOKEN/CHAT_ID.

Сайт показує порожній результат або не бачить ціну, яка є в браузері. Як виправити?

Спочатку відкрийте збережений знімок у ChangeDetection.io. Якщо в ньому немає потрібного блоку, імовірно, сайт генерує контент JavaScript-кодом, потребує cookie, геолокацію або блокує серверний IP. Спробуйте налаштувати CSS-селектор для статичної частини, змінити user-agent у налаштуваннях спостереження або підключити Playwright-браузер. Не намагайтеся обходити CAPTCHA та захисні механізми сайту без дозволу власника ресурсу.

Яка VPS-конфігурація мінімально підійде?

Мінімум для 10–30 звичайних HTML-перевірок — 1 vCPU, 1–2 ГБ RAM і 25 ГБ SSD. Практичніше починати з 2 vCPU, 4 ГБ RAM і 50 ГБ NVMe: буде запас для Docker, історії змін, TLS-проксі та кількох складних сторінок. Якщо вмикається Chromium або Playwright для JavaScript-рендерингу, 2 ГБ пам'яті часто недостатньо. Для браузерних перевірок розумний мінімум — 4 ГБ RAM.

Що вибрати — VPS чи dedicated для цього завдання?

Для більшості установок обирайте VPS. Він дешевший, швидше масштабується та без проблем обслуговує десятки або сотні звичайних URL. Dedicated має сенс за тисяч частих перевірок, великої кількості паралельних браузерних сесій, великого архіву знімків або вимог до гарантованої продуктивності CPU. Перед переходом на виділений сервер виміряйте реальне споживання ресурсів через docker stats, а не орієнтуйтеся лише на кількість URL.

Після оновлення зникли налаштування або історія спостережень. Чому?

Найчастіше причина полягає в запуску контейнера без попереднього монтування ./data:/datastore або в запуску Compose з іншого каталогу. Перевірте шлях у docker-compose.yml, поточний каталог проєкту та наявність файлів у /opt/changedetection/data. Не видаляйте volumes або каталог даних під час очищення Docker. Якщо дані справді видалені, зупиніть застосунок і відновіть останню резервну копію Restic у вихідний шлях.

Чому сервер отримав блокування або CAPTCHA від відстежуваного сайту?

Найімовірніше, запити виконуються надто часто, надто паралельно або сайт забороняє автоматичний доступ. Збільште інтервал перевірок, зменште кількість одночасних завдань, вимкніть повторні швидкі спроби та ознайомтеся з правилами ресурсу. Використовуйте офіційний API, RSS-стрічку або e-mail-сповіщення сайту, якщо вони доступні. Моніторинг має бути обережним: технічна можливість завантажити сторінку не завжди означає дозвіл на масовий збір даних.

Висновки та наступні кроки

Тепер ChangeDetection.io працює на вашому VPS у Docker, доступний через HTTPS, надсилає зміни в Telegram і захищений зовнішніми резервними копіями. Така схема підходить для особистого моніторингу, робочих сповіщень і невеликих внутрішніх сервісів.

1. Додайте перші 5–10 спостережень і для кожного налаштуйте точний CSS-селектор, щоб прибрати хибні зміни.
2. Перевірте розмір каталогу data через місяць і скоригуйте обсяг диска або термін зберігання бекапів.
3. Якщо з'являються JavaScript-сайти, окремо протестуйте Playwright-контейнер і збільште RAM перед масовим увімкненням браузерного рендерингу.