Sådan self-hoster du ntfy i 2026: Topics, adgangskontrol og levering

De fleste installationsnoter til ntfy slutter efter den første sideindlæsning. Det er for tidligt: Cachen er ephemeral, eller WebSocket-/SSE-forbindelser får timeout ved proxyen. En nyttig produktionstest er mere krævende — publicér en besked med curl, modtag den via HTTP- og WebSocket-subscriptions, vedhæft en fil, og test ét autentificeret topic.

ntfy's rolle er enkel: push-notifikationer, der sendes med en simpel HTTP-request. Driftsgrænsen omfatter mere end webprocessen, så dependency, gemt state og den offentlige route skal navngives eksplicit, før der ankommer rigtige data.

ntfy's produktionsarkitektur

ntfy HTTP-processen lytter på port 80. Behold porten på application networket, og publicér kun platformens route. Det lokale runtime-krav er en config volume og eventuelt en auth database. Test denne grænse før publicering og igen efter udskiftning af en container.

Skriv grænsen ned som en kort kontrakt: Hvem ejer kravet, hvilken credential bruges, hvilken timeout er acceptabel, og hvordan viser en fejl sig? Kør derefter denne transaktion: publicér en besked med curl, modtag den via HTTP- og WebSocket-subscriptions, vedhæft en fil, og test ét autentificeret topic. Observer long-lived subscriber connections, attachment size, cache retention og outbound push relays under kørslen, fordi denne workload giver et mere brugbart udgangspunkt for sizing end en inaktiv container.

Start ntfy uden at skjule de bevægelige dele

Brug containeren som et runtime, der kan udskiftes, ikke som stedet, hvor sandheden ligger.

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æft det lokale krav før eksponering: en config volume og eventuelt en auth database. Inspicér containerens bruger, writable paths og bundne listener, før du eksponerer den. Kør hele handlingen — publicér en besked med curl, modtag den via HTTP- og WebSocket-subscriptions, vedhæft en fil, og test ét autentificeret topic — og gem den præcise image reference, der producerede resultatet.

Giv ntfy én canonical address

Sæt base-url til den offentlige HTTPS-origin, som publishers og subscribers bruger. Send det valgte hostname til containerens port 80, videresend den oprindelige host og HTTPS-scheme, og undgå at publicere en ekstra direkte origin.

Test ntfy fra en ren ekstern client. Adskil ingress-fejl fra den kendte application boundary — cachen er ephemeral, eller WebSocket-/SSE-forbindelser får timeout ved proxyen. En certificate-, DNS- eller 502-fejl hører til routing; en request, der når frem til ntfy og fejler senere, hører til application state, capacity eller den understøttende dependency. Guiden til TLS for custom domains dækker den første gruppe.

Bevis, at ntfy overlever udskiftning

Beskyt ntfy's state, før du optimerer containeren. Det nødvendige sæt er configuration, auth database og attachments, der skal overleve. Mount /var/cache/ntfy før bootstrap, skriv harmløse eksempeldata, og udskift containeren for at bevise, at stien faktisk er persistent. Hvis flere stores skal stemme overens, skal du dokumentere rækkefølgen, som writes pauses og backups tages i.

Opbevar kopier uden for deployment-serveren, og krypter materiale, der indeholder credentials eller privat indhold. Recovery lykkes, når users, ACL'er, configuration og retained attachments kommer tilbage, og en autentificeret subscriber modtager en ny besked. Forskellen mellem et persistent mount og en uafhængig kopi er beskrevet i persistent storage og snapshots.

Giv ikke ntfy hele hosten

For ntfy er den værdifulde surface ikke nødvendigvis landing page. Den største fejl er at tillade offentligt gæt på topics, når beskeder indeholder driftsoplysninger. Modvirk det bevidst: Brug topic ACL'er, fordi topic-navne, der er svære at gætte, ikke er stærk authorization for operationelle beskeder.

NTFY_BASE_URL er configuration, ikke en secret; behold værdien eksplicit, mens du beskytter de separate credentials, som ntfy bruger. Brug en unprivileged container user, når imaget understøtter det, og mount ingen uvedkommende credentials. Anvend rate- eller size limits ved ingress, hvor untrusted work kan bruge long-lived subscriber connections, attachment size, cache retention og outbound push relays.

Opgradér ntfy uden at gætte

Brug publicering af en besked med curl, modtagelse via HTTP- og WebSocket-subscriptions, vedhæftning af en fil og test af ét autentificeret topic som ntfy's smoke test efter hver deployment. De understøttende metrics er long-lived subscriber connections, attachment size, cache retention og outbound push relays; opret alerts dér, hvor disse resources nærmer sig et niveau, der forringer brugerhandlingen.

Den største ændringsrisiko er, at configuration keys, auth database migrations og client expectations skal kontrolleres, før ntfy opdateres. En sikker release starter fra et snapshot, der kan gendannes, og validerer enhver irreversibel state change, før trafikken flyttes. Når cachen er ephemeral, eller WebSocket-/SSE-forbindelser får timeout ved proxyen, skal du beholde den fejlede container længe nok til at læse dens configuration og første fejl.

ntfy's release gate

En release candidate til ntfy får trafik ved at gennemføre et fast scenario: publicér en besked med curl, modtag den via HTTP- og WebSocket-subscriptions, vedhæft en fil, og test ét autentificeret topic. Registrér image digest, effektiv non-secret configuration, public origin og timestamps for scenariet. Testdataene skal kunne bortskaffes, men være realistiske nok til at gennemgå den samme path som brugerne.

Kør testen efter udskiftning af runtime, og rebuild derefter servicen fra configuration, auth database og attachments, der skal overleve. Recovery består, når users, ACL'er, configuration og retained attachments kommer tilbage, og en autentificeret subscriber modtager en ny besked. Sammenlign resource-målinger for long-lived subscriber connections, attachment size, cache retention og outbound push relays med den tidligere release, og undersøg væsentlige afvigelser før promotion.

Udfør til sidst denne kontrollerede fejl: Indsend harmløst input tæt på den resource- eller formatgrænse, der er knyttet til denne boundary: Cachen er ephemeral, eller WebSocket-/SSE-forbindelser får timeout ved proxyen. Kontrollér, at ntfy forklarer fejlen, ikke beskadiger eksisterende state og genoptager driften, når den gyldige betingelse vender tilbage. Gem et redigeret loguddrag og recovery-tiden. Tilsammen dækker disse kontroller behavior, durability og operability — ikke kun, om processen kører.

Hold ntfy eksplicit, mens Dockup håndterer routing

Routing, certificates, service replacement og attached storage er fornuftige mål for automation. Dockup håndterer dette for ntfy og kan provisionere den tilknyttede managed database eller forbinde til services på kundens egen server.

Det, Dockup ikke bør opfinde, er ntfy's trust policy. Efter deployment skal du sætte base-url til den offentlige HTTPS-origin, som publishers og subscribers bruger, håndhæve denne boundary — brug topic ACL'er, fordi topic-navne, der er svære at gætte, ikke er stærk authorization for operationelle beskeder — og verificere resultatet af dette scenario: publicér en besked med curl, modtag den via HTTP- og WebSocket-subscriptions, vedhæft en fil, og test ét autentificeret topic. Resultatet er infrastruktur med ét klik og en applikationsspecifik acceptance test.

Ofte stillede spørgsmål

Hvad skal ntfy bruge til en produktion-deployment?

Route ntfy-containeren på port 80 gennem én HTTPS-origin. Det lokale runtime-krav er en config volume og eventuelt en auth database. Erklær ikke ntfy klar, før du kan publicere en besked med curl, modtage den via HTTP- og WebSocket-subscriptions, vedhæfte en fil og teste ét autentificeret topic.

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

Persistér /var/cache/ntfy, og inkludér configuration, auth database og attachments, der skal overleve, i det samme recovery manifest. En ren ntfy-restore er kun gennemført, når users, ACL'er, configuration og retained attachments kommer tilbage, og en autentificeret subscriber modtager en ny besked.

Kræver ntfy HTTPS bag en reverse proxy?

Brug HTTPS til den offentlige ntfy-origin, og behold port 80 på den interne route. Anvend ntfy-indstillingen korrekt: Sæt base-url til den offentlige HTTPS-origin, som publishers og subscribers bruger. For ntfy beskytter HTTPS credentials eller brugerindhold under transport og sikrer ensartet client behavior, der afhænger af origin.

Hvordan bør en ntfy-opgradering testes?

Gendan den aktuelle ntfy-state i en isoleret deployment, anvend candidate-versionen, og gentag dens acceptance transaction. Vær særligt opmærksom, fordi configuration keys, auth database migrations og client expectations skal kontrolleres, før ntfy opdateres. Behold det tidligere ntfy-image, indtil data-migrationens og rollbackens boundary er forstået.