Come fare il self-hosting di ntfy nel 2026: topic, controllo degli accessi e delivery

La maggior parte delle note sull'installazione di ntfy si ferma al primo caricamento della pagina. È troppo presto: la cache è effimera oppure le connessioni WebSocket/SSE vanno in timeout sul proxy. Un test di produzione utile è più impegnativo: pubblicare un messaggio con curl, riceverlo tramite subscription HTTP e WebSocket, allegare un file e testare un topic autenticato.

Il ruolo di ntfy è semplice: inviare notifiche push con una richiesta HTTP. Il suo perimetro operativo comprende più del solo processo web, quindi dipendenza, stato persistito e route pubblica devono essere indicati esplicitamente prima che arrivino dati reali.

La configurazione di ntfy per la produzione

Il processo HTTP di ntfy ascolta sulla porta 80; mantieni quella porta sulla rete dell'applicazione e pubblica solo la route della piattaforma. Il requisito del runtime locale è un volume per la configurazione e, facoltativamente, un database di autenticazione. Verifica questo perimetro prima della pubblicazione e di nuovo dopo la sostituzione di un container.

Metti il perimetro nero su bianco in un breve contratto: chi è responsabile del requisito, quale credenziale viene utilizzata, quale timeout è accettabile e come si manifesta un errore. Esegui quindi questa transazione: pubblica un messaggio con curl, ricevilo tramite subscription HTTP e WebSocket, allega un file e testa un topic autenticato. Durante l'esecuzione osserva le connessioni persistenti dei subscriber, la dimensione degli allegati, la retention della cache e i relay push in uscita, perché questo workload offre un punto di partenza più utile per il dimensionamento rispetto a un container inattivo.

Avvia ntfy senza nascondere i dettagli operativi

Usa il container come runtime sostituibile, non come fonte della verità.

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

Conferma il requisito locale prima dell'esposizione: un volume per la configurazione e, facoltativamente, un database di autenticazione. Controlla l'utente del container, i path scrivibili e il listener associato prima di esporlo. Esegui l'azione completa — pubblica un messaggio con curl, ricevilo tramite subscription HTTP e WebSocket, allega un file e testa un topic autenticato — e salva il riferimento esatto dell'immagine che ha prodotto il risultato.

Assegna a ntfy un unico indirizzo canonico

Imposta base-url sull'origine HTTPS pubblica utilizzata da publisher e subscriber. Invia l'hostname scelto alla porta 80 del container, inoltra l'host originale e lo schema HTTPS ed evita di pubblicare una seconda origine diretta.

Testa ntfy da un client esterno pulito. Separa il problema di ingress dal perimetro applicativo noto: la cache è effimera oppure le connessioni WebSocket/SSE vanno in timeout sul proxy. Un errore di certificato, DNS o 502 riguarda il routing; una richiesta che raggiunge ntfy ma fallisce in seguito riguarda lo stato dell'applicazione, la capacità o il relativo requisito di supporto. La guida al TLS automatico per domini personalizzati tratta il primo gruppo.

Verifica che ntfy superi una sostituzione

Proteggi lo stato di ntfy prima di ottimizzare il container. L'insieme richiesto comprende la configurazione, il database di autenticazione e gli allegati che devono sopravvivere. Monta /var/cache/ntfy prima del bootstrap, scrivi dati di esempio innocui e sostituisci il container per verificare che quel path sia effettivamente persistente. Se più storage devono rimanere coerenti, documenta l'ordine in cui vengono sospese le scritture e creati i backup.

Conserva copie al di fuori del server di deployment e cifra il materiale che contiene credenziali o contenuti privati. Il ripristino ha esito positivo quando utenti, ACL, configurazione e allegati conservati vengono recuperati e un subscriber autenticato riceve un nuovo messaggio. La differenza tra un mount persistente e una copia indipendente è descritta in storage persistente e snapshot.

Non concedere a ntfy l'accesso all'intero host

Per ntfy, la superficie più importante non è necessariamente la landing page. L'errore principale consiste nel consentire di indovinare pubblicamente i topic quando i messaggi contengono dettagli operativi. Contrasta deliberatamente questo rischio: usa le ACL dei topic, perché nomi di topic non indovinabili non costituiscono una vera autorizzazione per i messaggi operativi.

NTFY_BASE_URL è una configurazione, non un secret; mantieni esplicito il suo valore proteggendo separatamente le credenziali utilizzate da ntfy. Usa un utente non privilegiato per il container quando l'immagine lo supporta e non montare credenziali non correlate. Applica limiti di rate o di dimensione all'ingress, dove il lavoro non attendibile può consumare connessioni persistenti dei subscriber, dimensione degli allegati, retention della cache e relay push in uscita.

Aggiorna ntfy senza procedere per tentativi

Usa la pubblicazione di un messaggio con curl, la ricezione tramite subscription HTTP e WebSocket, l'allegato di un file e il test di un topic autenticato come smoke test di ntfy dopo ogni deployment. Le metriche di supporto sono le connessioni persistenti dei subscriber, la dimensione degli allegati, la retention della cache e i relay push in uscita; configura alert quando queste risorse si avvicinano a un livello che degrada l'azione dell'utente.

Il rischio principale di modifica è che le chiavi di configurazione, le migration del database di autenticazione e le aspettative dei client devono essere verificate prima di aggiornare ntfy. Un rilascio sicuro parte da uno snapshot ripristinabile e convalida qualsiasi modifica di stato unidirezionale prima di spostare il traffico. Quando la cache è effimera oppure le connessioni WebSocket/SSE vanno in timeout sul proxy, conserva il container che ha fallito abbastanza a lungo da leggerne la configurazione e il primo errore.

Il gate di rilascio di ntfy

Un release candidate di ntfy si guadagna il traffico completando uno scenario fisso: pubblicare un messaggio con curl, riceverlo tramite subscription HTTP e WebSocket, allegare un file e testare un topic autenticato. Registra il digest dell'immagine, la configurazione effettiva non segreta, l'origine pubblica e i timestamp dello scenario. I dati di test devono essere eliminabili, ma abbastanza realistici da esercitare lo stesso percorso degli utenti.

Eseguilo dopo aver sostituito il runtime, quindi ricostruisci il servizio a partire da configurazione, database di autenticazione e allegati che devono sopravvivere. Il ripristino ha esito positivo quando utenti, ACL, configurazione e allegati conservati vengono recuperati e un subscriber autenticato riceve un nuovo messaggio. Confronta le misurazioni delle risorse relative a connessioni persistenti dei subscriber, dimensione degli allegati, retention della cache e relay push in uscita con quelle del rilascio precedente e analizza qualsiasi variazione significativa prima della promozione.

Infine, esegui questo errore controllato: invia un input innocuo vicino al limite di risorse o di formato associato a questo perimetro: la cache è effimera oppure le connessioni WebSocket/SSE vanno in timeout sul proxy. Verifica che ntfy spieghi l'errore, non danneggi lo stato esistente e riprenda a funzionare quando torna una condizione valida. Salva un estratto del log con i dati sensibili rimossi e il tempo di ripristino. Nel complesso, questi controlli coprono comportamento, durabilità e operatività, non solo l'uptime del processo.

Mantieni ntfy esplicito mentre Dockup gestisce il routing

Routing, certificati, sostituzione dei servizi e storage collegato sono obiettivi ragionevoli per l'automazione. Dockup li gestisce per ntfy e può effettuare il provisioning del database gestito correlato oppure collegarsi ai servizi sul server del cliente.

Quello che non dovrebbe inventare è la policy di trust di ntfy. Dopo il deployment, imposta base-url sull'origine HTTPS pubblica utilizzata da publisher e subscriber, applica questo perimetro — usa le ACL dei topic, perché nomi di topic non indovinabili non costituiscono una vera autorizzazione per i messaggi operativi — e verifica il risultato di questo scenario: pubblica un messaggio con curl, ricevilo tramite subscription HTTP e WebSocket, allega un file e testa un topic autenticato. Il risultato è un'infrastruttura one-click con un acceptance test specifico per l'applicazione.

Domande frequenti

Di cosa ha bisogno ntfy per un deployment in produzione?

Instrada il container ntfy sulla porta 80 attraverso un'unica origine HTTPS. Il requisito del runtime locale è un volume per la configurazione e, facoltativamente, un database di autenticazione. Non considerare ntfy pronto finché non puoi pubblicare un messaggio con curl, riceverlo tramite subscription HTTP e WebSocket, allegare un file e testare un topic autenticato.

Quali dati di ntfy devono essere inclusi in un backup?

Rendi persistente /var/cache/ntfy e includi nello stesso manifest di ripristino la configurazione, il database di autenticazione e gli allegati che devono sopravvivere. Un restore pulito di ntfy ha esito positivo solo quando utenti, ACL, configurazione e allegati conservati vengono recuperati e un subscriber autenticato riceve un nuovo messaggio.

ntfy richiede HTTPS dietro un reverse proxy?

Usa HTTPS per l'origine pubblica di ntfy e mantieni la porta 80 sulla route interna. Applica correttamente l'impostazione di ntfy: imposta base-url sull'origine HTTPS pubblica utilizzata da publisher e subscriber. Per ntfy, HTTPS protegge le credenziali o i contenuti degli utenti durante il transito e mantiene coerente il comportamento dei client sensibile all'origine.

Come deve essere testato un upgrade di ntfy?

Ripristina lo stato attuale di ntfy in un deployment isolato, applica la versione candidata e ripeti la relativa transazione di acceptance. Presta particolare attenzione perché le chiavi di configurazione, le migration del database di autenticazione e le aspettative dei client devono essere verificate prima di aggiornare ntfy. Conserva la precedente immagine di ntfy finché non avrai compreso i limiti della migrazione dei dati e del rollback.