Comment auto-héberger ntfy en 2026 : topics, contrôle d’accès et distribution

La plupart des notes d’installation de ntfy s’arrêtent au premier chargement de la page. C’est trop tôt : le cache est éphémère ou les connexions WebSocket/SSE expirent au niveau du proxy. Un test de production utile est plus exigeant : publier un message avec curl, le recevoir via des abonnements HTTP et WebSocket, joindre un fichier et tester un topic authentifié.

Le rôle de ntfy est simple : envoyer des notifications push au moyen d’une simple requête HTTP. Son périmètre opérationnel ne se limite pas au processus web ; la dépendance, l’état stocké et la route publique doivent donc tous être explicitement identifiés avant l’arrivée de données réelles.

L’architecture de ntfy en production

Le processus HTTP de ntfy écoute sur le port 80 ; conservez ce port sur le réseau applicatif et ne publiez que la route de la plateforme. L’exigence locale d’exécution est un volume de configuration et une base d’authentification facultative. Testez ce périmètre avant la publication, puis de nouveau après le remplacement d’un container.

Consignez ce périmètre sous la forme d’un court contrat : qui est responsable de l’exigence, quel identifiant est utilisé, quel délai d’attente est acceptable et comment l’échec se manifeste. Exécutez ensuite cette transaction : publier un message avec curl, le recevoir via des abonnements HTTP et WebSocket, joindre un fichier et tester un topic authentifié. Observez les connexions d’abonnés de longue durée, la taille des pièces jointes, la rétention du cache et les relais push sortants pendant l’exécution, car cette charge fournit une base de dimensionnement plus pertinente qu’un container inactif.

Démarrer ntfy sans masquer les éléments importants

Utilisez le container comme un runtime remplaçable, et non comme la source de vérité.

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

Vérifiez l’exigence locale avant toute exposition : un volume de configuration et une base d’authentification facultative. Inspectez l’utilisateur du container, les chemins accessibles en écriture et le listener associé avant de l’exposer. Exécutez l’action complète — publier un message avec curl, le recevoir via des abonnements HTTP et WebSocket, joindre un fichier et tester un topic authentifié —, puis enregistrez la référence exacte de l’image à l’origine du résultat.

Attribuer à ntfy une adresse canonique

Définissez base-url sur l’origine HTTPS publique utilisée par les publishers et les abonnés. Dirigez le hostname choisi vers le port 80 du container, transmettez le host d’origine et le schéma HTTPS, et évitez de publier une seconde origine directe.

Testez ntfy depuis un client externe vierge. Distinguez une défaillance de l’ingress du périmètre applicatif connu — le cache est éphémère ou les connexions WebSocket/SSE expirent au niveau du proxy. Une erreur de certificat, de DNS ou de type 502 relève du routage ; une requête qui atteint ntfy puis échoue relève de l’état applicatif, de la capacité ou de l’exigence dont il dépend. Le guide TLS pour domaine personnalisé couvre le premier groupe.

Vérifier que ntfy survit au remplacement

Protégez l’état de ntfy avant d’optimiser son container. L’ensemble requis comprend la configuration, la base d’authentification et les pièces jointes qui doivent être conservées. Montez /var/cache/ntfy avant le bootstrap, écrivez des données d’exemple inoffensives et remplacez le container pour vérifier que ce chemin est réellement persistant. Si plusieurs stockages doivent rester cohérents, documentez l’ordre dans lequel les écritures sont suspendues et les sauvegardes effectuées.

Conservez des copies en dehors du serveur de déploiement et chiffrez les éléments contenant des identifiants ou du contenu privé. La récupération est réussie lorsque les utilisateurs, les ACL, la configuration et les pièces jointes conservées sont restaurés, et qu’un abonné authentifié reçoit un nouveau message. La distinction entre un montage persistant et une copie indépendante est expliquée dans stockage persistant et snapshots.

Ne donnez pas à ntfy un accès complet à l’hôte

Pour ntfy, la surface utile n’est pas nécessairement la landing page. L’erreur principale consiste à autoriser la devinette publique des topics lorsque les messages contiennent des informations opérationnelles. Répondez-y délibérément : utilisez des ACL par topic, car des noms de topic difficiles à deviner ne constituent pas une autorisation robuste pour les messages opérationnels.

NTFY_BASE_URL est une configuration, pas un secret ; gardez sa valeur explicite tout en protégeant les identifiants distincts utilisés par ntfy. Utilisez un utilisateur de container non privilégié lorsque l’image le permet et ne montez aucun identifiant sans rapport. Appliquez les limites de débit ou de taille au niveau de l’ingress, là où des requêtes non fiables peuvent consommer des connexions d’abonnés de longue durée, la taille des pièces jointes, la rétention du cache et les relais push sortants.

Mettre à niveau ntfy sans avancer à l’aveugle

Utilisez la séquence « publier un message avec curl, le recevoir via des abonnements HTTP et WebSocket, joindre un fichier et tester un topic authentifié » comme smoke test ntfy après chaque déploiement. Les métriques associées sont les connexions d’abonnés de longue durée, la taille des pièces jointes, la rétention du cache et les relais push sortants ; déclenchez des alertes lorsque ces ressources approchent un niveau susceptible de dégrader l’action utilisateur.

Le principal risque lié aux changements vient du fait que les clés de configuration, les migrations de la base d’authentification et les attentes des clients doivent être vérifiées avant la mise à jour de ntfy. Une release sûre part d’un snapshot restaurable et valide toute modification d’état irréversible avant de faire transiter le trafic. Lorsque le cache est éphémère ou que les connexions WebSocket/SSE expirent au niveau du proxy, conservez le container défaillant suffisamment longtemps pour lire sa configuration et sa première erreur.

La release gate de ntfy

Une release candidate de ntfy mérite de recevoir du trafic après avoir exécuté un scénario fixe : publier un message avec curl, le recevoir via des abonnements HTTP et WebSocket, joindre un fichier et tester un topic authentifié. Capturez le digest de l’image, la configuration effective non secrète, l’origine publique et les horodatages associés à ce scénario. Les données de test doivent être jetables, mais suffisamment réalistes pour emprunter le même chemin que les utilisateurs.

Exécutez ce scénario après avoir remplacé le runtime, puis reconstruisez le service à partir de la configuration, de la base d’authentification et des pièces jointes qui doivent être conservées. La récupération est réussie lorsque les utilisateurs, les ACL, la configuration et les pièces jointes conservées sont restaurés, et qu’un abonné authentifié reçoit un nouveau message. Comparez les mesures de ressources — connexions d’abonnés de longue durée, taille des pièces jointes, rétention du cache et relais push sortants — avec celles de la release précédente et analysez tout écart significatif avant la promotion.

Enfin, provoquez cet échec contrôlé : envoyez une entrée inoffensive proche de la limite de ressource ou de format associée à ce périmètre : le cache est éphémère ou les connexions WebSocket/SSE expirent au niveau du proxy. Vérifiez que ntfy explique l’échec, n’endommage pas l’état existant et reprend son fonctionnement lorsque la condition valide est rétablie. Conservez un extrait de log expurgé et le temps de récupération. Ensemble, ces vérifications couvrent le comportement, la durabilité et l’exploitabilité, plutôt que la seule disponibilité du processus.

Garder ntfy explicite pendant que Dockup gère le routage

Le routage, les certificats, le remplacement du service et le stockage associé sont de bonnes cibles pour l’automatisation. Dockup les gère pour ntfy et peut provisionner la base de données managée associée ou se connecter aux services présents sur le serveur d’un client.

Ce qu’il ne doit pas inventer, c’est la politique de confiance de ntfy. Après le déploiement, définissez base-url sur l’origine HTTPS publique utilisée par les publishers et les abonnés, imposez ce périmètre — utilisez des ACL par topic, car des noms de topic difficiles à deviner ne constituent pas une autorisation robuste pour les messages opérationnels — et vérifiez le résultat de ce scénario : publier un message avec curl, le recevoir via des abonnements HTTP et WebSocket, joindre un fichier et tester un topic authentifié. Le résultat est une infrastructure déployée en un clic, avec un test d’acceptation spécifique à l’application.

Foire aux questions

De quoi ntfy a-t-il besoin pour un déploiement en production ?

Acheminez le container ntfy sur le port 80 via une seule origine HTTPS. L’exigence locale d’exécution est un volume de configuration et une base d’authentification facultative. Ne considérez pas ntfy comme prêt tant que vous ne pouvez pas publier un message avec curl, le recevoir via des abonnements HTTP et WebSocket, joindre un fichier et tester un topic authentifié.

Quelles données de ntfy doivent être sauvegardées ?

Rendez /var/cache/ntfy persistant et incluez la configuration, la base d’authentification et les pièces jointes qui doivent être conservées dans le même manifeste de récupération. Une restauration propre de ntfy n’est réussie que lorsque les utilisateurs, les ACL, la configuration et les pièces jointes conservées sont restaurés, et qu’un abonné authentifié reçoit un nouveau message.

ntfy a-t-il besoin de HTTPS derrière un reverse proxy ?

Utilisez HTTPS pour l’origine publique de ntfy et conservez le port 80 sur la route interne. Appliquez correctement le paramètre ntfy : définissez base-url sur l’origine HTTPS publique utilisée par les publishers et les abonnés. Pour ntfy, HTTPS protège les identifiants ou le contenu utilisateur pendant leur transit et garantit un comportement cohérent des clients dépendant de l’origine.

Comment tester une mise à niveau de ntfy ?

Restaurez l’état actuel de ntfy dans un déploiement isolé, appliquez la version candidate et répétez sa transaction d’acceptation. Soyez particulièrement attentif, car les clés de configuration, les migrations de la base d’authentification et les attentes des clients doivent être vérifiées avant la mise à jour de ntfy. Conservez l’image ntfy précédente jusqu’à ce que les limites de migration des données et de rollback soient comprises.