Requisitos de Uptime Kuma: qué tamaño de servidor y dónde ejecutarlo

Los requisitos de Uptime Kuma son pequeños, y dónde se ejecuta importa más que su tamaño. Un monitor que se cae junto con tus sitios no puede avisarte de que están caídos, así que empieza por la ubicación, luego dimensiona el servidor y configúralo en orden.

Dónde ejecutarlo

Sandstorm Media, una agencia de software, se topó con esto al pasar de UptimeRobot a Uptime Kuma. No quería el monitor cerca de sus propios servidores, así que contrató un servidor en la nube en otro país.

Pon Uptime Kuma en un servidor que no ejecute ninguno de los sitios, aplicaciones ni bases de datos que comprueba. Si el servidor de un sitio se queda sin memoria, un despliegue falla o una base de datos deja de responder, el monitor no caerá con él y seguirás recibiendo la alerta.

Uno de los mantenedores de Uptime Kuma pone el listón más alto: should not co-locate your uptime status page on the same infrastructure, datacenter or credit card. Si tus sitios ya funcionan en servidores VPS de DreamHost, un segundo servidor para Uptime Kuma comparte su centro de datos, porque el Centro de ayuda de DreamHost indica que todos los VPS se alojan en su centro de datos US East de Ashburn (Virginia). Además, va en la misma factura. Si tus sitios están alojados en otra empresa, queda totalmente fuera de su infraestructura. En cualquier caso, añadirás una comprobación externa en los pasos de configuración de más abajo, y esa comprobación te avisará si el centro de datos o el propio Uptime Kuma dejan de responder.

Qué tamaño de servidor necesita

Uptime Kuma no publica un mínimo. Su README pide Node.js 20.4 o posterior en instalaciones sin Docker y ahí se queda, y un usuario no encontró ninguna cifra de RAM ni de CPU en toda la documentación, así que lo medimos nosotros. Los días 21 y 22 de octubre de 2026 ejecutamos Uptime Kuma 2.5.6 en Docker a partir del propio compose.yaml del proyecto, con su base de datos SQLite predeterminada, en nuestra máquina de prueba con 2 vCPU y 4 GB (arm64), no en un servidor de DreamHost. Tiene las mismas características que Stack 4.

Sin monitores, usó unos 200 MiB de memoria. Después añadimos 200 monitores de sitios web con los valores predeterminados, una comprobación cada 60 segundos sin reintentos, y los 200 se crearon sin errores. Tras 15 minutos de comprobaciones, el contenedor usaba 237 MiB y el 0,45 % de la CPU, y la máquina aún tenía libres 3408 MB de sus 3904 MB. Nuestras comprobaciones apuntaban a una pequeña página de prueba dentro de la misma máquina, así que los sitios reales con HTTPS y redirecciones cuestan algo más. Fue una sola ejecución de 15 minutos, así que no dice nada sobre meses de historial.

Un usuario de GitHub midió unos 126 MiB para 200 comprobaciones en la versión 1, en un servidor del mismo tamaño, y otro usuario en el mismo hilo ejecutó unos 250 monitores en una beta de la versión 2 con menos de 400 MiB de media.

Lo que hay que vigilar es el disco: cada comprobación escribe un resultado, así que la base de datos crece según cuántos monitores tengas, con qué frecuencia comprueban y cuánto tiempo guardes el historial. En el servidor de DreamHost puedes conservar un año o guardarlo para siempre. El usuario que calculó 9 GB lo llamó an order of magnitude, ya que salía de una muestra de 11 minutos. Nuestra carpeta de datos pasó de 1,4 MB vacía a 5 MB tras añadir 200 monitores y 15 minutos de comprobaciones, una muestra demasiado corta para proyectar meses. Stack 4 tiene 75 GB de disco, así que al principio revisa df -h cada uno o dos meses. Si se te queda pequeño, puedes pasar a un plan Stack mayor y tu entorno se viene contigo.

Cómo accedes al panel de control

La propia guía de proxy inverso de Uptime Kuma recomienda poner delante un servidor web normal con HTTPS, y menciona Caddy como uno que obtiene y renueva los certificados por sí solo. El servidor de Uptime Kuma de DreamHost está montado así: accedes al panel a través de Caddy, con HTTPS real en la IP del servidor.

Las páginas de estado y las insignias están pensadas para ser públicas, así que siguen accesibles sin iniciar sesión.

Configúralo paso a paso

Ejecutarás los comandos siguientes como root, o pon sudo delante si inicias sesión con otro usuario.

Inicia sesión y actualiza

1. Dale un servidor que no aloje nada más

   Contrata Stack 4 con Uptime Kuma, la opción de DreamHost para este trabajo, y dedica ese servidor solo al monitor.

2. Consulta el inicio de sesión creado en el primer arranque

   La contraseña de administrador se genera en el primer arranque, antes de que se pueda acceder al panel. Conéctate al servidor por SSH y muéstrala:

   bashCopiar

   cat /root/.uptime_kuma_credentials

   Inicia sesión en la IP de tu servidor por HTTPS. Guarda la contraseña en un gestor de contraseñas. Más adelante, cada página de estado puede tener su propio dominio.

3. Actualiza antes de añadir nada

   Un servidor nuevo arranca con la versión que DreamHost fijó y probó, que puede ir por detrás de la última versión de Uptime Kuma. El script de actualización no hace copia de seguridad por su cuenta, así que haz primero la copia:

   bashCopiar

   uptime-kuma-backup
   uptime-kuma-update

   El actualizador se mantiene en la versión 2 y no salta a una versión principal nueva sin ti. A 15 de octubre de 2026, la última versión de Uptime Kuma era la 2.5.6.

Configura el inicio de sesión y las alertas

1. Activa el inicio de sesión en dos pasos

   Ve a Settings, luego a Security, y haz clic en 2FA Settings. Uptime Kuma muestra un código QR para escanear con una app de autenticación y después te pide un código de la app para confirmar.

2. Indica a Uptime Kuma que confíe en Caddy

   Ve a Settings, luego a Reverse Proxy y después a HTTP Headers, y pon Trust Proxy en Yes si no lo está ya. La guía de proxy inverso de Uptime Kuma indica este ajuste para servidores a los que solo se accede a través de un servidor web situado delante. Así, tus registros muestran la dirección real de cada visitante.

3. Añade una notificación y después tus monitores

   Un monitor caído solo aparece en el panel hasta que añades un servicio de notificaciones en Settings, luego Notifications. Conecta primero el correo electrónico, Slack o Telegram y después crea tus monitores.

Vigila el monitor y guarda una copia

1. Apunta una comprobación externa a Uptime Kuma

   El plan gratuito de UptimeRobot cubre 50 monitores con comprobaciones cada 5 minutos, y uno de ellos puede vigilar la dirección de tu Uptime Kuma. Un comentarista de Hacker News usa UptimeRobot justo para esto: I only use it to monitor the Uptime Kuma that monitors the rest of my homelab.

   Una señal de latido (heartbeat) también sirve. El plan gratuito de Healthchecks.io vigila 20 tareas, y su documentación de shell da una línea de curl para enviarle el ping. Pon delante una comprobación local rápida para que el ping solo salga mientras Uptime Kuma responde, y añade la línea al crontab del servidor con crontab -e:

   bashCopiar

   */5 * * * * curl -fsS -m 5 -o /dev/null http://127.0.0.1:3001 && curl -fsS -m 10 --retry 5 -o /dev/null https://hc-ping.com/your-uuid-here

   Ese latido demuestra que el servidor, sus tareas programadas y la aplicación están en marcha. La comprobación de UptimeRobot también confirma que el panel responde por HTTPS desde fuera. Los planes de pago de UptimeRobot aparecen en nuestra guía de precios de UptimeRobot frente a Pingdom y Better Stack.

2. Copia cada copia de seguridad fuera del servidor

   La guía de migración a v2 de Uptime Kuma considera que una copia del directorio de datos es la única copia de seguridad compatible, y uptime-kuma-backup crea una como archivo local y muestra dónde la ha guardado. Desde tu propio ordenador, descarga ese archivo:

   bashCopiar

   scp YOUR-USER@YOUR-SERVER-IP:/path/printed/by/the/script.tar.gz .

   Si inicias sesión con un usuario que no sea root, copia el archivo a tu carpeta personal con sudo cp y hazte propietario de él con sudo chown antes de descargarlo.

   El script guarda su archivo en el mismo disco que Uptime Kuma. Esa copia te permite recuperarte de una actualización fallida, pero no te servirá si pierdes el servidor, así que no la dejes ahí.

3. Sigue las nuevas versiones

   Debian se parchea solo en segundo plano. El contenedor de Uptime Kuma no se actualiza solo, así que cada nueva versión espera hasta que vuelvas a ejecutar los dos comandos de actualización. Sigue las versiones de Uptime Kuma desde el menú Watch del repositorio en GitHub y actualiza a la última cuando salga.

Preguntas frecuentes sobre el hosting de Uptime Kuma