ntfy 2.24 en pymes: alertas, ACL y prueba de entrega
ntfy permite enviar alertas por HTTP desde backups, monitoreo y scripts. Qué configurar para que cada aviso tenga tópico, permiso y prueba de recepción.
La alerta de backup falla cuando llega al celular correcto y nadie puede explicar quién tenía permiso para verla. ntfy 2.24, publicado el 4 de junio, permite enviar avisos por HTTP, tópicos y prioridades desde scripts, monitoreo o aplicaciones internas. Para una pyme, el trabajo serio queda en ACL, tokens, cache y prueba de entrega; esta guía muestra dónde vive cada dato y cómo revisar el corte. ## Dónde aparece la alerta sin responsable Las notas de ntfy 2.24 dicen que la versión estable salió el 4 de junio e incorporó cache de ACL en memoria, apagada por defecto, para bajar consultas a la base de autorización en servidores de alto volumen. También corrigió coincidencias de tópicos en SQLite: una regla para secret ya no debe cubrir SECRET. Ese detalle convierte una alerta simple en una decisión de permisos. La documentación de envío de mensajes separa título, prioridad, etiquetas, adjuntos, acciones y autenticación. Hay cinco niveles de prioridad. La cifra global queda cerca: GitHub Octoverse registró un desarrollador nuevo por segundo y más proyectos automatizados; cada script que corre solo necesita avisar con dueño, no gritar en un canal común. El grupo de guardia sin dueño es el antagonista. En una escuela técnica del este provincial, el objeto que marcaba la escena era un teléfono viejo enchufado junto al router del laboratorio, con tres aplicaciones de mensajería abiertas. Los avisos llegaban, pero soporte no podía distinguir backup correcto, backup vencido, corte de energía y reinicio de servidor. ntfy ordena ese flujo si cada tópico tiene permisos propios.
Cómo funciona por dentro
El flujo empieza cuando un script de backup, Uptime Kuma, Prometheus Alertmanager o una aplicación de turnos hace un POST a un tópico. ntfy recibe mensaje, título, prioridad, token y adjunto si corresponde. El servidor valida usuario, tópico y regla de lectura o escritura. El cache guarda mensajes durante el período definido; la base de autenticación guarda usuarios, tokens, permisos y auditoría de acceso. PostgreSQL puede guardar inventario operativo, servicios, responsables y ventanas de mantenimiento fuera de ntfy. ntfy entrega la notificación a web, escritorio o móvil. Keycloak o el directorio interno administra identidades cuando se centraliza el login; ntfy usa sus propios usuarios y tokens si se instala de forma simple. Un tablero toma eventos aceptados y muestra servicio, responsable, prioridad, entrega y acuse manual. El backup copia configuración de ntfy, base de usuarios, tokens, reglas, cache si se conserva historial y documentación de tópicos. La prueba restaura el servidor, publica una alerta de backup, comprueba entrega en dos clientes y revoca un token para verificar que el aviso deje de salir. La instalación oficial permite usar binario, paquete o contenedor. La configuración define base URL, cache, autenticación, límites y web push. La API de GitHub confirma el release v2.24.0 publicado el 4 de junio. La parte técnica conviene escribirla antes de sumar servicios.
Qué se instala o configura primero
La pila mínima usa ntfy 2.24, proxy HTTPS, autenticación, tópicos por servicio, tokens por emisor, archivo de configuración, backup y monitoreo. Para pymes con 20 a 80 servicios, el costo mensual queda entre USD 45 y USD 140 si incluye servidor, dominio, TLS, copia externa y alerta de disponibilidad. Con dólar vendedor oficial de ARS 1.462, el rango va de ARS 65.790 a ARS 204.680. La implementación inicial lleva 18 a 35 horas: instalación, tópicos, usuarios, tokens, reglas de lectura y escritura, pruebas móviles, registro de servicios y restauración. El primer entregable verificable es una alerta de backup que muestre tópico, prioridad, emisor, destinatario, hora, entrega y revocación de token. UMSA puede ordenar el piloto sobre pocos avisos: backup, caída de enlace, certificado TLS y cola de tareas. La pyme conserva sus scripts; ntfy entrega el aviso con tópico y permiso. La documentación debe listar servicio, emisor, tópico, responsable, prioridad, horario de silencio y prueba mensual. El costo incluye servidor, copias, dominio, TLS, monitoreo y una matriz de permisos. La operación diaria sigue dependiendo de que cada responsable confirme recepción y cierre. Esa confirmación puede vivir en GLPI, Zammad o una planilla controlada, según tamaño del equipo.
Dónde se rompe y cómo probarlo
El primer riesgo es el tópico público. La señal aparece cuando una URL de tópico alcanza para leer o publicar. La prueba crea un tópico privado, intenta publicar sin token y exige rechazo. El segundo riesgo es el token amplio. La señal aparece cuando un emisor de backup puede publicar alertas de facturación o leer avisos de soporte. La prueba crea tokens por servicio y revisa lectura, escritura y revocación. El tercer riesgo es la prioridad inflada. La señal aparece cuando todo llega como urgente y nadie distingue una caída real. La prueba envía prioridades 1 a 5 y verifica sonido, vista y escalamiento. El cuarto riesgo es la restauración sin reglas. La señal aparece cuando vuelve el servidor, pero los tópicos quedan abiertos. La prueba restaura configuración, base y cache; después publica con un token revocado y comprueba rechazo. El quinto riesgo es el adjunto sensible. La señal aparece cuando el aviso incluye logs con contraseñas o documentos. La prueba envía valores señuelo y exige que el script filtre antes de publicar. Una alerta útil deja tres pruebas: quién la emitió, quién podía leerla y qué pasó después.
Para seguir leyendo
Para avanzar
Ver también
Continuá hacia capacidades técnicas, sectores o notas relacionadas.