Установка 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

Для rolling-обновлений Gatus не предназначен как кластерный сервис с автоматическим failover. Если мониторинг критичен, поднимите второй экземпляр на другом VPS с отдельным Telegram-каналом или с разными префиксами сообщений. Это надёжнее, чем пытаться обновлять один экземпляр без краткого перерыва.

Еженедельно проверяйте df -h, docker system df, статус контейнеров и размер /opt/gatus/data/gatus.db. При высокой частоте проверок база будет расти. Сокращайте срок хранения истории средствами актуальной версии Gatus либо периодически экспортируйте метрики в Prometheus и очищайте старые данные по документированной процедуре версии, которую используете.

Troubleshooting и 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 в другой локации и сравнивайте инциденты из независимых сетей.