Як розгорнути ntfy на власному сервері у 2026 році: топіки, контроль доступу та доставка
Практичний посібник із розгортання ntfy на власному сервері: Docker, порти, постійні дані, TLS, безпека, резервні копії та проблеми, які заважають використовувати сервіс у production. Покроково.
Більшість інструкцій зі встановлення ntfy завершується на першому відкритті сторінки. Це надто рано: кеш може бути ефемерним, а підключення WebSocket/SSE — завершуватися за тайм-аутом на проксі. Корисніший production-тест вимагає більшого — опублікувати повідомлення через curl, отримати його через підписки HTTP і WebSocket, додати файл і перевірити один автентифікований топік.
Роль ntfy проста: надсилати push-сповіщення за допомогою простого HTTP-запиту. Його операційна межа охоплює більше, ніж вебпроцес, тому до надходження реальних даних потрібно явно визначити залежність, збережений стан і публічний маршрут.
Production-архітектура ntfy
HTTP-процес ntfy слухає порт 80; залиште цей порт у мережі застосунку й опублікуйте лише маршрут платформи. Локальна вимога середовища виконання — том конфігурації та опційна база даних автентифікації. Перевірте цю межу до публікації, а потім ще раз після заміни контейнера.
Зафіксуйте межу як короткий контракт: хто відповідає за вимогу, які облікові дані використовуються, який тайм-аут є прийнятним і як проявляється збій. Потім виконайте таку транзакцію: опублікуйте повідомлення через 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
Перед відкриттям доступу підтвердьте локальну вимогу: том конфігурації та опційну базу даних автентифікації. Перевірте користувача контейнера, доступні для запису шляхи та прив’язаний слухач, перш ніж відкривати доступ. Виконайте повний сценарій — опублікуйте повідомлення через curl, отримайте його через підписки HTTP і WebSocket, додайте файл і перевірте один автентифікований топік — та збережіть точне посилання на образ, який дав цей результат.
Надайте ntfy одну канонічну адресу
Налаштуйте base-url на публічне джерело HTTPS, яке використовують видавці та підписники. Спрямовуйте вибране ім’я хоста на порт контейнера 80, передавайте оригінальні host і схему HTTPS та не публікуйте друге пряме джерело.
Перевірте ntfy з чистого зовнішнього клієнта. Відокремте збій ingress від відомої межі застосунку — кеш може бути ефемерним, а підключення WebSocket/SSE — завершуватися за тайм-аутом на проксі. Помилка сертифіката, DNS або 502 належить до маршрутизації; запит, який доходить до ntfy, але пізніше завершується помилкою, вказує на стан застосунку, місткість або його допоміжну вимогу. Першу групу розглянуто в посібнику з TLS для власного домену.
Переконайтеся, що ntfy переживає заміну
Захистіть стан ntfy до оптимізації його контейнера. Обов’язковий набір — конфігурація, база даних автентифікації та вкладення, які мають зберігатися. Підключіть /var/cache/ntfy до початкового налаштування, запишіть нешкідливі тестові дані та замініть контейнер, щоб довести, що цей шлях справді є постійним. Якщо кілька сховищ мають залишатися узгодженими, задокументуйте порядок призупинення записів і створення резервних копій.
Зберігайте копії за межами сервера розгортання та шифруйте матеріали, що містять облікові дані або приватний вміст. Відновлення є успішним, коли повертаються користувачі, ACL, конфігурація та збережені вкладення, а автентифікований підписник отримує нове повідомлення. Різницю між постійним монтуванням і незалежною копією описано в матеріалі постійне сховище та знімки.
Не надавайте ntfy доступ до всього хоста
Для ntfy цінною поверхнею не обов’язково є landing page. Основна помилка — дозволити публічний підбір топіків, коли повідомлення містять операційні деталі. Протидійте цьому свідомо: використовуйте ACL для топіків, оскільки непередбачувані назви топіків не є надійною авторизацією для операційних повідомлень.
NTFY_BASE_URL — це конфігурація, а не секрет; зберігайте його значення явним, захищаючи окремі облікові дані, які використовує ntfy. Використовуйте непривілейованого користувача контейнера, якщо образ це підтримує, і не монтуйте сторонні облікові дані. Застосовуйте обмеження швидкості або розміру на ingress-рівні, де недовірені запити можуть споживати довготривалі підключення підписників, розмір вкладень, зберігання кешу та вихідні push-релеї.
Оновлюйте ntfy без припущень
Використовуйте сценарій «опублікувати повідомлення через curl, отримати його через підписки HTTP і WebSocket, додати файл і перевірити один автентифікований топік» як smoke-тест ntfy після кожного розгортання. Супровідні метрики — довготривалі підключення підписників, розмір вкладень, зберігання кешу та вихідні push-релеї; налаштуйте сповіщення там, де ці ресурси наближаються до рівня, що погіршує користувацьку дію.
Основний ризик змін полягає в тому, що перед оновленням ntfy потрібно перевірити ключі конфігурації, міграції бази даних автентифікації та очікування клієнтів. Безпечний реліз починається з відновлюваного знімка й перевірки будь-якої односторонньої зміни стану до перемикання трафіку. Якщо кеш є ефемерним або підключення WebSocket/SSE завершуються за тайм-аутом на проксі, не видаляйте несправний контейнер, доки не прочитаєте його конфігурацію та першу помилку.
Критерій випуску ntfy
Кандидат на випуск ntfy отримує трафік після виконання фіксованого сценарію: опублікувати повідомлення через curl, отримати його через підписки HTTP і WebSocket, додати файл і перевірити один автентифікований топік. Зафіксуйте digest образу, ефективну конфігурацію без секретів, публічне джерело та часові мітки цього сценарію. Тестові дані мають бути одноразовими, але достатньо реалістичними, щоб перевірити той самий шлях, яким користуються користувачі.
Виконайте цей сценарій після заміни середовища виконання, а потім відновіть сервіс із конфігурації, бази даних автентифікації та вкладень, які мають зберігатися. Відновлення пройдено, коли повертаються користувачі, ACL, конфігурація та збережені вкладення, а автентифікований підписник отримує нове повідомлення. Порівняйте вимірювання ресурсів для довготривалих підключень підписників, розміру вкладень, зберігання кешу та вихідних push-релеїв із попереднім релізом і дослідіть суттєві відхилення до запуску.
Нарешті, виконайте контрольований збій: надішліть нешкідливі дані, близькі до обмеження ресурсу або формату, пов’язаного з цією межею: кеш може бути ефемерним або підключення WebSocket/SSE можуть завершуватися за тайм-аутом на проксі. Перевірте, що ntfy пояснює збій, не пошкоджує наявний стан і відновлює роботу після повернення коректної умови. Збережіть редагований фрагмент журналу та час відновлення. Разом ці перевірки охоплюють поведінку, надійність даних і придатність до експлуатації, а не лише доступність процесу.
Зберігайте налаштування ntfy явними, а маршрутизацію доручіть Dockup
Маршрутизація, сертифікати, заміна сервісу та підключене сховище — цілком доречні цілі для автоматизації. Dockup виконує ці завдання для ntfy та може підготувати пов’язану керовану базу даних або підключитися до сервісів на власному сервері клієнта.
Водночас Dockup не має вигадувати політику довіри ntfy. Після розгортання налаштуйте base-url на публічне джерело HTTPS, яке використовують видавці та підписники, застосуйте цю межу — використовуйте ACL для топіків, оскільки непередбачувані назви топіків не є надійною авторизацією для операційних повідомлень — і перевірте результат такого сценарію: опублікуйте повідомлення через curl, отримайте його через підписки HTTP і WebSocket, додайте файл і перевірте один автентифікований топік. У підсумку ви отримуєте інфраструктуру в один клік із прикладним acceptance-тестом.
Поширені запитання
Що потрібно ntfy для production-розгортання?
Прокиньте контейнер ntfy через порт 80 на одне джерело HTTPS. Локальна вимога середовища виконання — том конфігурації та опційна база даних автентифікації. Не вважайте ntfy готовим, доки не зможете опублікувати повідомлення через curl, отримати його через підписки HTTP і WebSocket, додати файл і перевірити один автентифікований топік.
Які дані ntfy потрібно включати до резервної копії?
Забезпечте збереження /var/cache/ntfy та включіть конфігурацію, базу даних автентифікації й вкладення, які мають зберігатися, до одного маніфесту відновлення. Чисте відновлення ntfy вважається успішним лише тоді, коли повертаються користувачі, ACL, конфігурація та збережені вкладення, а автентифікований підписник отримує нове повідомлення.
Чи потрібен ntfy HTTPS за reverse proxy?
Використовуйте HTTPS для публічного джерела ntfy та залиште порт 80 у внутрішньому маршруті. Правильно застосуйте налаштування ntfy: встановіть base-url на публічне джерело HTTPS, яке використовують видавці та підписники. Для ntfy HTTPS захищає облікові дані або вміст користувачів під час передавання та забезпечує узгоджену поведінку клієнтів, чутливу до джерела.
Як тестувати оновлення ntfy?
Відновіть поточний стан ntfy в ізольованому розгортанні, застосуйте кандидатну версію та повторіть транзакцію приймання. Особливу увагу приділіть тому, що перед оновленням ntfy потрібно перевірити ключі конфігурації, міграції бази даних автентифікації та очікування клієнтів. Зберігайте попередній образ ntfy, доки не буде зрозумілою межа міграції даних і відкату.