Развёртывание Uptime Kuma за Caddy через Docker Compose

В этом материале разберём, как развернуть Uptime Kuma за Caddy с поддержкой HTTPS и собственным доменом вида:

https://status.your.site

Стек будет развёрнут через Docker Compose, что даёт:

быструю установку и переносимость;
изоляцию сервисов (Caddy + Uptime Kuma в отдельных контейнерах);
централизованный старт/стоп/обновление.

Uptime Kuma будет отвечать за мониторинг сервисов и формирование статус-страниц, а Caddy — за приём HTTPS‑трафика, автоматическое получение и продление сертификатов Let’s Encrypt, а также за обратное проксирование запросов к Uptime Kuma.

Архитектура решения

Логика работы стека:

Клиент открывает https://status.your.site.
DNS-запись A/AAAA указывает на IP вашего сервера.
Caddy принимает запрос на 80/443 порту, обрабатывает HTTPS (TLS, сертификаты Let’s Encrypt).
Caddy проксирует запросы к контейнеру uptime-kuma, который работает на внутреннем порту 3001 в общей Docker-сети.
Uptime Kuma отдаёт веб-интерфейс, Caddy — наружу.

Все сервисы живут в общей внутренней сети status_net, недоступной снаружи.

Предварительные требования

Для развёртывания необходимы:

Сервер с публичным IPv4/IPv6 (VPS/дедик), на котором можно открыть порты 80 и 443.
Установленные:
- docker
- docker compose (новый плагин docker compose или классический docker-compose).
Домен your.site (или другой) и возможность редактировать DNS-записи.

DNS-настройки

Создайте (или проверьте наличие) записи для поддомена:

status.your.site → A/AAAA на IP сервера, где будет запущен стек.

Если используете Cloudflare или аналогичный прокси:

на этапе первоначального получения сертификата лучше использовать режим DNS only (серый облачок), либо корректно настроенный прокси с поддержкой Let’s Encrypt.

Подготовка структуры каталогов

Создадим отдельный каталог под стек статуса, например:

mkdir -p /opt/status-stack
cd /opt/status-stack

mkdir -p uptime-kuma caddy_data caddy_config

Здесь:

uptime-kuma/ — данные Uptime Kuma (БД, конфигурация и т.п.).
caddy_data/ — данные Caddy (сертификаты Let’s Encrypt и пр.).
caddy_config/ — внутренние конфиги Caddy (помимо Caddyfile).

Docker Compose: Caddy + Uptime Kuma

Создадим файл docker-compose.yml в каталоге /opt/status-stack:

services:
  uptime-kuma:
    image: louislam/uptime-kuma:latest
    restart: unless-stopped
    volumes:
      - ./uptime-kuma:/app/data
    networks:
      - status_net

  caddy:
    image: caddy:2.8-alpine
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    environment:
      # Не обязательно, но демонстрирует согласие с условиями ACME
      - ACME_AGREE=true
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile:ro
      - ./caddy_data:/data
      - ./caddy_config:/config
    networks:
      - status_net

networks:
  status_net:
    driver: bridge

Краткое пояснение:

uptime-kuma
- image: louislam/uptime-kuma:latest — официальный образ.
- ./uptime-kuma:/app/data — постоянные данные хранятся на хосте.
- restart: unless-stopped — контейнер перезапускается при сбоях.
caddy
- image: caddy:2.8-alpine — облегчённый образ Caddy.
- Порты 80 и 443 проброшены наружу.
- Caddyfile монтируется только для чтения.
- caddy_data и caddy_config хранят состояние и сертификаты.
status_net — отдельная виртуальная сеть, в которой сервисы видят друг друга по имени контейнера (например, uptime-kuma:3001).

Caddyfile для status.`your`.site

В том же каталоге /opt/status-stack создайте файл Caddyfile:

{
    # Укажите e-mail администратора для Let’s Encrypt
    email admin@your.site
    # Необязательно, но полезно для отладки
    # acme_ca https://acme-v02.api.letsencrypt.org/directory
}

status.your.site {
    encode gzip

    # Простейший reverse proxy до Uptime Kuma
    reverse_proxy uptime-kuma:3001

    # Базовые заголовки безопасности
    header {
        Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
        X-Content-Type-Options "nosniff"
        X-Frame-Options "DENY"
        Referrer-Policy "no-referrer-when-downgrade"
    }
}

Что здесь происходит:

В глобальном блоке { ... } задаётся e-mail, который будет использован Let’s Encrypt для уведомлений о сертификатах.
Для хоста status.your.site Caddy:
- автоматически получает/обновляет TLS-сертификат;
- сжимает ответы gzip;
- проксирует все запросы на контейнер uptime-kuma на порт 3001 внутри одной сети;
- добавляет базовые заголовки безопасности.

Важно: имя хоста в Caddyfile (status.your.site) должно точно совпадать с DNS-записью.

Запуск стека

Находясь в каталоге /opt/status-stack, выполните:

docker compose pull
docker compose up -d

Проверка статуса контейнеров:

docker compose ps

Оба сервиса (caddy и uptime-kuma) должны быть в статусе Up.

Если Caddy не может получить сертификат (например, DNS ещё не обновился или порт 80/443 закрыт), посмотрите логи:

docker compose logs caddy

Исправьте причину (DNS, фаервол, порт) и перезапустите:

docker compose restart caddy

Первичная настройка Uptime Kuma

После успешного запуска откройте в браузере:

https://status.your.site

При первом заходе Uptime Kuma предложит:

Создать административный аккаунт (логин/пароль).
Войти в панель.

Рекомендуется сразу включить 2FA (двухфакторную аутентификацию) в настройках профиля Uptime Kuma для дополнительной безопасности.

Далее вы можете добавлять мониторы:

HTTP/HTTPS (сайты, панели, API);
Ping (серверы, ноды);
TCP-порты (VPN, базы данных, SSH и т.п.);
DNS, SSL, Push-мониторы и многое другое.

Настройка публичной статус-страницы

Uptime Kuma позволяет создавать одну или несколько публичных статус-страниц.

Общий алгоритм:

В интерфейсе Uptime Kuma перейдите в раздел Status Pages.
Создайте новую страницу (например, YourSite Status).
Добавьте в неё нужные мониторы (или группы мониторов), сгруппировав их по категориям:
- Billing / ЛК;
- Панели администрирования (Hestia/cPanel/ISP);
- Cloud VPS / Dedicated;
- VPN-ноды и т.д.
Выберите режим доступа:
- публичная;
- по ссылке;
- (опционально) с авторизацией.

Если вы хотите использовать тот же домен, что и для входа в админку Kuma, достаточно настроить статус-страницу так, чтобы она открывалась при визите на status.your.site (по умолчанию одна из страниц может быть «главной»).

При необходимости можно:

сделать одну страницу публичной под клиентов;
другую — закрытой под внутренний мониторинг.

Обновление и резервное копирование

Обновление контейнеров

Обновление стека сводится к:

cd /opt/status-stack

docker compose pull
docker compose up -d

Uptime Kuma и Caddy подтянут новые версии образов, конфигурация и данные сохранятся, так как вынесены в тома/каталоги.

Резервное копирование

Для бэкапа достаточно периодически сохранять содержимое каталогов:

/opt/status-stack/uptime-kuma
/opt/status-stack/caddy_data
(опционально) /opt/status-stack/caddy_config

Рекомендуется настроить регулярный бэкап этих директорий в отдельное хранилище (другой сервер, S3-совместимое хранилище и т.п.).

Безопасность и best practices

Несколько практических рекомендаций:

Ограничьте доступ к серверу:
- закройте все лишние порты в фаерволе (оставьте 22/SSH, 80, 443 при необходимости);
- используйте SSH-ключи вместо паролей.
Защитите админку Uptime Kuma:
- сложный пароль + 2FA;
- не создавайте лишних пользователей без необходимости.
Следите за обновлениями:
- периодически обновляйте образы Caddy и Uptime Kuma через docker compose pull;
- обновляйте сам Docker и систему.
Контролируйте нагрузку:
- не ставьте слишком частый интервал проверки на сотни мониторов на слабом VPS;
- мониторьте ресурсы (CPU/RAM/IO) на хост-системе.
Используйте отдельный сервер/ВМ под мониторинг, если Uptime Kuma становится критически важным компонентом инфраструктуры.

Заключение

В результате вы получаете:

современную систему мониторинга Uptime Kuma, развёрнутую в контейнере;
фронт на Caddy с автоматическим HTTPS и собственным доменом status.your.site;
централизованный стек, который:
- легко переносится на другой сервер;
- относительно просто обновляется;
- даёт удобный интерфейс для вас и понятную статус-страницу для клиентов.

Дальше можно развивать решение:

интегрировать уведомления в Telegram/Slack/почту;
автоматически добавлять мониторы по Docker-лейблам или через Ansible/скрипты;
разделить отдельные статус-страницы по продуктам (Cloud, Shared, VPN и т.д.).

Эта базовая конфигурация даёт «скелет» для профессионального мониторинга и статус-панели, который можно последовательно наращивать под конкретные задачи вашей инфраструктуры.