Slik selvhoster du ntfy i 2026: Topics, tilgangskontroll og levering

De fleste notater om ntfy-installasjon stopper etter den første sidelastingen. Det er for tidlig: cachen er flyktig, eller WebSocket-/SSE-tilkoblinger får tidsavbrudd i proxyen. En nyttig produksjonstest er mer krevende — publiser en melding med curl, motta den gjennom HTTP- og WebSocket-subscriptions, legg ved en fil og test ett autentisert topic.

Rollen til ntfy er enkel: push-varsler sendt med en enkel HTTP-forespørsel. Driftsgrensen omfatter mer enn webprosessen, så avhengigheten, den lagrede tilstanden og den offentlige ruten må navngis eksplisitt før ekte data kommer inn.

Hvordan ntfy bør se ut i produksjon

HTTP-prosessen til ntfy lytter på port 80. La denne porten være på applikasjonsnettverket, og publiser bare plattformruten. Det lokale runtime-kravet er et config-volum og en valgfri auth-database. Test denne grensen før publisering og igjen etter at en container er erstattet.

Skriv ned grensen som en kort kontrakt: hvem som eier kravet, hvilken credential som brukes, hvilket tidsavbrudd som er akseptabelt, og hvordan en feil vises. Kjør deretter denne transaksjonen: publiser en melding med curl, motta den gjennom HTTP- og WebSocket-subscriptions, legg ved en fil og test ett autentisert topic. Følg med på langvarige subscriber-tilkoblinger, vedleggsstørrelse, cache-retention og utgående push-reléer under kjøringen, fordi denne arbeidsbelastningen gir et mer nyttig utgangspunkt for dimensjonering enn en inaktiv container.

Start ntfy uten å skjule de viktige delene

Bruk containeren som et utskiftbart runtime-miljø, ikke som stedet der sannheten lagres.

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

Bekreft det lokale kravet før eksponering: et config-volum og en valgfri auth-database. Kontroller container-brukeren, skrivbare stier og den bundne lytteren før du eksponerer den. Kjør hele handlingen — publiser en melding med curl, motta den gjennom HTTP- og WebSocket-subscriptions, legg ved en fil og test ett autentisert topic — og lagre den nøyaktige image-referansen som produserte resultatet.

Gi ntfy én kanonisk adresse

Sett base-url til den offentlige HTTPS-opprinnelsen som brukes av publishers og subscribers. Send det valgte hostnavnet til containerport 80, videresend den opprinnelige hosten og HTTPS-skjemaet, og unngå å publisere en ekstra direkte opprinnelse.

Test ntfy fra en ren ekstern klient. Skill ingress-feil fra den kjente applikasjonsgrensen — cachen er flyktig, eller WebSocket-/SSE-tilkoblinger får tidsavbrudd i proxyen. En sertifikat-, DNS- eller 502-feil hører til rutingen. En forespørsel som når ntfy og feiler senere, hører til applikasjonstilstand, kapasitet eller en støttende avhengighet. Veiledningen for TLS med egendefinert domene dekker den første gruppen.

Bevis at ntfy overlever utskifting

Beskytt tilstanden til ntfy før du optimaliserer containeren. Det nødvendige settet er konfigurasjon, auth-database og vedlegg som må overleve. Monter /var/cache/ntfy før bootstrap, skriv ufarlige eksempeldata og erstatt containeren for å bevise at denne stien faktisk er persistent. Hvis flere lagringssteder må være konsistente, dokumenter rekkefølgen for når skriving pauses og sikkerhetskopier tas.

Oppbevar kopier utenfor deployment-serveren, og krypter materiale som inneholder credentials eller privat innhold. Gjenoppretting er vellykket når brukere, ACL-er, konfigurasjon og bevarte vedlegg er tilbake, og en autentisert subscriber mottar en ny melding. Forskjellen mellom et persistent mount og en uavhengig kopi er beskrevet i persistent lagring og snapshots.

Ikke gi ntfy tilgang til hele verten

For ntfy er den verdifulle overflaten ikke nødvendigvis landingssiden. Den største feilen er å tillate offentlig gjetting av topics når meldinger inneholder operasjonelle detaljer. Motvirk dette bevisst: bruk topic-ACL-er, fordi ugjetbare topic-navn ikke er sterk autorisering for operasjonelle meldinger.

NTFY_BASE_URL er konfigurasjon, ikke en secret. Hold verdien eksplisitt, samtidig som du beskytter de separate credentialene som brukes av ntfy. Bruk en upriviligert container-bruker når imaget støtter det, og ikke monter uvedkommende credentials. Bruk rate- eller størrelsesbegrensninger i ingress-laget der upålitelige forespørsler kan forbruke langvarige subscriber-tilkoblinger, vedleggsstørrelse, cache-retention og utgående push-reléer.

Oppgrader ntfy uten å gjette

Bruk publisering av en melding med curl, mottak gjennom HTTP- og WebSocket-subscriptions, filvedlegg og testing av ett autentisert topic som ntfy-smoketesten etter hver deployment. De tilhørende metrikkene er langvarige subscriber-tilkoblinger, vedleggsstørrelse, cache-retention og utgående push-reléer. Sett varsler der disse ressursene nærmer seg et nivå som forringer brukerhandlingen.

Den største endringsrisikoen er at konfigurasjonsnøkler, migreringer av auth-databasen og klientforventninger må kontrolleres før ntfy oppdateres. En trygg release starter med et gjenopprettbart snapshot og validerer alle irreversible tilstandsendringer før trafikken flyttes. Når cachen er flyktig, eller WebSocket-/SSE-tilkoblinger får tidsavbrudd i proxyen, bør du beholde den feilede containeren lenge nok til å lese konfigurasjonen og den første feilen.

Release-gaten for ntfy

En releasekandidat for ntfy får trafikk ved å fullføre et fast scenario: publiser en melding med curl, motta den gjennom HTTP- og WebSocket-subscriptions, legg ved en fil og test ett autentisert topic. Registrer image-digest, effektiv ikke-hemmelig konfigurasjon, offentlig opprinnelse og tidsstempler for scenarioet. Testdataene bør kunne kastes, men være realistiske nok til å dekke samme flyt som brukerne.

Kjør testen etter at runtime-miljøet er erstattet, og bygg deretter tjenesten på nytt fra konfigurasjon, auth-database og vedlegg som må overleve. Gjenoppretting er vellykket når brukere, ACL-er, konfigurasjon og bevarte vedlegg er tilbake, og en autentisert subscriber mottar en ny melding. Sammenlign ressursmålinger for langvarige subscriber-tilkoblinger, vedleggsstørrelse, cache-retention og utgående push-reléer med forrige release, og undersøk vesentlige avvik før promovering.

Test til slutt denne kontrollerte feilen: send inn ufarlige data nær ressurs- eller formatgrensen som er knyttet til denne grensen: cachen er flyktig, eller WebSocket-/SSE-tilkoblinger får tidsavbrudd i proxyen. Bekreft at ntfy forklarer feilen, ikke skader eksisterende tilstand og gjenopptar driften når den gyldige tilstanden er tilbake. Lagre et redigert loggutdrag og gjenopprettingstiden. Til sammen dekker disse kontrollene atferd, bestandighet og drift — ikke bare at prosessen kjører.

Hold ntfy eksplisitt mens Dockup håndterer ruting

Ruting, sertifikater, utskifting av tjenester og tilknyttet lagring er fornuftige mål for automatisering. Dockup håndterer dette for ntfy og kan klargjøre den tilhørende administrerte databasen eller koble til tjenester på kundens egen server.

Det Dockup ikke bør finne på, er ntfys trust policy. Etter deployment setter du base-url til den offentlige HTTPS-opprinnelsen som brukes av publishers og subscribers, håndhever denne grensen — bruk topic-ACL-er, fordi ugjetbare topic-navn ikke er sterk autorisering for operasjonelle meldinger — og verifiserer resultatet av dette scenarioet: publiser en melding med curl, motta den gjennom HTTP- og WebSocket-subscriptions, legg ved en fil og test ett autentisert topic. Resultatet er infrastruktur med ett klikk og en applikasjonsspesifikk akseptansetest.

Vanlige spørsmål

Hva trenger ntfy for en produksjonsdeployment?

Rout ntfy-containeren på port 80 gjennom én HTTPS-opprinnelse. Det lokale runtime-kravet er et config-volum og en valgfri auth-database. Ikke erklær ntfy som klar før du kan publisere en melding med curl, motta den gjennom HTTP- og WebSocket-subscriptions, legge ved en fil og teste ett autentisert topic.

Hvilke ntfy-data hører hjemme i en sikkerhetskopi?

Gjør /var/cache/ntfy persistent, og inkluder konfigurasjon, auth-database og vedlegg som må overleve i det samme gjenopprettingsmanifestet. En ren ntfy-gjenoppretting er først godkjent når brukere, ACL-er, konfigurasjon og bevarte vedlegg er tilbake, og en autentisert subscriber mottar en ny melding.

Krever ntfy HTTPS bak en reverse proxy?

Bruk HTTPS for den offentlige ntfy-opprinnelsen, og behold port 80 på den interne ruten. Bruk ntfy-innstillingen riktig: sett base-url til den offentlige HTTPS-opprinnelsen som brukes av publishers og subscribers. For ntfy beskytter HTTPS credentials eller brukerinnhold under transport og sørger for konsistent klientatferd som er avhengig av opprinnelsen.

Hvordan bør en ntfy-oppgradering testes?

Gjenopprett den gjeldende ntfy-tilstanden i en isolert deployment, ta i bruk kandidatversjonen og gjenta akseptansetransaksjonen. Vær spesielt oppmerksom på at konfigurasjonsnøkler, migreringer av auth-databasen og klientforventninger må kontrolleres før ntfy oppdateres. Behold det forrige ntfy-imaget til grensen for datamigrering og rollback er forstått.