Autoalojar Uptime Kuma para páginas de estado y alertas

Quieres saber en el momento en que tu sitio, API o servidor se cae, y quieres una página de estado para mostrarle a tus clientes sin pagar una suscripción mensual por algo que un solo contenedor puede hacer. Uptime Kuma es una herramienta de monitoreo de código abierto que hace ambas cosas: revisa tus endpoints según un horario, te envía una alerta en el momento en que uno falla, y te da una página de estado pública para mostrar el resultado. Al final de esto, lo tendrás funcionando en tu propio servidor, accesible por HTTPS en tu propio dominio, con sus datos sobreviviendo de verdad a un reinicio.

Lo que necesitas

• Un servidor pequeño. Uptime Kuma es un solo proceso de Node.js con una base de datos SQLite, así que no necesita mucho, pero darle al menos 1 GB de RAM evita los problemas de memoria insuficiente descritos en la sección de solución de problemas más abajo. Un Basic Droplet de DigitalOcean con 1 GB de RAM, 1 vCPU y 25 GB de SSD cuesta 6 USD al mes a la fecha de hoy (verificado en la página de precios de DigitalOcean). La línea optimizada en costo de Hetzner es una alternativa razonable si prefieres comparar.
• Un dominio que controles, con la posibilidad de agregar un registro A.
• Docker y Docker Compose instalados en el servidor (el paso 2 cubre esto).
• Unos minutos en tu primera visita para crear la cuenta de administrador. Uptime Kuma no trae ningún inicio de sesión por defecto: quien llegue primero a la pantalla de configuración se vuelve el administrador, así que no dejes el acceso abierto a Internet antes de completar ese paso.

Paso 1: apunta tu dominio al servidor

Crea primero el servidor, anota su dirección IP pública, y luego agrega un registro A para el subdominio que quieras usar, por ejemplo status.tudominio.com, apuntando a esa IP. La propagación de DNS suele ser rápida, pero puede tardar hasta unas horas según la configuración de TTL de tu registrador.

Puedes verificar que se resolvió con:

dig +short status.tudominio.com

Deberías ver la dirección IP del servidor reflejada. Si todavía no aparece nada, espera un poco antes de continuar. Hacer este paso primero le da tiempo al DNS para estabilizarse antes de que llegues a la parte de HTTPS.

Paso 2: instala Docker

La documentación de instalación de Uptime Kuma recomienda ejecutarlo como contenedor, y esa es la configuración que usa este tutorial de principio a fin. Conéctate por SSH a tu servidor e instala Docker con el script oficial:

curl -fsSL https://get.docker.com | sh

Docker Compose viene incluido como complemento en las instalaciones recientes de Docker, así que normalmente no hace falta un paso de instalación aparte. Confirma que ambos estén presentes:

docker --version
docker compose version

Deberías ver un número de versión impreso para cada uno. Si docker compose version falla, tu instalación de Docker es lo bastante antigua como para que Compose no venga incluido, y tendrás que instalar el paquete docker-compose-plugin por separado.

Paso 3: escribe el archivo Compose y arranca Uptime Kuma

Crea un directorio para la aplicación y un compose.yml dentro:

mkdir -p ~/uptime-kuma && cd ~/uptime-kuma

services:
  uptime-kuma:
    image: louislam/uptime-kuma:1
    container_name: uptime-kuma
    restart: unless-stopped
    ports:
      - "3001:3001"
    volumes:
      - uptime-kuma-data:/app/data

volumes:
  uptime-kuma-data:

La etiqueta 1 sigue la línea de la versión estable actual y se actualiza con cada versión de parche al volver a descargarla, en lugar de fijar una compilación exacta. Lo importante es el volumen con nombre uptime-kuma-data montado en /app/data: ahí es donde Uptime Kuma guarda su base de datos SQLite, y es lo que hace que tus monitores, tus ajustes de notificación y tus páginas de estado sobrevivan a un reinicio o una reconstrucción del contenedor. Sin ese volumen, un docker compose down o un reinicio del servidor que recree el contenedor borra todos los monitores que hayas configurado.

Arráncalo:

docker compose up -d

Confirma que está corriendo:

docker compose ps

Deberías ver el servicio uptime-kuma listado como running o healthy. En este punto solo es accesible por el puerto 3001, lo cual está bien, porque el paso 5 pone un proxy inverso delante.

Paso 4: crea la cuenta de administrador y agrega tu primer monitor

Antes de que el DNS y el HTTPS estén en su lugar, igual puedes acceder a la aplicación directamente por su puerto para crear la cuenta de administrador lo antes posible, lo que cierra la ventana de exposición de la pantalla de configuración:

http://<ip-del-servidor>:3001

La primera pantalla te pide crear un nombre de usuario y una contraseña. No hay ningún inicio de sesión por defecto que cambiar, solo una pantalla en blanco. Una vez dentro, agrega un monitor desde el panel: dale un nombre, un tipo (HTTP(s), puerto TCP, ping, DNS, y otros están disponibles), y el objetivo a revisar. Define el intervalo de verificación (60 segundos es un valor razonable por defecto para la mayoría de los sitios) y guárdalo.

Ya que estás ahí, ve a Settings → Notifications y agrega al menos un canal de notificación (correo electrónico, Slack, Discord, un webhook genérico, y decenas más están disponibles). Usa el botón Test en la notificación antes de confiar en ella: una URL de webhook mal configurada o un proveedor de correo que rechaza el mensaje silenciosamente es la forma más común de descubrir, en plena caída real, que tus alertas nunca se estaban entregando.

Deberías ver el estado de tu nuevo monitor ponerse verde (o rojo, si apuntaste a algo inalcanzable) dentro de un intervalo de verificación.

Paso 5: pon Caddy delante para HTTPS

Correr un panel de monitoreo en un puerto HTTP simple, sin certificado y sin dominio, está bien para probar pero no para algo de lo que realmente dependas. Caddy es un proxy inverso que solicita y renueva un certificado de Let’s Encrypt de forma automática, sin necesidad de configurar certbot por separado.

Instala Caddy directamente en el servidor (fuera del archivo Compose, para que pueda enlazarse limpiamente a los puertos 80 y 443):

sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https curl
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list
sudo apt update
sudo apt install caddy

Reemplaza /etc/caddy/Caddyfile con:

status.tudominio.com {
	reverse_proxy localhost:3001
}

Recarga Caddy para aplicar el cambio:

sudo systemctl reload caddy

Caddy solicita el certificado la primera vez que ve una petición para ese nombre de host, lo cual solo funciona si el registro A del paso 1 ya apunta a este servidor. Deberías ver https://status.tudominio.com cargar Uptime Kuma con un candado válido, y las peticiones http:// al mismo nombre de host deberían redirigirse automáticamente a HTTPS. Una vez que esto funcione, cierra el acceso directo al puerto 3001 en tu firewall para que la aplicación solo sea accesible a través de Caddy.

Paso 6: respalda el volumen de datos

Todo lo que importa (monitores, ajustes de notificación, configuración de páginas de estado, historial) vive en el archivo SQLite dentro del volumen uptime-kuma-data. Respáldalo según un horario, en lugar de descubrir que lo necesitas en medio de un incidente real.

Un enfoque simple compatible con cron, ejecutado desde el host:

docker run --rm \
  -v uptime-kuma_uptime-kuma-data:/data \
  -v ~/uptime-kuma-backups:/backup \
  alpine tar czf /backup/uptime-kuma-$(date +%F).tar.gz -C /data .

Agrega eso como una tarea cron diaria (crontab -e) y conserva los archivos de la última semana o dos. Deberías ver un nuevo archivo .tar.gz aparecer en ~/uptime-kuma-backups después de que se ejecute. Para restaurar, detén el contenedor, extrae el archivo de vuelta en la misma ruta del volumen, y arráncalo de nuevo.

Paso 7: actualizaciones más adelante

Como el archivo Compose fija la etiqueta móvil 1 en lugar de una versión de parche exacta, volver a descargar trae la última versión de parche de esa línea:

docker compose pull
docker compose up -d

Docker recrea el contenedor con la nueva imagen dejando el volumen con nombre intacto, así que tus datos no se ven afectados. Revisa las notas de versión en la página de releases de GitHub de Uptime Kuma antes de un salto de versión mayor en particular, ya que esos pueden incluir cambios que rompen compatibilidad y que una versión de parche no tendría.

El atajo: hazlo con Railyard

Todo lo anterior es el camino manual completo, y es una forma razonable de correr esto si quieres ser dueño de cada pieza. Si prefieres saltarte el aprovisionamiento del servidor, la instalación de Docker, el archivo Compose y la configuración del proxy inverso para obtener la misma aplicación funcionando, la plantilla de Uptime Kuma de Railyard despliega la misma imagen con el volumen de datos ya montado en /app/data y el HTTPS ya resuelto. No hay nada que configurar después del despliegue: tampoco hay inicio de sesión por defecto, creas la cuenta de administrador en tu primera visita, igual que en el camino manual. Es la misma aplicación, el mismo paso de configuración, solo sin la gestión del servidor en medio.

Si estás descubriendo Railyard en general, la guía de inicio rápido y desplegar con un botón de un clic cubren lo básico, y los costos de hospedaje desglosan lo que una aplicación pequeña como esta suele costar según el proveedor.

Solución de problemas

“Bind for 0.0.0.0:3001 failed: port is already allocated”. Algo más en el servidor ya está usando el puerto 3001, muchas veces un intento anterior de correr el contenedor que no se eliminó. Revisa con docker ps -a y elimina el contenedor obsoleto, o cambia el lado del host en el mapeo de puertos en compose.yml (por ejemplo "3002:3001") y ajusta el destino del proxy inverso de Caddy correspondientemente.

Caddy no logra emitir un certificado. Esto casi siempre es cuestión de DNS, no de Caddy. Si el registro A del paso 1 todavía no se ha propagado, o apunta a la IP equivocada, la petición de validación de Let’s Encrypt nunca llega a tu servidor y la solicitud de certificado falla en silencio en los registros de Caddy (sudo journalctl -u caddy -n 50). Vuelve a ejecutar el comando dig del paso 1 para confirmar que el registro apunta a la IP correcta antes de investigar cualquier otra cosa.

Los monitores desaparecieron después de un reinicio o redespliegue. Esto significa que el contenedor estaba corriendo sin el volumen con nombre, o con el volumen montado en la ruta equivocada. /app/data es la única ruta donde Uptime Kuma escribe su base de datos. Si ejecutaste un docker run rápido sin -v para probar algo, los datos de ese contenedor desaparecen en el momento en que se elimina. Confirma que docker volume ls muestre uptime-kuma_uptime-kuma-data y que sea ese el que está montado en tu archivo compose.

Las notificaciones no llegan realmente. Uptime Kuma registra un envío de notificación fallido en su propio registro de eventos, pero es fácil pasarlo por alto si no lo estás buscando. Usa siempre el botón Test en Settings → Notifications justo después de agregar un canal, no solo cuando configures un monitor por primera vez. Las URL de webhook ligeramente equivocadas, los proveedores de correo que exigen una contraseña de aplicación en lugar de tu contraseña normal, y los tokens de Slack vencidos son las causas más comunes.

El contenedor se reinicia sin parar en un servidor muy pequeño. En un droplet de 512 MB, el proceso de Node.js de Uptime Kuma puede ser eliminado por falta de memoria bajo carga, especialmente si agregas muchos monitores con intervalos de verificación cortos o activas monitores que usan un navegador sin interfaz. dmesg | grep -i "out of memory" lo confirmará. La solución es más RAM, no más ajustes: un plan de 1 GB es el mínimo realista para una operación cómoda y sin supervisión constante.

Preguntas frecuentes

¿Uptime Kuma es gratis? Sí, es de código abierto (licencia MIT) y autoalojado, así que no hay ninguna suscripción. Solo pagas por el servidor donde corre.

¿Necesito una base de datos? No. Uptime Kuma usa una base de datos SQLite integrada dentro de su propio volumen de datos, así que no hay nada más que aprovisionar o conectar.

¿Puedo monitorear más de un sitio o servidor desde una sola instancia? Sí, una sola instancia de Uptime Kuma puede correr cualquier cantidad de monitores, cada uno verificado de forma independiente según su propio horario y tipo.

¿La página de estado es pública por defecto? Las páginas de estado son algo que creas y publicas deliberadamente desde el panel. Los monitores individuales no quedan expuestos hasta que los agregas a una página de estado que decides hacer pública.

¿En qué se diferencia de UptimeRobot o Pingdom? Esos son servicios alojados que pagas mensualmente y cuya infraestructura no controlas. Uptime Kuma te da el mismo conjunto de funciones principales (verificaciones HTTP/TCP/ping, alertas, páginas de estado públicas) corriendo en un servidor que es tuyo, con tu historial de monitoreo quedándose en tu propia base de datos en lugar de en la de un proveedor.

Una vez que está funcionando y respaldado, esta es una de las cosas que menos mantenimiento piden al autoalojarla: vigila todo lo demás por ti, y solo te pide algo cuando de verdad algo anda mal.