Cómo alojar Uptime Kuma por tu cuenta en 2026: alertas, TLS y datos persistentes

La mayoría de las notas de instalación de Uptime Kuma terminan en la primera carga de la página. Es demasiado pronto: el volumen de datos puede ser de solo lectura o el DNS del contenedor no puede resolver los hosts monitorizados. Una prueba útil en producción es más exigente: crear monitores HTTP y TCP, provocar un fallo controlado y recibir la alerta y el aviso de recuperación a través del proveedor elegido.

El papel de Uptime Kuma es sencillo: monitorizar servicios existentes y enviar alertas a más de 90 destinos. Su ámbito operativo incluye más que el proceso web, por lo que la dependencia, el estado almacenado y la ruta pública deben especificarse antes de que lleguen datos reales.

Define primero el éxito de Uptime Kuma

Un diagrama útil de Uptime Kuma muestra la ruta pública, el puerto privado 3001, el límite del estado y todos los requisitos de soporte. Indica qué flechas transportan credenciales y cuáles corresponden al tráfico normal de los usuarios. El requisito externo de Uptime Kuma es tener acceso saliente a cada endpoint monitorizado y proveedor de alertas. Prueba el DNS saliente, TLS y el comportamiento del proveedor sin publicar otro servicio entrante.

Demuestra el diagrama con una acción real: crea monitores HTTP y TCP, provoca un fallo controlado y recibe la alerta y el aviso de recuperación a través del proveedor elegido. La presión probablemente vendrá del intervalo de monitorización, el número de reintentos, el tráfico de la página de estado y la cantidad de probes salientes realizados en el mismo segundo; monitoriza esa ruta en lugar de tratar todas las solicitudes HTTP como equivalentes.

Opera Uptime Kuma teniendo en cuenta su cuello de botella real

La primera métrica operativa útil de Uptime Kuma es comprobar si puede crear monitores HTTP y TCP, provocar un fallo controlado y recibir la alerta y el aviso de recuperación a través del proveedor elegido. Combínala con señales de saturación del intervalo de monitorización, el número de reintentos, el tráfico de la página de estado y la cantidad de probes salientes realizados en el mismo segundo. Un probe que compruebe solo el proceso no debería llamar a dependencias costosas ni reiniciar el contenedor porque un upstream no esté disponible temporalmente.

Trata las actualizaciones como cambios de datos, porque las migraciones de SQLite y los cambios en los proveedores de notificaciones pueden convertir un simple pull de una imagen en una actualización de una aplicación con estado. Fija las versiones, ensaya el proceso con un estado restaurado y conserva la imagen anterior hasta que el rollback siga siendo válido. Cuando el volumen de datos sea de solo lectura o el DNS del contenedor no pueda resolver los hosts monitorizados, conserva los logs anteriores al reinicio; normalmente contienen el mensaje causal.

Registra un deployment de Uptime Kuma conocido y correcto

En Uptime Kuma, define una transacción conocida y correcta antes del lanzamiento: crea monitores HTTP y TCP, provoca un fallo controlado y recibe la alerta y el aviso de recuperación a través del proveedor elegido. Guarda sus prerrequisitos, la respuesta esperada y los pasos de limpieza en el control de versiones, sin valores secretos. Fija la imagen utilizada para establecer esa referencia.

Usa la transacción para validar un reemplazo y una restauración independiente. El servicio restaurado solo será aceptable cuando vuelvan a aparecer el historial de los monitores, las credenciales de notificación y las ventanas de mantenimiento, y una alerta de prueba siga entregándose. Al mismo tiempo, observa el intervalo de monitorización, el número de reintentos, el tráfico de la página de estado y la cantidad de probes salientes realizados en el mismo segundo, y convierte la parte más lenta o limitada en una alerta de nivel de servicio.

El proceso de validación también necesita un caso negativo: deniega temporalmente la ruta de prueba utilizada para el acceso saliente a cada endpoint monitorizado y proveedor de alertas. Confirma que Uptime Kuma genera un error accionable y conserva los datos, restablece la condición válida y repite la transacción conocida y correcta. Conservar ambos resultados evita que un endpoint de health superficial se convierta en la única evidencia en producción.

Configuración del contenedor que conviene revisar

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

docker run -d \
  --name uptime-kuma \
  --restart unless-stopped \
  -p 127.0.0.1:3001:3001 \
  -v uptime-kuma-data:/app/data \
  -e UPTIME_KUMA_PORT=3001 \
  louislam/uptime-kuma:1

Permite y verifica la ruta saliente o del lado del cliente necesaria para acceder a cada endpoint monitorizado y proveedor de alertas. Inspecciona el usuario del contenedor, las rutas con permisos de escritura y el listener enlazado antes de exponerlo. Ejecuta la acción completa —crear monitores HTTP y TCP, provocar un fallo controlado y recibir la alerta y el aviso de recuperación a través del proveedor elegido— y guarda la referencia exacta de la imagen que produjo el resultado.

Restaura Uptime Kuma en un host vacío

Protege el estado de Uptime Kuma antes de optimizar su contenedor. El conjunto necesario incluye la base de datos SQLite y los assets subidos en /app/data. Monta /app/data antes del bootstrap, escribe datos de muestra inofensivos y reemplaza el contenedor para demostrar que esa ruta es realmente persistente. Si varias ubicaciones de almacenamiento deben mantenerse sincronizadas, documenta el orden en que se pausan las escrituras y se realizan las copias de seguridad.

Conserva copias fuera del servidor de deployment y cifra el material que contenga credenciales o contenido privado. La recuperación tiene éxito cuando vuelven a aparecer el historial de los monitores, las credenciales de notificación y las ventanas de mantenimiento, y una alerta de prueba sigue entregándose. La diferencia entre un mount persistente y una copia independiente se explica en almacenamiento persistente y snapshots.

Asigna a Uptime Kuma una dirección canónica

Publica un único origen HTTPS estable a través del reverse proxy. Envía el hostname elegido al puerto 3001 del contenedor, reenvía el host original y el esquema HTTPS, y evita publicar un segundo origen directo.

Prueba Uptime Kuma desde un cliente externo limpio. Separa un fallo de ingress del límite conocido de la aplicación: el volumen de datos es de solo lectura o el DNS del contenedor no puede resolver los hosts monitorizados. Un error de certificado, DNS o 502 pertenece al routing; una solicitud que llega a Uptime Kuma 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.

Decisiones de seguridad específicas de Uptime Kuma

El riesgo de seguridad específico de la aplicación consiste en ejecutar la configuración del primer usuario en una instancia expuesta públicamente. La respuesta operativa es completar la configuración del primer usuario de forma privada y proteger después por separado los dashboards y la administración de la página de estado. Completa el bootstrap mediante una ruta restringida y elimina inmediatamente después el acceso temporal de configuración.

UPTIME_KUMA_PORT controla el comportamiento, no la confidencialidad; valida su tipo y valor, y almacena por separado las credenciales reales de Uptime Kuma. Concede al proceso de Uptime Kuma únicamente sus mounts documentados y las rutas hacia sus dependencias; evita el acceso al root del host y al socket de Docker. Registra los fallos de autenticación y los errores de configuración, pero redacta los tokens, las connection strings y el contenido de los usuarios.

Un deployment de Dockup también necesita una prueba de aceptación de Uptime Kuma

El routing, los certificados, el reemplazo del servicio y el almacenamiento asociado son objetivos razonables para la automatización. Dockup se ocupa de ellos para Uptime Kuma y puede aprovisionar la base de datos gestionada relacionada o conectarse a servicios del servidor del propio cliente.

Lo que no debería inventar es la trust policy de Uptime Kuma. Después del deployment, publica un único origen HTTPS estable a través del reverse proxy, aplica este límite —completa la configuración del primer usuario de forma privada y protege después por separado los dashboards y la administración de la página de estado— y verifica el resultado de este escenario: crea monitores HTTP y TCP, provoca un fallo controlado y recibe la alerta y el aviso de recuperación a través del proveedor elegido. El resultado es una infraestructura one-click con una prueba de aceptación específica de la aplicación.

Preguntas frecuentes

¿Qué necesita Uptime Kuma para un deployment en producción?

Dirige el contenedor de Uptime Kuma en el puerto 3001 mediante un único origen HTTPS. El requisito externo de entrega es tener acceso saliente a cada endpoint monitorizado y proveedor de alertas. No des por listo Uptime Kuma hasta que puedas crear monitores HTTP y TCP, provocar un fallo controlado y recibir la alerta y el aviso de recuperación a través del proveedor elegido.

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

Haz persistir /app/data e incluye la base de datos SQLite y los assets subidos en /app/data en el mismo manifest de recuperación. Una restauración limpia de Uptime Kuma solo es válida cuando vuelven a aparecer el historial de los monitores, las credenciales de notificación y las ventanas de mantenimiento, y una alerta de prueba sigue entregándose.

¿Uptime Kuma necesita HTTPS detrás de un reverse proxy?

Usa HTTPS para el origen público de Uptime Kuma y mantén el puerto 3001 en la ruta interna. Aplica correctamente la configuración de Uptime Kuma: publica un único origen HTTPS estable a través del reverse proxy. En Uptime Kuma, HTTPS protege las credenciales o el contenido de los usuarios durante el tránsito y mantiene coherente el comportamiento del cliente sensible al origen.

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

Restaura el estado actual de Uptime Kuma en un deployment aislado, aplica la versión candidata y repite su transacción de aceptación. Presta especial atención, porque las migraciones de SQLite y los cambios en los proveedores de notificaciones pueden convertir un simple pull de una imagen en una actualización de una aplicación con estado. Conserva la imagen anterior de Uptime Kuma hasta comprender los límites de la migración de datos y del rollback.