Cómo alojar ntfy por tu cuenta en 2026: topics, control de acceso y entrega

La mayoría de las notas de instalación de ntfy terminan cuando se carga la primera página. Es demasiado pronto: la caché es efímera o las conexiones WebSocket/SSE expiran en el proxy. Una prueba de producción útil es más exigente: publicar un mensaje con curl, recibirlo mediante suscripciones HTTP y WebSocket, adjuntar un archivo y probar un topic autenticado.

La función de ntfy es sencilla: enviar notificaciones push mediante una simple solicitud HTTP. Su perímetro operativo incluye más que el proceso web, por lo que hay que identificar explícitamente la dependencia, el estado almacenado y la ruta pública antes de que lleguen datos reales.

La configuración de ntfy en producción

El proceso HTTP de ntfy escucha en el puerto 80; mantén ese puerto en la red de la aplicación y publica únicamente la ruta de la plataforma. El requisito del runtime local es un volumen de configuración y, opcionalmente, una base de datos de autenticación. Prueba ese límite antes de publicar y de nuevo después de reemplazar un contenedor.

Deja el límite por escrito como un contrato breve: quién es responsable del requisito, qué credencial se utiliza, qué timeout es aceptable y cómo se manifiesta un fallo. Después ejecuta esta transacción: publica un mensaje con curl, recíbelo mediante suscripciones HTTP y WebSocket, adjunta un archivo y prueba un topic autenticado. Durante la ejecución, observa las conexiones de suscriptores de larga duración, el tamaño de los adjuntos, la retención de la caché y los relays de push salientes, porque esa carga proporciona un punto de partida más útil para dimensionar el servicio que un contenedor inactivo.

Inicia ntfy sin ocultar sus componentes

Usa el contenedor como un runtime reemplazable, no como la ubicación de la verdad.

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

Confirma el requisito local antes de exponer el servicio: un volumen de configuración y, opcionalmente, una base de datos de autenticación. Inspecciona el usuario del contenedor, las rutas con permisos de escritura y el listener enlazado antes de exponerlo. Ejecuta la acción completa —publicar un mensaje con curl, recibirlo mediante suscripciones HTTP y WebSocket, adjuntar un archivo y probar un topic autenticado— y guarda la referencia exacta de la imagen que produjo el resultado.

Dale a ntfy una única dirección canónica

Establece base-url en el origen HTTPS público que utilizan los publishers y suscriptores. Envía el hostname elegido al puerto 80 del contenedor, reenvía el host original y el esquema HTTPS, y evita publicar un segundo origen directo.

Prueba ntfy desde un cliente externo limpio. Separa los fallos de ingress del límite conocido de la aplicación: la caché es efímera o las conexiones WebSocket/SSE expiran en el proxy. Un error de certificado, DNS o 502 pertenece al routing; una solicitud que llega a ntfy y falla después pertenece al estado de la aplicación, a la capacidad o a uno de sus requisitos de soporte. La guía de TLS para dominios personalizados cubre el primer grupo.

Demuestra que ntfy sobrevive a un reemplazo

Protege el estado de ntfy antes de optimizar su contenedor. El conjunto necesario incluye la configuración, la base de datos de autenticación y los adjuntos que deban conservarse. Monta /var/cache/ntfy antes del bootstrap, escribe datos de ejemplo inocuos y reemplaza el contenedor para demostrar que esa ruta es realmente persistente. Si varios almacenes deben mantenerse sincronizados, documenta el orden en el que se pausan las escrituras y se realizan las copias de seguridad.

Conserva copias fuera del servidor de despliegue y cifra el material que contenga credenciales o contenido privado. La recuperación es correcta cuando vuelven los usuarios, las ACL, la configuración y los adjuntos retenidos, y un suscriptor autenticado recibe un mensaje nuevo. La diferencia entre un montaje persistente y una copia independiente se explica en almacenamiento persistente y snapshots.

No le des a ntfy acceso a todo el host

En ntfy, la superficie valiosa no tiene por qué ser la landing page. El error principal consiste en permitir que se adivinen públicamente los topics cuando los mensajes contienen detalles operativos. Contrarréstalo de forma deliberada: utiliza ACL para los topics, porque los nombres de topic difíciles de adivinar no constituyen una autorización sólida para mensajes operativos.

NTFY_BASE_URL es configuración, no un secreto; mantén su valor explícito y protege por separado las credenciales que utiliza ntfy. Usa un usuario de contenedor sin privilegios cuando la imagen lo permita y no montes credenciales que no estén relacionadas. Aplica límites de rate o de tamaño en el ingress, donde el trabajo no confiable puede consumir conexiones de suscriptores de larga duración, tamaño de adjuntos, retención de caché y relays de push salientes.

Actualiza ntfy sin hacer suposiciones

Utiliza publicar un mensaje con curl, recibirlo mediante suscripciones HTTP y WebSocket, adjuntar un archivo y probar un topic autenticado como smoke test de ntfy después de cada despliegue. Sus métricas de soporte son las conexiones de suscriptores de larga duración, el tamaño de los adjuntos, la retención de la caché y los relays de push salientes; configura alertas cuando esos recursos se acerquen a un punto que degrade la acción del usuario.

El principal riesgo del cambio es que hay que comprobar las claves de configuración, las migraciones de la base de datos de autenticación y las expectativas de los clientes antes de actualizar ntfy. Una release segura parte de un snapshot restaurable y valida cualquier cambio de estado unidireccional antes de transferir el tráfico. Cuando la caché es efímera o las conexiones WebSocket/SSE expiran en el proxy, conserva el contenedor fallido el tiempo suficiente para leer su configuración y el primer error.

El gate de release de ntfy

Una release candidate de ntfy se gana el tráfico al completar un escenario fijo: publicar un mensaje con curl, recibirlo mediante suscripciones HTTP y WebSocket, adjuntar un archivo y probar un topic autenticado. Captura el digest de la imagen, la configuración efectiva no secreta, el origen público y las marcas de tiempo de ese escenario. Los datos de prueba deben ser desechables, pero lo bastante realistas como para recorrer la misma ruta que utilizan los usuarios.

Ejecútalo después de reemplazar el runtime y, a continuación, reconstruye el servicio a partir de la configuración, la base de datos de autenticación y los adjuntos que deban conservarse. La recuperación es correcta cuando vuelven los usuarios, las ACL, la configuración y los adjuntos retenidos, y un suscriptor autenticado recibe un mensaje nuevo. Compara las mediciones de recursos de las conexiones de suscriptores de larga duración, el tamaño de los adjuntos, la retención de caché y los relays de push salientes con las de la release anterior, e investiga cualquier desviación significativa antes de promocionarla.

Por último, ejecuta este fallo controlado: envía una entrada inocua cercana al límite de recursos o formato asociado a este límite: la caché es efímera o las conexiones WebSocket/SSE expiran en el proxy. Verifica que ntfy explique el fallo, no dañe el estado existente y se recupere cuando vuelva a cumplirse la condición válida. Guarda un fragmento de log redactado y el tiempo de recuperación. En conjunto, estas comprobaciones cubren el comportamiento, la durabilidad y la operabilidad, no solo que el proceso siga activo.

Mantén ntfy explícito mientras Dockup gestiona el routing

El routing, los certificados, el reemplazo de servicios y el almacenamiento adjunto son objetivos razonables para la automatización. Dockup se encarga de ellos para ntfy y puede aprovisionar la base de datos gestionada relacionada o conectarse a servicios que se ejecuten en el servidor del cliente.

Lo que no debería inventar es la política de confianza de ntfy. Después del despliegue, establece base-url en el origen HTTPS público que utilizan los publishers y suscriptores, aplica este límite —utiliza ACL para los topics, porque los nombres de topic difíciles de adivinar no constituyen una autorización sólida para mensajes operativos— y verifica el resultado de este escenario: publicar un mensaje con curl, recibirlo mediante suscripciones HTTP y WebSocket, adjuntar un archivo y probar un topic autenticado. El resultado es una infraestructura de un clic con una prueba de aceptación específica de la aplicación.

Preguntas frecuentes

¿Qué necesita ntfy para un despliegue de producción?

Enruta el contenedor de ntfy en el puerto 80 a través de un único origen HTTPS. El requisito del runtime local es un volumen de configuración y, opcionalmente, una base de datos de autenticación. No consideres que ntfy está listo hasta que puedas publicar un mensaje con curl, recibirlo mediante suscripciones HTTP y WebSocket, adjuntar un archivo y probar un topic autenticado.

¿Qué datos de ntfy deben incluirse en una copia de seguridad?

Haz persistir /var/cache/ntfy e incluye en el mismo manifiesto de recuperación la configuración, la base de datos de autenticación y los adjuntos que deban conservarse. Una restauración limpia de ntfy solo es correcta cuando vuelven los usuarios, las ACL, la configuración y los adjuntos retenidos, y un suscriptor autenticado recibe un mensaje nuevo.

¿Necesita ntfy HTTPS detrás de un reverse proxy?

Usa HTTPS para el origen público de ntfy y mantén el puerto 80 en la ruta interna. Aplica correctamente la configuración de ntfy: establece base-url en el origen HTTPS público que utilizan los publishers y suscriptores. En ntfy, HTTPS protege las credenciales o el contenido de los usuarios durante el tránsito y mantiene coherente el comportamiento de los clientes sensible al origen.

¿Cómo se debe probar una actualización de ntfy?

Restaura el estado actual de ntfy en un despliegue aislado, aplica la versión candidata y repite su transacción de aceptación. Presta especial atención, porque hay que comprobar las claves de configuración, las migraciones de la base de datos de autenticación y las expectativas de los clientes antes de actualizar ntfy. Conserva la imagen anterior de ntfy hasta comprender los límites de la migración de datos y del rollback.