Jak v roce 2026 provozovat ntfy vlastním hostingem: témata, řízení přístupu a doručování

Většina návodů k instalaci ntfy končí u prvního načtení stránky. To je příliš brzy: cache je pomíjivá nebo na proxy vyprší WebSocket/SSE připojení. Užitečný produkční test je náročnější — publikujte zprávu pomocí curl, přijměte ji přes HTTP a WebSocket subscriptions, připojte soubor a otestujte jedno autentizované téma.

Role ntfy je jednoduchá: odesílání push notifikací pomocí jednoduchého HTTP požadavku. Jeho provozní hranice zahrnuje více než jen webový proces, proto je nutné před příchodem skutečných dat explicitně pojmenovat závislost, uložený stav i veřejnou route.

Produkční podoba ntfy

HTTP proces ntfy naslouchá na portu 80; tento port ponechte v aplikační síti a publikujte pouze route platformy. Lokální runtime vyžaduje konfigurační volume a volitelnou databázi pro autentizaci. Tuto hranici otestujte před publikováním a znovu po nahrazení containeru.

Popište hranici jako krátký kontrakt: kdo požadavek vlastní, které credentials se používají, jaký timeout je přijatelný a jak se projeví selhání. Poté spusťte tuto transakci: publikujte zprávu pomocí curl, přijměte ji přes HTTP a WebSocket subscriptions, připojte soubor a otestujte jedno autentizované téma. Během běhu sledujte dlouho trvající subscriber connections, velikost příloh, retenci cache a outbound push relays, protože tato zátěž poskytne užitečnější výchozí velikost než nečinný container.

Spusťte ntfy bez skrývání důležitých částí

Použijte container jako nahraditelný runtime, nikoli jako místo, kde je uložen zdroj pravdy.

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

Před vystavením služby ověřte lokální požadavek: konfigurační volume a volitelnou databázi pro autentizaci. Před vystavením zkontrolujte uživatele containeru, zapisovatelné cesty a bindovaný listener. Spusťte kompletní akci — publikujte zprávu pomocí curl, přijměte ji přes HTTP a WebSocket subscriptions, připojte soubor a otestujte jedno autentizované téma — a uložte přesnou referenci image, která výsledek vytvořila.

Dejte ntfy jednu kanonickou adresu

Nastavte base-url na veřejný HTTPS origin používaný publishery a subscribery. Zvolený hostname směrujte na port 80 containeru, předávejte původní host a HTTPS scheme a vyhněte se publikování druhého přímého originu.

Otestujte ntfy z čistého externího klienta. Oddělte selhání ingressu od známé aplikační hranice — cache je pomíjivá nebo na proxy vyprší WebSocket/SSE připojení. Chyba certifikátu, DNS nebo 502 patří do routingu; požadavek, který dorazí do ntfy a selže až později, souvisí se stavem aplikace, kapacitou nebo její podpůrnou závislostí. První skupině se věnuje průvodce TLS pro vlastní doménu.

Ověřte, že ntfy přežije nahrazení

Chraňte stav ntfy dříve, než začnete optimalizovat jeho container. Povinnou sadou je konfigurace, databáze pro autentizaci a přílohy, které musí zůstat zachovány. Před bootstrapem připojte /var/cache/ntfy, zapište neškodná ukázková data a nahraďte container, abyste ověřili, že je tato cesta skutečně persistentní. Pokud musí být konzistentních více úložišť, zdokumentujte pořadí, ve kterém se pozastavují zápisy a pořizují zálohy.

Kopie uchovávejte mimo deployment server a zašifrujte materiál obsahující credentials nebo privátní obsah. Obnova je úspěšná, když se vrátí uživatelé, ACL, konfigurace i zachované přílohy a autentizovaný subscriber přijme novou zprávu. Rozdílu mezi persistentním mountem a nezávislou kopií se věnuje persistentní storage a snapshots.

Nedávejte ntfy přístup k celému hostiteli

U ntfy nemusí být nejcennější plochou úvodní stránka. Hlavní chybou je povolit veřejné hádání názvů témat v situaci, kdy zprávy obsahují provozní informace. Této chybě předcházejte záměrně: používejte topic ACL, protože neuhodnutelné názvy témat nejsou pro provozní zprávy silnou autorizací.

NTFY_BASE_URL je konfigurace, nikoli secret; jeho hodnotu ponechte explicitní a chraňte samostatné credentials používané ntfy. Pokud to image podporuje, použijte neprivilegovaného uživatele containeru a nepřipojujte žádné nesouvisející credentials. Na ingressu aplikujte limity rychlosti nebo velikosti tam, kde nedůvěryhodná práce může spotřebovávat dlouho trvající subscriber connections, kapacitu příloh, retenci cache a outbound push relays.

Aktualizujte ntfy bez hádání

Po každém deploymentu použijte jako smoke test ntfy tento scénář: publikujte zprávu pomocí curl, přijměte ji přes HTTP a WebSocket subscriptions, připojte soubor a otestujte jedno autentizované téma. Podpůrné metriky tvoří dlouho trvající subscriber connections, velikost příloh, retence cache a outbound push relays; nastavte alerting tam, kde se tyto zdroje blíží bodu, který zhoršuje uživatelskou akci.

Hlavním rizikem změny je, že před aktualizací ntfy je nutné zkontrolovat konfigurační klíče, migrace databáze pro autentizaci a očekávání klientů. Bezpečný release začíná obnovitelným snapshotem a před přesunem provozu ověřuje všechny jednosměrné změny stavu. Pokud je cache pomíjivá nebo na proxy vyprší WebSocket/SSE připojení, ponechte selhaný container dostatečně dlouho v provozu, abyste mohli přečíst jeho konfiguraci a první chybu.

Release gate pro ntfy

Release candidate ntfy získá provoz až po dokončení pevně definovaného scénáře: publikujte zprávu pomocí curl, přijměte ji přes HTTP a WebSocket subscriptions, připojte soubor a otestujte jedno autentizované téma. Zachyťte digest image, efektivní konfiguraci bez secretů, veřejný origin a časová razítka tohoto scénáře. Testovací data by měla být odstranitelná, ale zároveň dostatečně realistická, aby ověřila stejnou cestu jako u uživatelů.

Spusťte jej po nahrazení runtime a poté službu znovu sestavte z konfigurace, databáze pro autentizaci a příloh, které musí zůstat zachovány. Obnova je úspěšná, když se vrátí uživatelé, ACL, konfigurace i zachované přílohy a autentizovaný subscriber přijme novou zprávu. Porovnejte měření zdrojů pro dlouho trvající subscriber connections, velikost příloh, retenci cache a outbound push relays s předchozím releasem a před nasazením prozkoumejte významné odchylky.

Nakonec proveďte toto řízené selhání: odešlete neškodný vstup poblíž limitu zdroje nebo formátu souvisejícího s touto hranicí: cache je pomíjivá nebo na proxy vyprší WebSocket/SSE připojení. Ověřte, že ntfy selhání vysvětlí, nepoškodí existující stav a po návratu platné podmínky znovu pokračuje. Uložte redigovaný výpis logu a dobu obnovy. Tyto kontroly společně pokrývají chování, trvanlivost i provozuschopnost, nikoli pouze dostupnost procesu.

Udržujte ntfy explicitní, zatímco Dockup řeší routing

Routing, certifikáty, nahrazování služeb a připojené storage jsou rozumné cíle pro automatizaci. Dockup je pro ntfy řeší a může zřídit související managed databázi nebo se připojit ke službám na vlastním serveru zákazníka.

Neměl by ale vymýšlet trust policy ntfy. Po deploymentu nastavte base-url na veřejný HTTPS origin používaný publishery a subscribery, vynucujte tuto hranici — používejte topic ACL, protože neuhodnutelné názvy témat nejsou pro provozní zprávy silnou autorizací — a ověřte výsledek tohoto scénáře: publikujte zprávu pomocí curl, přijměte ji přes HTTP a WebSocket subscriptions, připojte soubor a otestujte jedno autentizované téma. Výsledkem je infrastruktura na jedno kliknutí s akceptačním testem specifickým pro aplikaci.

Často kladené otázky

Co ntfy potřebuje pro produkční deployment?

Veďte container ntfy na portu 80 přes jeden HTTPS origin. Lokální runtime vyžaduje konfigurační volume a volitelnou databázi pro autentizaci. Nt​​fy nepovažujte za připravené, dokud nedokážete publikovat zprávu pomocí curl, přijmout ji přes HTTP a WebSocket subscriptions, připojit soubor a otestovat jedno autentizované téma.

Která data ntfy patří do zálohy?

Persistujte /var/cache/ntfy a do stejného recovery manifestu zahrňte konfiguraci, databázi pro autentizaci a přílohy, které musí zůstat zachovány. Čistá obnova ntfy je úspěšná pouze tehdy, když se vrátí uživatelé, ACL, konfigurace i zachované přílohy a autentizovaný subscriber přijme novou zprávu.

Vyžaduje ntfy za reverse proxy HTTPS?

Pro veřejný origin ntfy používejte HTTPS a port 80 ponechte na interní route. Nastavení ntfy aplikujte správně: nastavte base-url na veřejný HTTPS origin používaný publishery a subscribery. U ntfy HTTPS chrání credentials nebo uživatelský obsah při přenosu a udržuje konzistentní chování klientů závislé na originu.

Jak testovat aktualizaci ntfy?

Obnovte aktuální stav ntfy v izolovaném deploymentu, použijte kandidátní verzi a zopakujte její akceptační transakci. Věnujte tomu zvláštní pozornost, protože před aktualizací ntfy je nutné zkontrolovat konfigurační klíče, migrace databáze pro autentizaci a očekávání klientů. Předchozí image ntfy ponechte, dokud neporozumíte hranici migrace dat a rollbacku.