Встановлення Gatus на VPS: моніторинг сайтів, SSL-сповіщення та повідомлення в Telegram

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

Gatus — open-source інструмент моніторингу доступності, написаний на Go. Він підходить для власника VPS, який хоче бачити стан власних сайтів, REST API, VPN-панелей, ігрових серверів, Git-сервісів, пошти або зовнішніх залежностей без передачі списку інфраструктури сторонньому SaaS-моніторингу.

Сервіс виконує перевірки за розкладом. Наприклад, він може надсилати HTTP-запит до https://example.com/health, переконатися, що сервер повернув код 200, перевірити JSON-поле відповіді, виміряти затримку й попередити, якщо SSL-сертифікат закінчується через 21 день. Для TCP-сервісів Gatus уміє перевіряти відкритий порт, а для ICMP — доступність вузла через ping.

У результаті у вас з’явиться вебпанель статусів за адресою на кшталт https://status.example.com, історія перевірок, час відповіді, відсоток доступності та Telegram-сповіщення. Сповіщення надсилаються не після одиничного випадкового тайм-ауту, а після заданої кількості послідовних помилок. Після відновлення Gatus також надішле окреме повідомлення.

Що саме буде розгорнуто

• Ubuntu Server 24.04 LTS або 26.04 LTS на VPS.
• Docker Engine 27+ або новіша стабільна версія.
• Docker Compose Plugin v2.
• Контейнер Gatus з офіційного образу twinproduction/gatus.
• Контейнер Caddy 2.9+ для reverse proxy і автоматичного HTTPS.
• SQLite-база Gatus у Docker volume.
• Конфігурація endpoint у YAML і секрети у файлі .env.
• Резервне копіювання конфігурацій і SQLite-бази через restic.

Які перевірки підтримує Gatus

Self-hosted Gatus чи хмарний моніторинг

Хмарні сервіси моніторингу зручні, якщо потрібно кілька географічно розподілених точок перевірки, SLA-звіти для клієнтів і мінімум адміністрування. Їхній мінус — щомісячна оплата, обмеження кількості перевірок на недорогих тарифах і передача даних про ваші домени, endpoint та інциденти зовнішньому провайдеру.

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

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

Gatus не потребує потужного сервера. Навантаження залежить від кількості endpoint, інтервалу перевірок, кількості TCP-з’єднань і часу зберігання історії. Для більшості особистих і невеликих комерційних проєктів обмежувальним фактором буде не CPU, а розумне зберігання SQLite-бази та стабільна мережа.

Практичний стартовий варіант — 1 vCPU, 2 ГБ RAM, 20 ГБ NVMe і публічний IPv4. Такого запасу достатньо для Gatus, Caddy, Docker, fail2ban, резервних копій конфігурації та кількох десятків перевірок щохвилини. Як один із нейтральних варіантів можна взяти VPS із зазначеними характеристиками, але орієнтуйтеся насамперед на близькість локації, якість мережі та наявність регулярних snapshots.

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

Для одного Gatus виділений сервер майже ніколи не потрібен. Dedicated має сенс, якщо моніторинг — лише частина великої observability-платформи: поруч працюють Prometheus, Grafana, Loki, Uptime Kuma, CI-система та сотні контейнерів. Він також корисний за вимог до ізоляції, великого обсягу логів або тисяч перевірок із короткими інтервалами.

Якщо ви просто перевіряєте 10–200 доменів і сервісів, VPS простіший, дешевший і швидше масштабується. У разі зростання навантаження перенесення Gatus на більший VPS зазвичай зводиться до відновлення файлів конфігурації та volume SQLite з бекапу.

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

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

Не встановлюйте Gatus на той самий хост, який він моніторить: у разі аварії сервера моніторинг також зникне. Мінімально розумна схема — окремий VPS. Для важливих проєктів використовуйте два незалежні екземпляри в різних країнах або у різних провайдерів і надсилайте сповіщення в різні Telegram-чати.

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

Нижче передбачається чистий сервер Ubuntu 24.04 LTS або Ubuntu 26.04 LTS із публічним IPv4, доменом status.example.com і DNS-записом типу A, що вказує на IP VPS. До випуску сертифіката переконайтеся, що DNS уже поширився: Caddy має бути доступним ззовні на портах 80 і 443.

Оновіть систему

Підключіться до сервера під користувачем, створеним під час провізіонування, або під root. Насамперед встановіть оновлення безпеки та базові утиліти.

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

Команди оновлюють пакети, встановлюють необхідні утиліти, firewall і захист від перебору паролів, а потім перезавантажують сервер.

Створіть окремого адміністратора

Не використовуйте постійну роботу під root. Створіть користувача, додайте його до групи sudo і заздалегідь додайте публічний SSH-ключ. У прикладі ім’я користувача — deploy.

sudo adduser deploy
sudo usermod -aG sudo deploy
sudo install -d -m 700 -o deploy -g deploy /home/deploy/.ssh
sudo nano /home/deploy/.ssh/authorized_keys
sudo chmod 600 /home/deploy/.ssh/authorized_keys
sudo chown deploy:deploy /home/deploy/.ssh/authorized_keys

У файл authorized_keys вставте один рядок вашого публічного ключа, наприклад вміст файлу ~/.ssh/id_ed25519.pub на локальному комп’ютері. Перед закриттям поточної SSH-сесії обов’язково перевірте вхід у новому терміналі.

ssh deploy@SERVER_IP

Ця команда перевіряє, що вхід за ключем справді працює для нового користувача.

Вимкніть SSH-вхід за паролем

Після перевірки ключа забороніть авторизацію за паролем і вхід root. Це суттєво зменшить імовірність компрометації сервера через автоматичні brute-force атаки.

sudo nano /etc/ssh/sshd_config.d/99-hardening.conf

PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
X11Forwarding no
MaxAuthTries 3

sudo sshd -t && sudo systemctl restart ssh

Команда перевіряє синтаксис SSH-конфігурації та перезапускає SSH лише за відсутності помилок.

Налаштуйте UFW і fail2ban

Панель Gatus має бути доступною через HTTPS, а HTTP потрібен Caddy для первинної перевірки домену та перенаправлення на HTTPS. Залишайте SSH відкритим лише після того, як переконаєтеся в можливості повторного підключення.

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

Команди вмикають firewall і залишають відкритими лише SSH, HTTP та HTTPS. Порт Gatus 8080 назовні відкривати не потрібно: він буде доступний лише контейнеру Caddy у внутрішній Docker-мережі.

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

Це вмикає fail2ban під час завантаження системи та показує статус захисту SSH. Якщо ви обмежуєте доступ до сервера фіксованими IP, додатково створіть правила UFW, що дозволяють SSH лише з вашої мережі.

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

Для розгортання використовуємо Docker Engine і Compose Plugin з офіційного репозиторію Docker. У 2026 році рекомендується використовувати актуальну стабільну гілку Docker Engine 27+ або новішу доступну версію, а не старий пакет docker.io зі стандартного репозиторію Ubuntu.

Додайте офіційний репозиторій Docker

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

Цей блок створює каталог для ключів APT і додає ключ підпису офіційного репозиторію Docker.

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

Команда додає репозиторій, що відповідає версії Ubuntu й архітектурі сервера, а потім оновлює індекс пакетів.

Встановіть Docker Engine і Compose

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

Цей блок встановлює Docker, вмикає його автозапуск і дозволяє користувачу deploy запускати Docker без sudo. Після виконання вийдіть із SSH-сесії та підключіться повторно, щоб оновилося членство в групах.

exit
ssh deploy@SERVER_IP
docker version
docker compose version

Переконайтеся, що Docker Engine і Compose Plugin доступні. Якщо команда docker ps видає помилку доступу до сокета, підключіться ще раз або виконайте newgrp docker.

Створіть структуру проєкту

Усі файли Gatus зберігатимуться в /opt/gatus. Такий каталог зручно резервувати, переносити та перевіряти через систему контролю конфігурації без секретів.

sudo mkdir -p /opt/gatus/{config,caddy,data,backups}
sudo chown -R deploy:deploy /opt/gatus
cd /opt/gatus
umask 077
touch .env
chmod 600 .env

Команди створюють робочі каталоги, передають право власності користувачу deploy і створюють закритий файл для Telegram-секретів.

Створіть Telegram-бота та дізнайтеся chat ID

Відкрийте в Telegram офіційний бот @BotFather, виконайте команду /newbot, задайте ім'я та username. BotFather поверне токен виду 123456789:AA.... Не публікуйте його в Git, тікетах, скриншотах або конфігурації, доступній іншим користувачам.

Створіть особистий чат із ботом, надішліть йому будь-яке повідомлення, наприклад /start. Для групового чату додайте бота до групи та надішліть повідомлення в цій групі. Отримайте ідентифікатор чату на сервері, підставивши токен:

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

У JSON знайдіть поле message.chat.id. Для Telegram-груп chat ID часто починається з мінуса, наприклад -1001234567890. Запишіть токен та ідентифікатор у /opt/gatus/.env.

cd /opt/gatus
nano .env

TELEGRAM_TOKEN=123456789:REPLACE_WITH_REAL_TOKEN
TELEGRAM_CHAT_ID=-1001234567890
GATUS_DOMAIN=status.example.com
[email protected]

У цьому файлі містяться секрети та параметри середовища. Він не повинен мати права читання для інших користувачів і не повинен потрапляти до публічного репозиторію.

Конфігурація Gatus, Telegram і HTTPS

У цій схемі Gatus слухає порт 8080 лише всередині Docker-мережі. Caddy приймає зовнішні запити на 80 і 443, автоматично отримує TLS-сертифікат і передає трафік до Gatus. Це виключає публікацію службового порту та позбавляє ручного обслуговування Let’s Encrypt.

Створіть шаблон конфігурації Gatus

Gatus використовує YAML. Ми зберігаємо шаблон config.yaml.template, а під час запуску Compose підставляє Telegram-змінні через envsubst. Так токен не потрапить до постійного YAML-файлу, який можна випадково закомітити.

cd /opt/gatus
nano config/config.yaml.template

storage:
  type: sqlite
  path: /data/gatus.db
  caching: true

ui:
  title: "Infrastructure Status"
  description: "Availability and SSL monitoring"
  default-sort-by: group

metrics: true

alerting:
  telegram:
    token: "${TELEGRAM_TOKEN}"
    id: "${TELEGRAM_CHAT_ID}"

endpoints:
  - name: Main website
    group: Public sites
    url: "https://example.com/"
    interval: 1m
    timeout: 10s
    conditions:
      - "[STATUS] == 200"
      - "[RESPONSE_TIME] < 3000"
    alerts:
      - type: telegram
        failure-threshold: 3
        success-threshold: 2
        send-on-resolved: true
        description: "The main website is unavailable or too slow."

  - name: API healthcheck
    group: Public sites
    url: "https://api.example.com/health"
    interval: 1m
    timeout: 10s
    headers:
      Accept: "application/json"
    conditions:
      - "[STATUS] == 200"
      - "[BODY].status == UP"
      - "[RESPONSE_TIME] < 2000"
    alerts:
      - type: telegram
        failure-threshold: 2
        success-threshold: 2
        send-on-resolved: true
        description: "API healthcheck did not return status UP."

  - name: SSH server
    group: Infrastructure
    url: "tcp://203.0.113.10:22"
    interval: 2m
    timeout: 5s
    conditions:
      - "[CONNECTED] == true"
    alerts:
      - type: telegram
        failure-threshold: 3
        success-threshold: 1
        send-on-resolved: true
        description: "SSH port is unreachable."

  - name: External HTTPS certificate
    group: SSL certificates
    url: "https://example.com/"
    interval: 12h
    conditions:
      - "[STATUS] == 200"
      - "[CERTIFICATE_EXPIRATION] > 336h"
    alerts:
      - type: telegram
        failure-threshold: 1
        success-threshold: 1
        send-on-resolved: true
        description: "SSL certificate expires in less than 14 days."

Замініть example.com, api.example.com та IP-адресу SSH на реальні значення. Умова [CERTIFICATE_EXPIRATION] > 336h означає, що до завершення сертифіката має залишатися понад 14 діб. Для критичних сертифікатів можна встановити 720 годин, тобто 30 днів.

Не додавайте до URL токени, паролі або приватні query-параметри. Якщо API потребує авторизації, використовуйте окремий технічний токен із мінімальними правами та передавайте його через змінні середовища або закритий шаблон. Для чутливих внутрішніх endpoint краще обмежити доступ до панелі Gatus через Caddy Basic Auth, VPN або firewall.

Створіть конфігурацію Caddy

cd /opt/gatus
nano caddy/Caddyfile

{
    email {$ACME_EMAIL}
}

{$GATUS_DOMAIN} {
    encode zstd gzip

    reverse_proxy gatus:8080

    header {
        -Server
        X-Content-Type-Options "nosniff"
        X-Frame-Options "DENY"
        Referrer-Policy "strict-origin-when-cross-origin"
    }
}

Caddy запитає сертифікат автоматично. Для цього запис A домену має вказувати на VPS, а порти 80 і 443 повинні бути доступні ззовні. Якщо домен використовує проксування через CDN, переконайтеся, що режим TLS не заважає ACME-перевірці.

Створіть Docker Compose-файл

cd /opt/gatus
nano compose.yaml

services:
  gatus:
    image: twinproduction/gatus:latest
    container_name: gatus
    restart: unless-stopped
    env_file:
      - .env
    entrypoint:
      - /bin/sh
      - -ec
      - |
        envsubst < /config/config.yaml.template > /tmp/config.yaml
        exec /gatus --config-file=/tmp/config.yaml
    volumes:
      - ./config:/config:ro
      - ./data:/data
    networks:
      - monitoring
    healthcheck:
      test: ["CMD", "/gatus", "--config-file=/tmp/config.yaml", "--version"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 15s

  caddy:
    image: caddy:2-alpine
    container_name: caddy-gatus
    restart: unless-stopped
    env_file:
      - .env
    depends_on:
      gatus:
        condition: service_started
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./caddy/Caddyfile:/etc/caddy/Caddyfile:ro
      - caddy_data:/data
      - caddy_config:/config
    networks:
      - monitoring

networks:
  monitoring:
    name: monitoring

volumes:
  caddy_data:
  caddy_config:

Використання тегу latest зручне для першого запуску, але для передбачуваних оновлень у production краще закріпити протестовану версію Gatus, наприклад twinproduction/gatus:v5.x.y, після перевірки актуального релізу. Аналогічно можна закріпити мінорну версію Caddy. Після оновлення версії обов'язково перевіряйте зміни формату конфігурації в release notes.

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

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

Перша команда об'єднує Compose-файл і змінні, перевіряючи синтаксис. Потім Docker завантажує образи, запускає стек у фоновому режимі та показує статус контейнерів. Обидва контейнери повинні мати статус Up.

docker compose logs --tail=100 gatus
docker compose logs --tail=100 caddy

У логах Gatus не повинно бути помилок YAML, а в логах Caddy з'явиться повідомлення про успішну видачу сертифіката. Якщо сертифікат не випускається, спочатку перевіряйте DNS, порти UFW і відсутність іншого вебсервера на 80 або 443.

Перевірте роботу панелі та endpoint

curl -I http://127.0.0.1
curl -I https://status.example.com
curl -s https://status.example.com | head

Перший запит може повернути помилку, оскільки Caddy очікує правильний Host-заголовок. Основна перевірка — другий запит: очікуйте статус 200 або редирект із HTTP на HTTPS. Відкрийте домен у браузері та переконайтеся, що в інтерфейсі відображаються групи, endpoint, історія перевірок і поточний статус.

Перевірте Telegram-сповіщення

Найбезпечніший тест — тимчасово вказати свідомо недоступний URL в окремому endpoint. Після двох або трьох інтервалів Gatus має надіслати Telegram-повідомлення. Потім поверніть правильну адресу: після заданого success-threshold надійде сповіщення про відновлення.

docker compose restart gatus
docker compose logs -f gatus

Перша команда застосовує зміни шаблону конфігурації, а друга виводить логи в реальному часі. Після завершення тесту видаліть тимчасовий endpoint, щоб не отримувати хибні алерти.

Важливо: Gatus перевіряє сервіси з IP вашого VPS. Якщо ресурс, що перевіряється, блокує запити з дата-центрів, використовує географічні обмеження або Cloudflare WAF, додайте IP моніторингу до allowlist або налаштуйте окремий дозволений endpoint /health.

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

Gatus можна швидко розгорнути заново, але без резервної копії ви втратите налаштування перевірок, історію інцидентів, SQLite-базу та дані Caddy про сертифікати. Мінімальна стратегія — щодня резервувати каталог /opt/gatus у зовнішнє сховище та періодично перевіряти відновлення на тестовому сервері.

Що потрібно резервувати

• /opt/gatus/config/ — шаблони endpoint і логіка моніторингу.
• /opt/gatus/.env — Telegram-токен, chat ID, домен і email ACME.
• /opt/gatus/data/gatus.db — SQLite-історія перевірок і подій.
• Docker volume caddy_data — сертифікати, ключі та стан Caddy.
• Файл /opt/gatus/compose.yaml і Caddyfile.

Не зберігайте єдину копію резервної копії на тому самому VPS. Підійдуть S3-сумісне сховище, окремий сервер через SFTP або другий VPS по SSH. Якщо в бекапі міститься .env і private key сертифіката, репозиторій має бути зашифрований.

Встановіть restic

sudo apt install -y restic
sudo mkdir -p /root/.config/restic
sudo chmod 700 /root/.config/restic

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

sudo nano /root/.config/restic/gatus.env

export RESTIC_REPOSITORY="s3:https://s3.example.net/gatus-backups"
export RESTIC_PASSWORD="REPLACE_WITH_LONG_RANDOM_PASSWORD"
export AWS_ACCESS_KEY_ID="REPLACE_WITH_ACCESS_KEY"
export AWS_SECRET_ACCESS_KEY="REPLACE_WITH_SECRET_KEY"

sudo chmod 600 /root/.config/restic/gatus.env
sudo bash -c 'source /root/.config/restic/gatus.env && restic init'

Команди захищають файл змінних та ініціалізують порожній зашифрований репозиторій. Пароль RESTIC_PASSWORD зберігайте окремо: без нього відновлення неможливе.

Створіть скрипт резервного копіювання

sudo nano /usr/local/sbin/backup-gatus.sh

#!/usr/bin/env bash
set -euo pipefail

source /root/.config/restic/gatus.env

cd /opt/gatus
docker compose stop gatus
trap 'docker compose start gatus' EXIT

restic backup \
  /opt/gatus/config \
  /opt/gatus/caddy \
  /opt/gatus/compose.yaml \
  /opt/gatus/.env \
  /opt/gatus/data \
  --tag gatus

docker run --rm \
  -v caddy_data:/source:ro \
  -v /opt/gatus/backups:/backup \
  alpine sh -c 'tar czf /backup/caddy_data.tar.gz -C /source .'

restic backup /opt/gatus/backups/caddy_data.tar.gz --tag caddy

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

Скрипт ненадовго зупиняє Gatus, щоб отримати узгоджену SQLite-копію, а потім запускає його знову навіть у разі помилки завдяки trap. Caddy продовжує працювати, тому вебпанель може відображати останню сторінку, але свіжі перевірки зупиняться на кілька секунд.

sudo chmod 700 /usr/local/sbin/backup-gatus.sh
sudo /usr/local/sbin/backup-gatus.sh
sudo bash -c 'source /root/.config/restic/gatus.env && restic snapshots'

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

sudo crontab -e

15 3   * /usr/local/sbin/backup-gatus.sh >> /var/log/backup-gatus.log 2>&1

Завдання запускає резервне копіювання щодня о 03:15 за часом сервера. Раз на місяць перевіряйте відновлення: завантажте snapshot в окремий тимчасовий каталог, переконайтеся в наявності gatus.db і коректності YAML.

Оновлення та контроль стану

Для невеликої інсталяції оновлення краще проводити в maintenance window: у цей час алерти можуть ненадовго не надходити, а зміну версії простіше скасувати. Перед оновленням створіть резервну копію, прочитайте changelog і перевірте, чи не змінився формат конфігурації Gatus.

cd /opt/gatus
sudo /usr/local/sbin/backup-gatus.sh
docker compose pull
docker compose up -d
docker image prune -f
docker compose ps

Gatus не призначений для rolling-оновлень як кластерний сервіс з автоматичним failover. Якщо моніторинг критично важливий, розгорніть другий екземпляр на іншому VPS з окремим Telegram-каналом або з різними префіксами повідомлень. Це надійніше, ніж намагатися оновлювати один екземпляр без короткої перерви.

Щотижня перевіряйте df -h, docker system df, статус контейнерів і розмір /opt/gatus/data/gatus.db. За високої частоти перевірок база зростатиме. Скорочуйте термін зберігання історії засобами актуальної версії Gatus або періодично експортуйте метрики в Prometheus і очищайте старі дані за документованою процедурою версії, яку використовуєте.

Усунення несправностей і FAQ

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

Спочатку перевірте DNS: команда dig +short status.example.com має повернути публічну IP-адресу VPS. Потім переконайтеся, що UFW дозволяє порти 80 і 443, а Docker публікує їх через docker compose ps. Перевірте, чи не зайняті порти іншим Nginx або Apache: sudo ss -ltnp | grep -E ':80|:443'. Якщо використовується CDN, тимчасово вимкніть проксування або налаштуйте коректний режим TLS для ACME challenge.

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

Перевірте, що бот отримав принаймні одне повідомлення від користувача або був доданий до групи. Потім виконайте запит getUpdates і переконайтеся, що TELEGRAM_CHAT_ID збігається з message.chat.id. Для груп ID часто є від’ємним. Перевірте файл .env на зайві лапки, пробіли та неправильний токен, потім перезапустіть Gatus командою docker compose restart gatus і перегляньте логи контейнера.

Чому контейнер Gatus постійно перезапускається?

Найчастіша причина — помилка YAML або непідтримуване поле конфігурації після оновлення образу. Виконайте docker compose logs --tail=200 gatus: рядок помилки зазвичай містить номер рядка YAML. Перевірте відступи, використовуйте пробіли замість tab і переконайтеся, що спеціальні символи в URL взято в лапки. Якщо проблема з’явилася після оновлення, тимчасово поверніть тег образу, який раніше працював, і порівняйте конфігурацію з документацією цієї версії.

Чому endpoint показує помилку, хоча сайт відкривається в браузері?

Браузер і VPS можуть використовувати різні DNS, маршрути IPv4/IPv6, геолокацію та заголовки. Перевірте запит безпосередньо з контейнера: docker exec -it gatus wget -S -O /dev/null https://example.com. Можливі блокування дата-центрів WAF, обов’язковий Host-header, перенаправлення на інший домен, вимога авторизації або надто малий timeout. Налаштуйте allowlist IP моніторингу, збільште timeout до 15–20 секунд і перевіряйте спеціальний endpoint /health.

Чому SSL-алерт надходить надто пізно або не надходить взагалі?

Перевірте інтервал endpoint: за значення 12h Gatus бачить зміну сертифіката лише двічі на добу. Для важливих доменів використовуйте інтервал 1–6 годин. Перевірте умову [CERTIFICATE_EXPIRATION]: 336 годин дорівнюють 14 дням, 720 годин — 30 дням. Також переконайтеся, що endpoint справді використовує HTTPS, а не HTTP. Після зміни умови перезапустіть контейнер і перегляньте статус endpoint у панелі.

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

Для 10–30 сайтів і API endpoint із перевіркою раз на 1–5 хвилин достатньо 1 vCPU, 1 ГБ RAM, 10 ГБ SSD і каналу 100 Мбіт/с. Практичніше обрати 2 ГБ RAM і 20 ГБ NVMe: залишиться запас для Docker, Caddy, оновлень і SQLite-історії. Обов’язково потрібні публічна IPv4-адреса, можливість відкрити 80/443 і стабільна мережа. Якщо плануються сотні endpoint, почніть із 2 vCPU, 4 ГБ RAM і 30–50 ГБ NVMe.

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

Для Gatus майже завжди достатньо VPS. Він дешевший, швидше розгортається і легко масштабується зі зростанням кількості перевірок. Dedicated потрібен, якщо Gatus є частиною великої системи моніторингу з Prometheus, Grafana, логами та тисячами частих перевірок або якщо політика безпеки вимагає фізично виділеного обладнання. Для підвищення надійності краще витратити бюджет не на dedicated, а на другий невеликий VPS в іншій мережі та іншій локації.

Чи можна закрити панель Gatus від публічного доступу?

Так. Найпростіший шлях — залишити публічним лише доступ через VPN, наприклад WireGuard, і закрити 80/443 в UFW для всіх, крім VPN-підмережі. Якщо панель має бути доступна кільком співробітникам, додайте Basic Auth у Caddyfile з хешованим паролем. При цьому не блокуйте ACME-перевірки, якщо Caddy продовжує випускати публічний сертифікат. Альтернативно використовуйте DNS challenge або окремий внутрішній домен із корпоративним TLS.

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

Тепер на окремому VPS працює Gatus із HTTPS-панеллю, перевірками сайтів і API, контролем SSL-сертифікатів та сповіщеннями в Telegram. Конфігурацію відокремлено від секретів, дані зберігаються в SQLite, а бекапи надсилаються до зовнішнього зашифрованого сховища.

1. Додайте endpoint для всіх публічних сайтів, API, DNS-залежностей, SSH і критичних TCP-сервісів.
2. Створіть окремі групи для production, staging і зовнішніх постачальників, щоб Telegram-алерти було простіше класифікувати.
3. Для критичних систем розгорніть другий Gatus в іншій локації та порівнюйте інциденти з незалежних мереж.