Så självhostar du ntfy 2026: Topics, åtkomstkontroll och leverans
En praktisk guide till att självhosta ntfy med Docker, portar, beständig data, TLS, säkerhet, säkerhetskopior och de problem som hindrar produktionsanvändning. Steg för steg.
De flesta installationsanteckningar för ntfy slutar vid den första sidinläsningen. Det är för tidigt: cachen är flyktig eller så löper WebSocket/SSE-anslutningar ut vid proxyn. Ett användbart produktionstest är mer krävande — publicera ett meddelande med curl, ta emot det via HTTP- och WebSocket-prenumerationer, bifoga en fil och testa en autentiserad topic.
ntfy:s roll är enkel: skicka pushnotiser med en enkel HTTP-förfrågan. Den operativa omfattningen innefattar mer än webbprocessen, så beroendet, det lagrade tillståndet och den publika routen måste anges uttryckligen innan riktiga data anländer.
ntfy:s produktionsmodell
ntfy:s HTTP-process lyssnar på port 80. Behåll den porten i applikationsnätverket och publicera endast plattformsrouten. Det lokala runtime-kravet är en config-volym och en valfri auth-databas. Testa den gränsen före publicering och igen efter att en container har ersatts.
Skriv ner gränsen som ett kort kontrakt: vem som äger kravet, vilken credential som används, vilken timeout som är acceptabel och hur ett fel visar sig. Kör sedan den här transaktionen: publicera ett meddelande med curl, ta emot det via HTTP- och WebSocket-prenumerationer, bifoga en fil och testa en autentiserad topic. Observera långlivade prenumerantanslutningar, bilagestorlek, cache-retention och utgående push-reläer under körningen, eftersom den arbetsbelastningen ger en mer användbar utgångspunkt för dimensionering än en inaktiv container.
Starta ntfy utan att dölja de rörliga delarna
Använd containern som en utbytbar runtime, inte som platsen där sanningen finns.
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
Bekräfta det lokala kravet före exponering: en config-volym och en valfri auth-databas. Inspektera containeranvändaren, skrivbara sökvägar och den bundna lyssnaren innan du exponerar den. Kör hela flödet — publicera ett meddelande med curl, ta emot det via HTTP- och WebSocket-prenumerationer, bifoga en fil och testa en autentiserad topic — och spara den exakta image-referens som gav resultatet.
Ge ntfy en enda kanonisk adress
Sätt base-url till den publika HTTPS-origin som används av publishers och subscribers. Skicka det valda hostname:t till containerport 80, vidarebefordra den ursprungliga host-headern och HTTPS-schemat och undvik att publicera en andra direkt origin.
Testa ntfy från en ren extern klient. Separera ingressfel från den kända applikationsgränsen — cachen är flyktig eller så löper WebSocket/SSE-anslutningar ut vid proxyn. Certifikat-, DNS- eller 502-fel hör till routingen; en förfrågan som når ntfy men misslyckas senare hör till applikationens state, kapacitet eller dess stödjande krav. Guiden för TLS med egen domän täcker den första gruppen.
Bevisa att ntfy överlever en ersättning
Skydda ntfy:s state innan du optimerar containern. Det som måste finnas med är konfiguration, auth-databas och bilagor som ska överleva. Montera /var/cache/ntfy före bootstrap, skriv ofarliga exempeldata och ersätt containern för att bevisa att sökvägen faktiskt är persistent. Om flera datalager måste vara konsistenta, dokumentera i vilken ordning skrivningar pausas och säkerhetskopior tas.
Förvara kopior utanför deploymentsservern och kryptera material som innehåller credentials eller privat innehåll. Återställningen är lyckad när användare, ACL:er, konfiguration och sparade bilagor är tillbaka och en autentiserad subscriber tar emot ett nytt meddelande. Skillnaden mellan en persistent mount och en fristående kopia beskrivs i persistent lagring och snapshots.
Ge inte ntfy hela värden
För ntfy är den värdefulla exponeringsytan inte nödvändigtvis landningssidan. Det vanligaste misstaget är att tillåta publik gissning av topics när meddelanden innehåller operativa detaljer. Motverka det medvetet: använd topic-ACL:er, eftersom ogissningsbara topic-namn inte är stark auktorisering för operativa meddelanden.
NTFY_BASE_URL är konfiguration, inte en secret. Håll dess värde explicit och skydda samtidigt de separata credentials som ntfy använder. Använd en unprivileged container-användare när imagen stöder det och montera inga orelaterade credentials. Tillämpa rate- eller storleksbegränsningar vid ingress där otillförlitligt arbete kan förbruka långlivade prenumerantanslutningar, bilagestorlek, cache-retention och utgående push-reläer.
Uppgradera ntfy utan att gissa
Använd publicering av ett meddelande med curl, mottagning via HTTP- och WebSocket-prenumerationer, bifogande av en fil och test av en autentiserad topic som ntfy:s smoke test efter varje deployment. De stödjande mätvärdena är långlivade prenumerantanslutningar, bilagestorlek, cache-retention och utgående push-reläer. Larma när resurserna närmar sig en nivå som försämrar användarflödet.
Den främsta förändringsrisken är att konfigurationsnycklar, migreringar av auth-databasen och klientförväntningar måste kontrolleras innan ntfy uppdateras. En säker release utgår från en återställningsbar snapshot och validerar alla enkelriktade state-förändringar innan trafiken flyttas. När cachen är flyktig eller WebSocket/SSE-anslutningar löper ut vid proxyn ska du behålla den felande containern tillräckligt länge för att läsa dess konfiguration och första fel.
ntfy:s release gate
En releasekandidat för ntfy får trafik genom att slutföra ett fast scenario: publicera ett meddelande med curl, ta emot det via HTTP- och WebSocket-prenumerationer, bifoga en fil och testa en autentiserad topic. Fånga image digest, effektiv icke-hemlig konfiguration, publik origin och tidsstämplar för scenariot. Testdata ska kunna kastas, men vara tillräckligt realistiska för att använda samma flöde som användarna.
Kör scenariot efter att runtime har ersatts och bygg sedan om tjänsten från konfiguration, auth-databas och bilagor som måste överleva. Återställningen godkänns när användare, ACL:er, konfiguration och sparade bilagor är tillbaka och en autentiserad subscriber tar emot ett nytt meddelande. Jämför resursmätningar för långlivade prenumerantanslutningar, bilagestorlek, cache-retention och utgående push-reläer med föregående release och undersök betydande avvikelser före promotion.
Testa slutligen detta kontrollerade fel: skicka ofarlig input nära den resurs- eller formatgräns som hör till den här gränsen: cachen är flyktig eller så löper WebSocket/SSE-anslutningar ut vid proxyn. Kontrollera att ntfy förklarar felet, inte skadar befintligt state och återhämtar sig när det giltiga tillståndet återkommer. Spara ett redigerat loggutdrag och återställningstiden. Tillsammans täcker dessa kontroller beteende, beständighet och driftbarhet — inte bara att processen är igång.
Håll ntfy explicit medan Dockup hanterar routingen
Routing, certifikat, ersättning av tjänster och ansluten lagring är rimliga mål för automation. Dockup hanterar detta för ntfy och kan provisionera den relaterade hanterade databasen eller ansluta till tjänster på kundens egen server.
Det som inte ska uppfinnas är ntfy:s trust policy. Efter deploymenten ska du sätta base-url till den publika HTTPS-origin som används av publishers och subscribers, tillämpa den här gränsen — använd topic-ACL:er, eftersom ogissningsbara topic-namn inte är stark auktorisering för operativa meddelanden — och verifiera resultatet av följande scenario: publicera ett meddelande med curl, ta emot det via HTTP- och WebSocket-prenumerationer, bifoga en fil och testa en autentiserad topic. Resultatet är infrastruktur med ett klick och ett applikationsspecifikt acceptanstest.
Vanliga frågor
Vad behöver ntfy för en produktionsdeployment?
Routa ntfy-containern på port 80 via en enda HTTPS-origin. Det lokala runtime-kravet är en config-volym och en valfri auth-databas. Betrakta inte ntfy som redo förrän du kan publicera ett meddelande med curl, ta emot det via HTTP- och WebSocket-prenumerationer, bifoga en fil och testa en autentiserad topic.
Vilka ntfy-data ska ingå i en säkerhetskopia?
Persist /var/cache/ntfy och inkludera konfiguration, auth-databas och bilagor som måste överleva i samma återställningsmanifest. En ren ntfy-återställning är godkänd först när användare, ACL:er, konfiguration och sparade bilagor är tillbaka och en autentiserad subscriber tar emot ett nytt meddelande.
Kräver ntfy HTTPS bakom en reverse proxy?
Använd HTTPS för den publika ntfy-originen och behåll port 80 på den interna routen. Tillämpa ntfy-inställningen korrekt: sätt base-url till den publika HTTPS-origin som används av publishers och subscribers. För ntfy skyddar HTTPS credentials eller användarinnehåll under överföring och gör att klientbeteende som är känsligt för origin förblir konsekvent.
Hur bör en ntfy-uppgradering testas?
Återställ aktuellt ntfy-state i en isolerad deployment, använd kandidatversionen och upprepa dess acceptanstransaktion. Var särskilt uppmärksam eftersom konfigurationsnycklar, migreringar av auth-databasen och klientförväntningar måste kontrolleras innan ntfy uppdateras. Behåll föregående ntfy-image tills datamigreringens och rollbackens gränser är förstådda.