Alojar ntfy en un VPS: notificaciones push para sus scripts

Uptime Kuma vigila sus servicios, Beszel vigila las métricas de su VPS, Backrest gestiona sus copias de seguridad, y sus cron jobs callan por la noche — salvo cuando fallan. Cada uno tiene su canal de notificación: Slack, correo, webhook, Telegram. Resultado: cinco integraciones distintas que mantener, cinco tipos de alerta que formatear y ninguna vista unificada cuando algo falla a las 03:00. ntfy resuelve el problema al revés: es usted quien aloja el hub de notificaciones, y cada herramienta o script le envía sus alertas por HTTP puro.

ntfy es un binario Go que cabe en un único contenedor Docker. Expone una interfaz HTTP sencilla: un PUT o un POST sobre /su-topic publica un mensaje; cualquier cliente que escuche ese topic lo recibe al instante. Los mensajes se guardan en caché en SQLite con una retención configurable (12 horas por defecto). En producción, ntfy se coloca detrás de un proxy inverso nginx que gestiona el TLS — behind-proxy: true en server.yml indica a ntfy que lea la IP real desde X-Forwarded-For. Toda la configuración avanzada vive en un único archivo /etc/ntfy/server.yml.

Sin configuración, ntfy arranca sin control de acceso (la doc indica auth-default-access en read-write) — cualquiera que conozca la URL puede leer y escribir. En producción: auth-default-access: deny-all cierra el servidor; usuarios con contraseñas bcrypt en user.db; tokens de acceso vinculados a un usuario específico y revocables de forma independiente. Un token comprometido se revoca sin cambiar la contraseña del usuario.

Cree un usuario por servicio o equipo, concédale derechos solo sobre sus topics, y cada servicio creerá tener su propio hub. El rol admin ve todo; los usuarios normales están limitados a sus ACL. Para equipos con aislamiento total, despliegue dos contenedores ntfy en dos subdominios distintos.

1. HTTP 403 Forbidden al publicar o suscribirse
Mensaje: {"code":40301,"http":403,"error":"Unauthorized"}
Causa: auth-default-access: deny-all activo y el token falta o ha caducado. Regenere el token con ntfy token add <usuario> y actualice sus scripts.

2. Notificación enviada pero nunca recibida en el móvil
En Android, compruebe primero que la app está suscrita a su instancia y no al servidor público ntfy.sh (URL en los ajustes de la app). En iOS, la causa más probable es la ausencia de upstream-base-url: "https://ntfy.sh" en server.yml: sin ese relé, la doc advierte de que la entrega puede tardar horas. Configúrelo y repase la checklist de la sección iOS más abajo. base-url también debe estar definido, pero la doc lo asocia a las URL de adjuntos y al pie de los correos, no a la llegada del push.

3. Enlaces incorrectos en los correos salientes
Sin base-url, el pie del correo (enlace a la notificación) se construye sin la URL pública y no sirve desde el exterior. Solución: establecer base-url: https://ntfy.ejemplo.com y reiniciar el contenedor.

4. Caídas repetidas de WebSocket en producción (reconexiones cada 30 s)
Causa: el timeout keepalive de nginx es inferior al intervalo de heartbeat de ntfy (keepalive-interval: "45s" en la configuración de ejemplo de la doc). Añada proxy_read_timeout 60; y proxy_send_timeout 60; al bloque location. Verifique también proxy_http_version 1.1; y proxy_set_header Upgrade $http_upgrade;.

5. OOM (Out of Memory) en un topic de alto volumen
Reduzca cache-duration a 1h o 30m. Filtre en el script (| grep -E 'ERROR|WARN') para enviar solo eventos relevantes. ntfy puede usar PostgreSQL en lugar de SQLite para sus almacenes (vea la doc de configuración).

En iOS una app no puede mantener una conexión abierta en segundo plano: la documentación de ntfy explica que esta restricción hace imposible un push instantáneo sin un servidor central. Su servidor autoalojado reenvía por tanto, por cada mensaje, una petición de «poll» a un servidor ascendente, ntfy.sh por defecto, que se encarga de despertar la app. El ajuste es upstream-base-url: "https://ntfy.sh". Esa petición solo contiene el identificador del mensaje (cabecera X-Poll-ID) y el hash SHA-256 de la URL del topic, nunca el texto: el servidor autoalojado envía literalmente «New message» y la app va a buscar el contenido real a su servidor. Sin upstream-base-url, la documentación advierte de que las notificaciones acaban llegando, pero la entrega puede tardar horas (20 a 30 minutos si el teléfono se usa activamente). upstream-access-token es opcional: la doc solo lo reserva para cuando se superan los límites del servidor ascendente o este está protegido.

Estas dos issues del repositorio de ntfy describen el síntoma que busca: un servidor autoalojado, un push iOS que no aparece, mensajes que solo aparecen al refrescar la app a mano. Leídas el 30 de octubre de 2026, ambas están abiertas y ninguna señala una causa confirmada.

#1305 «No push notifications on ios?» (abierta en marzo de 2025, etiquetas ios y bug). El autor no recibe ningún aviso, ni con ntfy.sh ni con su propia instancia. Algunos comentarios dicen que reinstalar la app ayudó, otros que el problema volvió meses después. Un colaborador propone que la app se reabone a los topics de Firebase al arrancar y abrió una PR en borrador, precisando que no pudo probarla. Un mantenedor pregunta al autor si la suscripción de Firebase es la causa, sin concluir.

#1844 «No iOS Push notification, also with valid subscription» (abierta en julio de 2026, etiquetas ios, server y bug). El autor ejecuta ntfy en Docker con NTFY_UPSTREAM_BASE_URL en https://ntfy.sh y NTFY_UPSTREAM_ACCESS_TOKEN informado. Dice haber alcanzado el límite gratuito de 250 mensajes al día y haber contratado después una suscripción de pago. Sus registros muestran el mensaje publicado y enviado al relé, y aun así ningún push. Un colaborador responde que los errores 429 pueden suponer un bloqueo de IP de hasta 4 horas, constata que la prueba con curl del autor funciona (por tanto no hay bloqueo) y que la cuenta mostraba 48 mensajes enviados de 2 500. Añade que las notificaciones iOS son caprichosas sin que se sepa exactamente por qué. Solución alternativa comunicada: desactivar y volver a activar «Actualización en segundo plano» y «Notificaciones» en los ajustes de iOS. El autor escribe que no sabe por qué funciona; el problema volvió, luego desapareció sin causa conocida, y otro usuario confirma la solución en septiembre de 2026. Otro informe relaciona un caso parecido con listas de bloqueo DNS.

Lo que se puede concluir y lo que no. Ni un límite diario de mensajes ni un bloqueo 429 quedan establecidos como causa en estos hilos: el 429 se descarta para la IP del autor, y el límite de 250 mensajes es una cifra dada por él, no por la documentación de configuración. El token ascendente no resuelve ahí el problema. Trate la lista anterior como comprobaciones, no como una corrección garantizada.

Backrest soporta ntfy de forma nativa: configure la URL del topic y el token Bearer en la UI de Backrest, y cada snapshot completada o fallida genera automáticamente una notificación push con el nombre de la snapshot, el tamaño deduplicado y la duración. Cero scripts, cero cron.

Uptime Kuma soporta ntfy de forma nativa en su gestor de notificaciones. Cada monitor puede tener múltiples canales — combine ntfy para el push móvil y el SMTP de ntfy para la trazabilidad.

Grafana usa webhooks genéricos. Cree un contact point de tipo webhook, apúntelo a https://ntfy.ejemplo.com/grafana, añada las cabeceras Authorization: Bearer tk_... y Content-Type: text/plain.