Как перестать зависеть от телеграм-бота для алертов домашнего сервера: ntfy по уровням

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

Альтернатива, требующая примерно нулевых усилий на входе, — ntfy: сервер на Go, который принимает обычный HTTP POST и превращает его в push на телефоне. Никакого SDK, никакого формата вебхука, который надо изучать: curl -d "текст" сервер/топик — и всё. При этом сервер можно поднять свой, и тогда цепочка доставки принадлежит вам целиком. Почти целиком — с iOS есть нюанс, к которому мы дойдём.

Дальше — маршрут по уровням: от «попробовать за тридцать секунд» до сервера с логинами, токенами и правами на топики. Каждый уровень самодостаточен: можно остановиться там, где вам хватит.

Уровень 0. Чужой сервер и один curl

Публичный ntfy.sh не требует ни регистрации, ни ключей. Топик создаётся в момент первой отправки:

curl -d "Бэкап закончился" ntfy.sh/moi-domashnii-server-x7k2

Подписываетесь на тот же топик в приложении или на https://ntfy.sh/moi-domashnii-server-x7k2 в браузере — и сообщение приходит.

Имя топика ограничено 64 символами, допустимы буквы, цифры, - и _. Если остаётесь на публичном сервере — генерируйте его как пароль:

head -c 24 /dev/urandom | base64 | tr -d '/+='

Для чего этого уровня хватает: разовые скрипты, «дай знать, когда доедет rsync», уведомления, содержимое которых не жалко показать посторонним. Для всего остального — дальше.

Уровень 1. Свой ntfy в Docker

Образ binwiederhier/ntfy собирается под amd64, armv6, armv7 и arm64 — то есть спокойно едет на Raspberry Pi и на любом мини-ПК.

services:
  ntfy:
    image: binwiederhier/ntfy
    container_name: ntfy
    command: serve
    environment:
      - TZ=Europe/Moscow
    volumes:
      - ./cache:/var/cache/ntfy
      - ./etc:/etc/ntfy
    ports:
      - 8080:80
    healthcheck:
      test: ["CMD-SHELL", "wget -q --tries=1 http://localhost:80/v1/health -O - | grep -Eo '\"healthy\"\\s*:\\s*true' || exit 1"]
      interval: 60s
      timeout: 10s
      retries: 3
      start_period: 40s
    restart: unless-stopped

Минимальный etc/server.yml:

base-url: "https://ntfy.example.org"
cache-file: /var/cache/ntfy/cache.db
auth-file: /var/cache/ntfy/auth.db
attachment-cache-dir: /var/cache/ntfy/attachments

cache-file — это SQLite, в котором лежат сообщения. Без него сервер работает целиком в памяти: перезапустили контейнер — история пропала, а подписчик, который был офлайн, ничего не получит. Практически всегда его надо задать.

Уровень 2. За обратным прокси

Здесь живёт грабля, на которую наступают почти все.

behind-proxy: true
proxy-forwarded-header: "X-Forwarded-For"   # значение по умолчанию

Второе, что обязательно на этом уровне, — корректный base-url. Он используется в ссылках на вложения и в письмах; если он не совпадает с реальным внешним адресом, вложения будут приходить со ссылками в никуда.

Третье — сам прокси. ntfy держит длинные соединения для подписчиков, поэтому буферизация ответа и короткий таймаут прокси ломают доставку. В nginx это proxy_buffering off; и увеличенный proxy_read_timeout, в Caddy обычно достаточно обычного reverse_proxy без дополнительных настроек.

Уровень 3. Кто кому что может

По умолчанию сервер открыт: любой, кто знает адрес, публикует и читает. Закрывается это одной строкой:

auth-file: /var/cache/ntfy/auth.db
auth-default-access: "deny-all"

Значения auth-default-access:

Дальше — CLI. Команды выполняются внутри контейнера (docker compose exec ntfy ntfy ...):

# администратор — имеет доступ ко всему
ntfy user add --role=admin admin

# обычный пользователь: по умолчанию не имеет прав ни на что
ntfy user add homeassistant

# выдаём права точечно
ntfy access homeassistant "alerts-*"  write-only
ntfy access phone         "alerts-*"  read-only

# токен вместо пароля для скриптов
ntfy token add --expires=90d homeassistant

Шаблон alerts-* работает — права выдаются на группу топиков, а не только на один.

Отправка с токеном:

curl -H "Authorization: Bearer tk_xxxxxxxxxxxx" \
     -d "Диск /dev/sda заполнен на 91%" \
     https://ntfy.example.org/alerts-infra

Уровень 4. Телефон, и почему iOS требует чужого сервера

Это самая недооценённая часть. Одно и то же приложение доставляет уведомления тремя разными способами, и от способа зависит и задержка, и приватность, и расход батареи.

Android, сборка из Google Play. Firebase используется только для топиков на самом ntfy.sh. Для ваших собственных серверов приложение Firebase не задействует вообще — оно держит прямое соединение. Это прямая цитата из документации, и она снимает главное опасение: свой сервер не «ходит через Google».

Android, сборка из F-Droid. Firebase нет в принципе, все подписки по умолчанию идут в режиме мгновенной доставки.

Мгновенная доставка — это постоянное соединение, а значит foreground-сервис и вечное уведомление в шторке. Без него, предупреждает документация, сообщения могут приходить с задержкой в минуты и даже часы. Выбор здесь честный и явный: либо иконка в статус-баре, либо непредсказуемая задержка.

upstream-base-url: "https://ntfy.sh"

Если вас и это не устраивает — остаётся вариант «зайти в веб-интерфейс и подписаться там» через Web Push, для которого нужны ключи VAPID:

web-push-public-key: "..."
web-push-private-key: "..."
web-push-file: /var/cache/ntfy/webpush.db
web-push-email-address: "admin@example.org"

Ключи генерируются командой ntfy webpush keys. Заметьте, что Web Push в браузере тоже ходит через сервисы Google/Mozilla/Apple — полностью изолированного пути на смартфон сегодня просто не существует.

Что можно положить в уведомление

Это то, ради чего ntfy стоит предпочесть самописному вебхуку: сообщение — не просто строка.

Приоритеты влияют на поведение телефона:

Самое интересное — кнопки. Их три типа: view (открыть ссылку), http (сделать HTTP-запрос) и broadcast (отправить Android-интент в Tasker и подобное). Классический сценарий домашнего сервера:

curl -H "Title: Дверь гаража открыта 40 минут" \
     -H "Priority: high" \
     -H "Tags: warning,house" \
     -H 'Actions: http, Закрыть, https://ha.local/api/webhook/garage_close, method=POST' \
     -H "Authorization: Bearer tk_xxxxxxxxxxxx" \
     -d "Закрыть прямо отсюда?" \
     https://ntfy.example.org/alerts-home

Одно уведомление — и действие выполняется с экрана блокировки, без открытия Home Assistant.

Куда это подключается на практике

• systemd. В юнит добавляется OnFailure=, который дёргает одноразовый сервис с curl. Падение любого сервиса — сразу в телефон.
• cron и бэкап-скрипты. curl -d "..." -H "Priority: 5" в ветке ошибки — и вы наконец узнаёте о неудавшемся бэкапе не через месяц.
• Uptime Kuma и Healthchecks. ntfy у обоих в списке нотификаторов из коробки.
• Home Assistant. Через rest_command или интеграцию ntfy; сюда же — кнопки действий с примера выше.
• Grafana, Alertmanager. Обычный webhook-приёмник, форматирование настраивается шаблоном.

Лимиты, которые стоит знать заранее

Даже на своём сервере лимиты включены — они защищают от того, чтобы один взбесившийся скрипт не забил диск.

Три часа хранения вложений — это про то, что ntfy не файлопомойка. Скриншот с камеры дойдёт, архив логов — нет, и не должен.

Чего ntfy не делает

Честности ради: это не мессенджер и не система оповещений с дежурными сменами.

Здесь нет шифрования сообщений между отправителем и получателем — трафик защищён TLS, но на сервере сообщение лежит открытым текстом в SQLite. Нет эскалаций «не подтвердил за 5 минут — звони следующему», нет расписаний дежурств, нет группировки и подавления шквала одинаковых алертов. Если вам нужно это — смотрите в сторону Alertmanager перед ntfy, а ntfy оставьте как транспорт последней мили.

И ещё: своим сервером вы берёте на себя его доступность. Уведомление о том, что сервер лёг, не придёт с сервера, который лёг. Классическое решение — держать ntfy не на той же машине, за которой он следит, а внешний watchdog вроде Healthchecks.io — на стороне.

Источники

• docs.ntfy.sh — Installation — установка, Docker Compose, поддерживаемые платформы
• docs.ntfy.sh — Configuration — все параметры, ACL, лимиты, Web Push, upstream
• docs.ntfy.sh — Publishing — заголовки, приоритеты, кнопки, вложения
• docs.ntfy.sh — Subscribe from phone — поведение Android-сборок и мгновенная доставка
• github.com/binwiederhier/ntfy — Releases — версии и changelog