Jak hostować ntfy samodzielnie w 2026 roku: topics, kontrola dostępu i dostarczanie

Większość instrukcji instalacji ntfy kończy się na pierwszym załadowaniu strony. To zdecydowanie za wcześnie: cache jest efemeryczny albo połączenia WebSocket/SSE wygasają na proxy. Przydatny test produkcyjny jest bardziej wymagający — opublikuj wiadomość za pomocą curl, odbierz ją przez subskrypcje HTTP i WebSocket, dołącz plik i przetestuj jeden uwierzytelniony topic.

Rola ntfy jest prosta: wysyłanie push notifications za pomocą prostego żądania HTTP. Jego granice operacyjne obejmują więcej niż sam proces webowy, dlatego zależność, przechowywany stan i publiczny route trzeba jednoznacznie określić, zanim pojawią się prawdziwe dane.

Produkcyjny kształt ntfy

Proces HTTP ntfy nasłuchuje na porcie 80; pozostaw ten port w sieci aplikacji i publikuj wyłącznie route platformy. Lokalne wymaganie środowiska uruchomieniowego obejmuje wolumen konfiguracji i opcjonalną bazę auth. Przetestuj tę granicę przed publikacją i ponownie po wymianie kontenera.

Zapisz granicę w formie krótkiego kontraktu: kto odpowiada za wymaganie, które credentials są używane, jaki timeout jest akceptowalny i jak wygląda awaria. Następnie wykonaj tę transakcję: opublikuj wiadomość za pomocą curl, odbierz ją przez subskrypcje HTTP i WebSocket, dołącz plik i przetestuj jeden uwierzytelniony topic. Podczas testu obserwuj długotrwałe połączenia subskrybentów, rozmiar załączników, retencję cache i wychodzące relays push, ponieważ taki workload daje lepszy punkt wyjścia do określenia rozmiaru niż bezczynny kontener.

Uruchom ntfy bez ukrywania istotnych elementów

Traktuj kontener jako wymienialne środowisko uruchomieniowe, a nie jako źródło prawdy.

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

Potwierdź lokalne wymaganie przed udostępnieniem usługi: wolumen konfiguracji i opcjonalną bazę auth. Sprawdź użytkownika kontenera, ścieżki z prawem zapisu i zbindowany listener przed jej udostępnieniem. Wykonaj pełną operację — opublikuj wiadomość za pomocą curl, odbierz ją przez subskrypcje HTTP i WebSocket, dołącz plik i przetestuj jeden uwierzytelniony topic — oraz zapisz dokładne odwołanie do obrazu, które dało ten wynik.

Nadaj ntfy jeden kanoniczny adres

Ustaw base-url na publiczny origin HTTPS używany przez publisherów i subskrybentów. Skieruj wybraną nazwę hosta do portu 80 kontenera, przekazuj oryginalny host i schemat HTTPS oraz unikaj publikowania drugiego, bezpośredniego originu.

Przetestuj ntfy z użyciem czystego, zewnętrznego klienta. Oddziel awarię ingressu od znanej granicy aplikacji — cache jest efemeryczny albo połączenia WebSocket/SSE wygasają na proxy. Błąd certyfikatu, DNS lub 502 należy do routingu; żądanie, które dociera do ntfy i kończy się błędem później, dotyczy stanu aplikacji, capacity albo jej wymagania wspierającego. Przewodnik po TLS dla własnej domeny obejmuje pierwszą grupę problemów.

Sprawdź, czy ntfy przetrwa wymianę

Zabezpiecz stan ntfy, zanim zaczniesz optymalizować kontener. Wymagany zestaw obejmuje konfigurację, bazę auth i załączniki, które muszą przetrwać. Zamontuj /var/cache/ntfy przed bootstrapem, zapisz nieszkodliwe dane przykładowe i wymień kontener, aby potwierdzić, że ta ścieżka rzeczywiście jest trwała. Jeśli wiele magazynów musi zachować spójność, udokumentuj kolejność wstrzymywania zapisów i wykonywania backupów.

Przechowuj kopie poza serwerem wdrożeniowym i szyfruj materiały zawierające credentials lub prywatne treści. Odzyskiwanie kończy się powodzeniem, gdy wracają użytkownicy, ACL-e, konfiguracja i zachowane załączniki, a uwierzytelniony subskrybent otrzymuje nową wiadomość. Różnicę między trwałym mountem a niezależną kopią opisano w trwałym storage i snapshotach.

Nie dawaj ntfy dostępu do całego hosta

W przypadku ntfy wartościową powierzchnią niekoniecznie jest landing page. Głównym błędem jest zezwolenie na publiczne zgadywanie topiców, gdy wiadomości zawierają szczegóły operacyjne. Przeciwdziałaj temu celowo: używaj ACL-i topiców, ponieważ nieprzewidywalne nazwy topiców nie są silnym mechanizmem autoryzacji w przypadku wiadomości operacyjnych.

NTFY_BASE_URL jest konfiguracją, a nie sekretem; zachowaj jego wartość w jawnej postaci, chroniąc osobno credentials używane przez ntfy. Używaj nieuprzywilejowanego użytkownika kontenera, jeśli obraz to obsługuje, i nie montuj niezwiązanych credentials. Stosuj limity rate lub rozmiaru na ingressie, gdzie niezaufany workload może zużywać długotrwałe połączenia subskrybentów, rozmiar załączników, retencję cache i wychodzące relays push.

Aktualizuj ntfy bez zgadywania

Po każdym wdrożeniu użyj sekwencji „opublikuj wiadomość za pomocą curl, odbierz ją przez subskrypcje HTTP i WebSocket, dołącz plik i przetestuj jeden uwierzytelniony topic” jako smoke test ntfy. Powiązane metryki obejmują długotrwałe połączenia subskrybentów, rozmiar załączników, retencję cache i wychodzące relays push; ustaw alerty w miejscach, w których te zasoby zbliżają się do poziomu pogarszającego działanie użytkownika.

Główne ryzyko zmiany polega na tym, że przed aktualizacją ntfy należy sprawdzić klucze konfiguracji, migracje bazy auth i oczekiwania klientów. Bezpieczne wydanie rozpoczyna się od snapshotu, który można odtworzyć, oraz waliduje każdą jednostronną zmianę stanu przed przełączeniem ruchu. Gdy cache jest efemeryczny albo połączenia WebSocket/SSE wygasają na proxy, zachowaj uszkodzony kontener wystarczająco długo, aby odczytać jego konfigurację i pierwszy błąd.

Bramka wydania ntfy

Kandydat do wydania ntfy zasługuje na obsługę ruchu po pomyślnym przejściu ustalonego scenariusza: opublikuj wiadomość za pomocą curl, odbierz ją przez subskrypcje HTTP i WebSocket, dołącz plik i przetestuj jeden uwierzytelniony topic. Zapisz digest obrazu, efektywną konfigurację niezawierającą sekretów, publiczny origin i timestampy tego scenariusza. Dane testowe powinny być jednorazowe, ale na tyle realistyczne, aby przećwiczyć tę samą ścieżkę, z której korzystają użytkownicy.

Uruchom ten test po wymianie środowiska uruchomieniowego, a następnie odbuduj usługę na podstawie konfiguracji, bazy auth i załączników, które muszą przetrwać. Recovery kończy się powodzeniem, gdy wracają użytkownicy, ACL-e, konfiguracja i zachowane załączniki, a uwierzytelniony subskrybent otrzymuje nową wiadomość. Porównaj pomiary zasobów dla długotrwałych połączeń subskrybentów, rozmiaru załączników, retencji cache i wychodzących relays push z poprzednim wydaniem, a przed promocją zbadaj istotne odchylenia.

Na koniec przećwicz kontrolowaną awarię: prześlij nieszkodliwe dane blisko limitu zasobu lub formatu związanego z tą granicą: cache jest efemeryczny albo połączenia WebSocket/SSE wygasają na proxy. Sprawdź, czy ntfy wyjaśnia awarię, nie uszkadza istniejącego stanu i wznawia działanie po przywróceniu prawidłowych warunków. Zapisz zredagowany fragment logu i czas odzyskiwania. Łącznie te kontrole obejmują zachowanie, trwałość i operacyjność, a nie tylko działanie procesu.

Zachowaj jawność ntfy, a routing powierz Dockup

Routing, certyfikaty, wymiana usług i dołączony storage to uzasadnione cele automatyzacji. Dockup obsługuje je dla ntfy i może aprowizować powiązaną zarządzaną bazę danych lub łączyć się z usługami na własnym serwerze klienta.

Nie powinien jednak wymyślać polityki zaufania ntfy. Po wdrożeniu ustaw base-url na publiczny origin HTTPS używany przez publisherów i subskrybentów, wymuś tę granicę — używaj ACL-i topiców, ponieważ nieprzewidywalne nazwy topiców nie są silnym mechanizmem autoryzacji w przypadku wiadomości operacyjnych — i zweryfikuj wynik tego scenariusza: opublikuj wiadomość za pomocą curl, odbierz ją przez subskrypcje HTTP i WebSocket, dołącz plik i przetestuj jeden uwierzytelniony topic. Rezultatem jest infrastruktura wdrażana jednym kliknięciem wraz z testem akceptacyjnym specyficznym dla aplikacji.

Najczęściej zadawane pytania

Czego ntfy potrzebuje do wdrożenia produkcyjnego?

Skieruj kontener ntfy działający na porcie 80 przez jeden origin HTTPS. Lokalne wymaganie środowiska uruchomieniowego obejmuje wolumen konfiguracji i opcjonalną bazę auth. Nie uznawaj ntfy za gotowe, dopóki nie możesz opublikować wiadomości za pomocą curl, odebrać jej przez subskrypcje HTTP i WebSocket, dołączyć pliku i przetestować jednego uwierzytelnionego topicu.

Które dane ntfy powinny znaleźć się w backupie?

Utrwal /var/cache/ntfy i uwzględnij w tym samym recovery manifeście konfigurację, bazę auth oraz załączniki, które muszą przetrwać. Czyste odtworzenie ntfy kończy się powodzeniem tylko wtedy, gdy wracają użytkownicy, ACL-e, konfiguracja i zachowane załączniki, a uwierzytelniony subskrybent otrzymuje nową wiadomość.

Czy ntfy wymaga HTTPS za reverse proxy?

Używaj HTTPS dla publicznego originu ntfy i pozostaw port 80 na wewnętrznym route. Zastosuj ustawienie ntfy prawidłowo: ustaw base-url na publiczny origin HTTPS używany przez publisherów i subskrybentów. W przypadku ntfy HTTPS chroni credentials lub treści użytkowników podczas transmisji i zapewnia spójne zachowanie klientów zależne od originu.

Jak testować aktualizację ntfy?

Odtwórz bieżący stan ntfy w odizolowanym wdrożeniu, zastosuj wersję kandydującą i powtórz transakcję akceptacyjną. Zwróć szczególną uwagę na to, że przed aktualizacją ntfy należy sprawdzić klucze konfiguracji, migracje bazy auth i oczekiwania klientów. Zachowaj poprzedni obraz ntfy do czasu zrozumienia granicy migracji danych i rollbacku.