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

Большинство инструкций по установке ntfy заканчиваются на первом открытии страницы. Это слишком рано: кэш может быть эфемерным, а подключения WebSocket/SSE — завершаться по тайм-ауту на прокси. Полноценная production-проверка требует большего: опубликовать сообщение с помощью curl, получить его через подписки HTTP и WebSocket, прикрепить файл и проверить один топик с аутентификацией.

Роль ntfy проста: отправка push-уведомлений с помощью обычного HTTP-запроса. Но эксплуатационная граница сервиса включает не только веб-процесс, поэтому до поступления реальных данных нужно явно определить зависимость, сохраняемое состояние и публичный маршрут.

Production-архитектура ntfy

HTTP-процесс ntfy слушает порт 80. Оставьте этот порт во внутренней сети приложения и публикуйте только маршрут платформы. Локальное требование среды выполнения — том конфигурации и, при необходимости, база данных аутентификации. Проверьте эту границу до публикации и ещё раз после замены контейнера.

Зафиксируйте границу в виде короткого соглашения: кто отвечает за требование, какие credentials используются, какой тайм-аут допустим и как проявляется сбой. Затем выполните такую транзакцию: опубликуйте сообщение с помощью curl, получите его через подписки HTTP и WebSocket, прикрепите файл и проверьте один топик с аутентификацией. Во время проверки отслеживайте долгоживущие подключения подписчиков, размер вложений, срок хранения кэша и исходящие push-релеи, поскольку такая нагрузка даёт более полезную отправную точку для расчёта ресурсов, чем простаивающий контейнер.

Запустите ntfy, не скрывая важные детали

Используйте контейнер как заменяемую среду выполнения, а не как место хранения данных, которым можно доверять.

docker run -d \
  --name ntfy \
  --restart unless-stopped \
  -p 127.0.0.1:80:80 \
  -v ntfy-data:/var/cache/ntfy \
  -e NTFY_BASE_URL=https://app.example.com \
  binwiederhier/ntfy:latest serve

До публикации подтвердите локальное требование: том конфигурации и, при необходимости, база данных аутентификации. Перед открытием доступа проверьте пользователя контейнера, доступные для записи пути и привязанный listener. Выполните полный сценарий — опубликуйте сообщение с помощью curl, получите его через подписки HTTP и WebSocket, прикрепите файл и проверьте один топик с аутентификацией — и сохраните точную ссылку на образ, с которым был получен результат.

Назначьте ntfy один канонический адрес

Укажите в base-url публичный HTTPS-адрес, который используют отправители и подписчики. Направьте выбранное имя хоста на порт 80 контейнера, передавайте исходные host и HTTPS scheme и не публикуйте второй прямой origin.

Проверьте ntfy с чистого внешнего клиента. Отделяйте сбой ingress от известной границы приложения — кэш может быть эфемерным, а подключения WebSocket/SSE — завершаться по тайм-ауту на прокси. Ошибки сертификата, DNS или 502 относятся к маршрутизации; запрос, который дошёл до ntfy и завершился ошибкой позже, связан с состоянием приложения, ёмкостью или поддерживающим требованием. Первая группа подробно рассматривается в руководстве по TLS для пользовательского домена.

Убедитесь, что ntfy переживает замену

Защитите состояние ntfy до оптимизации контейнера. В обязательный набор входят конфигурация, база данных аутентификации и вложения, которые должны сохраняться. Подключите /var/cache/ntfy до bootstrap, запишите безвредные тестовые данные и замените контейнер, чтобы убедиться, что этот путь действительно постоянный. Если нужно согласовать несколько хранилищ, задокументируйте порядок приостановки записи и создания резервных копий.

Храните копии за пределами сервера развёртывания и шифруйте материалы, содержащие credentials или приватный контент. Восстановление считается успешным, когда возвращаются пользователи, ACL, конфигурация и сохранённые вложения, а подписчик с аутентификацией получает новое сообщение. Разница между постоянным mount и независимой копией объясняется в материале постоянное хранилище и snapshots.

Не предоставляйте ntfy доступ ко всему хосту

Для ntfy ценной поверхностью атаки не обязательно является главная страница. Основная ошибка — разрешить угадывать публичные топики, если сообщения содержат операционные детали. Противодействуйте этому намеренно: используйте ACL топиков, поскольку неугадываемые имена топиков не являются надёжной авторизацией для операционных сообщений.

NTFY_BASE_URL — это конфигурация, а не секрет. Храните её значение явно, защищая при этом отдельные credentials, используемые ntfy. Используйте непривилегированного пользователя контейнера, если образ это поддерживает, и не монтируйте посторонние credentials. Применяйте ограничения скорости или размера на ingress, где недоверенная нагрузка может занять долгоживущие подключения подписчиков, увеличить размер вложений, срок хранения кэша и нагрузку на исходящие push-релеи.

Обновляйте ntfy без догадок

После каждого развёртывания используйте в качестве smoke test ntfy следующий сценарий: опубликуйте сообщение с помощью curl, получите его через подписки HTTP и WebSocket, прикрепите файл и проверьте один топик с аутентификацией. Важные метрики для поддержки — долгоживущие подключения подписчиков, размер вложений, срок хранения кэша и исходящие push-релеи; настройте оповещения, когда эти ресурсы приближаются к уровню, ухудшающему пользовательское действие.

Основной риск при изменениях связан с тем, что перед обновлением ntfy нужно проверить ключи конфигурации, миграции базы данных аутентификации и ожидания клиентов. Безопасный релиз начинается с восстанавливаемого snapshot и проверки любых необратимых изменений состояния до переключения трафика. Если кэш эфемерен или подключения WebSocket/SSE завершаются по тайм-ауту на прокси, не удаляйте неисправный контейнер, пока не прочитаете его конфигурацию и первую ошибку.

Release gate для ntfy

Кандидат на релиз ntfy получает трафик после выполнения фиксированного сценария: опубликовать сообщение с помощью curl, получить его через подписки HTTP и WebSocket, прикрепить файл и проверить один топик с аутентификацией. Зафиксируйте digest образа, фактическую конфигурацию без секретов, публичный origin и временные отметки этого сценария. Тестовые данные должны быть одноразовыми, но достаточно реалистичными, чтобы задействовать тот же путь, что и пользовательские данные.

Запустите сценарий после замены среды выполнения, а затем пересоберите сервис из конфигурации, базы данных аутентификации и вложений, которые должны сохраняться. Восстановление считается успешным, когда возвращаются пользователи, ACL, конфигурация и сохранённые вложения, а подписчик с аутентификацией получает новое сообщение. Сравните показатели долгоживущих подключений подписчиков, размера вложений, срока хранения кэша и исходящих push-релеев с предыдущим релизом и разберитесь с существенными отклонениями до продвижения версии.

Наконец, выполните контролируемый сбой: отправьте безвредные данные, близкие к ограничению ресурса или формата, связанному с этой границей: кэш эфемерен или подключения WebSocket/SSE завершаются по тайм-ауту на прокси. Убедитесь, что ntfy объясняет причину сбоя, не повреждает существующее состояние и продолжает работу после восстановления корректного условия. Сохраните обезличенный фрагмент лога и время восстановления. Вместе эти проверки охватывают поведение, сохранность данных и эксплуатационные характеристики, а не только доступность процесса.

Сохраняйте настройки ntfy явными, а маршрутизацию оставьте Dockup

Маршрутизация, сертификаты, замена сервисов и подключённое хранилище — подходящие цели для автоматизации. Dockup берёт это на себя для ntfy и может предоставить связанную managed database или подключиться к сервисам на собственном сервере клиента.

Но Dockup не должен самостоятельно придумывать trust policy для ntfy. После развёртывания укажите в base-url публичный HTTPS-адрес, который используют отправители и подписчики, примените это правило — используйте ACL топиков, поскольку неугадываемые имена топиков не являются надёжной авторизацией для операционных сообщений, — и проверьте результат следующего сценария: опубликуйте сообщение с помощью curl, получите его через подписки HTTP и WebSocket, прикрепите файл и проверьте один топик с аутентификацией. В результате вы получаете инфраструктуру в один клик с application-specific acceptance test.

Часто задаваемые вопросы

Что нужно ntfy для production-развёртывания?

Направьте контейнер ntfy на порт 80 через один HTTPS-origin. Локальное требование среды выполнения — том конфигурации и, при необходимости, база данных аутентификации. Не объявляйте ntfy готовым, пока не сможете опубликовать сообщение с помощью curl, получить его через подписки HTTP и WebSocket, прикрепить файл и проверить один топик с аутентификацией.

Какие данные ntfy нужно включать в резервную копию?

Сохраняйте /var/cache/ntfy и включайте в тот же recovery manifest конфигурацию, базу данных аутентификации и вложения, которые должны пережить восстановление. Восстановление ntfy считается успешным только тогда, когда возвращаются пользователи, ACL, конфигурация и сохранённые вложения, а подписчик с аутентификацией получает новое сообщение.

Требуется ли ntfy HTTPS за reverse proxy?

Используйте HTTPS для публичного origin ntfy, а порт 80 оставьте во внутреннем маршруте. Корректно примените настройку ntfy: укажите в base-url публичный HTTPS-адрес, который используют отправители и подписчики. Для ntfy HTTPS защищает credentials или пользовательский контент при передаче и обеспечивает согласованное поведение клиентов, зависящее от origin.

Как тестировать обновление ntfy?

Восстановите текущее состояние ntfy в изолированном развёртывании, примените кандидатную версию и повторите acceptance transaction. Уделите этому особое внимание, поскольку перед обновлением ntfy нужно проверить ключи конфигурации, миграции базы данных аутентификации и ожидания клиентов. Сохраняйте предыдущий образ ntfy, пока не будут понятны границы миграции данных и rollback.