ntfy zelf hosten in 2026: topics, toegangsbeheer en aflevering

De meeste installatie-instructies voor ntfy stoppen na de eerste page load. Dat is te vroeg: de cache is ephemeral of WebSocket/SSE-verbindingen verlopen bij de proxy. Een bruikbare productietest is veeleisender — publiceer een bericht met curl, ontvang het via HTTP- en WebSocket-subscriptions, voeg een bestand toe en test één geauthenticeerde topic.

De rol van ntfy is eenvoudig: pushnotificaties versturen met een eenvoudig HTTP-request. De operationele scope omvat meer dan alleen het webproces. Daarom moeten de dependency, opgeslagen state en publieke route expliciet worden benoemd voordat er echte data binnenkomt.

De productieopzet van ntfy

Het ntfy HTTP-proces luistert op poort 80. Houd die poort op het applicatienetwerk en publiceer alleen de platformroute. De lokale runtimevereiste bestaat uit een config volume en een optionele auth-database. Test die grens vóór publicatie en opnieuw nadat een container is vervangen.

Leg de grens vast als een kort contract: wie verantwoordelijk is voor de vereiste, welke credential wordt gebruikt, welke timeout acceptabel is en hoe een fout zichtbaar wordt. Voer vervolgens deze transactie uit: publiceer een bericht met curl, ontvang het via HTTP- en WebSocket-subscriptions, voeg een bestand toe en test één geauthenticeerde topic. Observeer tijdens de run langlopende subscriber-verbindingen, de attachmentgrootte, cache-retentie en outbound push-relays, omdat deze workload een nuttiger uitgangspunt voor de sizing geeft dan een idle container.

Start ntfy zonder de bewegende delen te verbergen

Gebruik de container als vervangbare runtime, niet als de plek waar de waarheid staat.

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

Bevestig de lokale vereiste vóór je ntfy beschikbaar maakt: een config volume en een optionele auth-database. Controleer de containergebruiker, schrijfbare paden en gebonden listener voordat je ntfy blootstelt. Voer de volledige actie uit — publiceer een bericht met curl, ontvang het via HTTP- en WebSocket-subscriptions, voeg een bestand toe en test één geauthenticeerde topic — en sla de exacte image reference op die het resultaat heeft opgeleverd.

Geef ntfy één canoniek adres

Stel base-url in op de publieke HTTPS-origin die door publishers en subscribers wordt gebruikt. Stuur de gekozen hostname naar containerpoort 80, stuur de oorspronkelijke host en het HTTPS-schema door en publiceer geen tweede directe origin.

Test ntfy vanaf een externe client zonder bestaande state. Maak onderscheid tussen een ingress-fout en de bekende applicatiegrens — de cache is ephemeral of WebSocket/SSE-verbindingen verlopen bij de proxy. Een certificaat-, DNS- of 502-fout hoort bij routing; een request dat ntfy bereikt en pas daarna faalt, hoort bij applicatiestate, capaciteit of een ondersteunende vereiste. De handleiding voor TLS met een custom domain behandelt de eerste groep.

Bewijs dat ntfy een vervanging overleeft

Bescherm de state van ntfy voordat je de container optimaliseert. De vereiste set bestaat uit configuratie, de auth-database en attachments die behouden moeten blijven. Mount /var/cache/ntfy vóór de bootstrap, schrijf ongevaarlijke voorbeelddata en vervang de container om te bewijzen dat dit pad daadwerkelijk persistent is. Als meerdere stores consistent moeten blijven, documenteer dan in welke volgorde writes worden gepauzeerd en backups worden gemaakt.

Bewaar kopieën buiten de deploymentserver en versleutel materiaal dat credentials of private content bevat. Recovery is geslaagd wanneer users, ACL's, configuratie en bewaarde attachments terugkeren en een geauthenticeerde subscriber een nieuw bericht ontvangt. Het verschil tussen een persistente mount en een onafhankelijke kopie wordt behandeld in persistente storage en snapshots.

Geef ntfy niet de volledige host

Voor ntfy is het waardevolle oppervlak niet per se de landingspagina. De grootste fout is het toestaan van het raden van publieke topics wanneer berichten operationele details bevatten. Pak dit bewust aan: gebruik topic-ACL's, want onraadbare topicnamen zijn geen sterke autorisatie voor operationele berichten.

NTFY_BASE_URL is configuratie en geen secret; houd de waarde expliciet en bescherm de afzonderlijke credentials die door ntfy worden gebruikt. Gebruik een unprivileged container user wanneer de image dit ondersteunt en mount geen niet-gerelateerde credentials. Pas rate- of sizelimits toe bij de ingress, waar onbetrouwbare workloads langlopende subscriber-verbindingen, attachmentgrootte, cache-retentie en outbound push-relays kunnen verbruiken.

Upgrade ntfy zonder te gokken

Gebruik publiceer een bericht met curl, ontvang het via HTTP- en WebSocket-subscriptions, voeg een bestand toe en test één geauthenticeerde topic als ntfy smoke test na elke deployment. De bijbehorende metrics zijn langlopende subscriber-verbindingen, attachmentgrootte, cache-retentie en outbound push-relays; configureer alerts wanneer deze resources een punt naderen waarop de gebruikersactie verslechtert.

Het grootste wijzigingsrisico is dat configuratiesleutels, migraties van de auth-database en verwachtingen van clients vóór het updaten van ntfy moeten worden gecontroleerd. Een veilige release begint met een herstelbare snapshot en valideert elke eenrichtingswijziging van state voordat het verkeer wordt omgezet. Wanneer de cache ephemeral is of WebSocket/SSE-verbindingen bij de proxy verlopen, houd de mislukte container dan lang genoeg beschikbaar om de configuratie en de eerste fout te lezen.

De ntfy-release gate

Een release candidate voor ntfy verdient verkeer door een vast scenario te voltooien: publiceer een bericht met curl, ontvang het via HTTP- en WebSocket-subscriptions, voeg een bestand toe en test één geauthenticeerde topic. Leg de image digest, effectieve niet-geheime configuratie, publieke origin en timestamps voor dat scenario vast. De testdata moet disposable zijn, maar realistisch genoeg om hetzelfde pad als gebruikers te testen.

Voer de test uit nadat je de runtime hebt vervangen en bouw de service vervolgens opnieuw op vanuit configuratie, de auth-database en attachments die behouden moeten blijven. Recovery is geslaagd wanneer users, ACL's, configuratie en bewaarde attachments terugkeren en een geauthenticeerde subscriber een nieuw bericht ontvangt. Vergelijk de resource measurements voor langlopende subscriber-verbindingen, attachmentgrootte, cache-retentie en outbound push-relays met de vorige release en onderzoek betekenisvolle afwijkingen vóór promotie.

Voer tot slot deze gecontroleerde fout uit: verstuur ongevaarlijke input die dicht bij de resource- of formatlimiet ligt die bij deze grens hoort: de cache is ephemeral of WebSocket/SSE-verbindingen verlopen bij de proxy. Controleer of ntfy de fout uitlegt, bestaande state niet beschadigt en hervat zodra de geldige toestand terugkeert. Bewaar een geredigeerd logfragment en de recoverytijd. Samen dekken deze controles gedrag, duurzaamheid en beheerbaarheid af, in plaats van alleen uptime van het proces.

Houd ntfy expliciet terwijl Dockup routing afhandelt

Routing, certificaten, service replacement en gekoppelde storage zijn redelijke doelen voor automation. Dockup handelt die voor ntfy af en kan de bijbehorende managed database provisionen of verbinding maken met services op de eigen server van een klant.

Wat het niet moet verzinnen, is het trustbeleid van ntfy. Stel na de deployment base-url in op de publieke HTTPS-origin die door publishers en subscribers wordt gebruikt, handhaaf deze grens — gebruik topic-ACL's, want onraadbare topicnamen zijn geen sterke autorisatie voor operationele berichten — en verifieer het resultaat van dit scenario: publiceer een bericht met curl, ontvang het via HTTP- en WebSocket-subscriptions, voeg een bestand toe en test één geauthenticeerde topic. Het resultaat is infrastructuur met één klik en een applicatiespecifieke acceptatietest.

Veelgestelde vragen

Wat heeft ntfy nodig voor een productie-deployment?

Routeer de ntfy-container op poort 80 via één HTTPS-origin. De lokale runtimevereiste bestaat uit een config volume en een optionele auth-database. Beschouw ntfy pas als klaar wanneer je een bericht kunt publiceren met curl, het kunt ontvangen via HTTP- en WebSocket-subscriptions, een bestand kunt toevoegen en één geauthenticeerde topic kunt testen.

Welke ntfy-data hoort in een backup?

Maak /var/cache/ntfy persistent en neem configuratie, de auth-database en attachments die behouden moeten blijven op in hetzelfde recovery manifest. Een schone ntfy-restore is pas geslaagd wanneer users, ACL's, configuratie en bewaarde attachments terugkeren en een geauthenticeerde subscriber een nieuw bericht ontvangt.

Heeft ntfy HTTPS nodig achter een reverse proxy?

Gebruik HTTPS voor de publieke ntfy-origin en houd poort 80 op de interne route. Pas de ntfy-instelling correct toe: stel base-url in op de publieke HTTPS-origin die door publishers en subscribers wordt gebruikt. Voor ntfy beschermt HTTPS credentials of user content tijdens transport en zorgt het ervoor dat origingevoelig clientgedrag consistent blijft.

Hoe moet een ntfy-upgrade worden getest?

Herstel de huidige ntfy-state in een geïsoleerde deployment, pas de kandidaatversie toe en herhaal de acceptatietransactie. Let hier goed op, omdat configuratiesleutels, migraties van de auth-database en verwachtingen van clients vóór het updaten van ntfy moeten worden gecontroleerd. Houd de vorige ntfy-image beschikbaar totdat de grenzen van datamigratie en rollback duidelijk zijn.