Alojar Uptime Kuma en un VPS administrado: vigile sus servicios sin pausa

Qué vigila Uptime Kuma

Uptime Kuma consulta sus servicios a intervalos regulares, hasta cada 20 segundos, guarda el historial de sus respuestas y le avisa en cuanto uno de ellos deja de responder. Se usa desde una interfaz web, disponible en varios idiomas.

• Las sondas: HTTP y HTTPS, búsqueda de una palabra clave en la página, petición JSON, TCP, WebSocket, ping, registro DNS, contenedores Docker y sonda «push» para una tarea programada que señala ella misma su ejecución.
• Las alertas: más de 90 servicios de notificación, entre ellos Telegram, Discord, Slack y el correo electrónico.
• Las páginas de estado: varias páginas públicas, cada una en su propio dominio si lo desea.
• Los certificados: la información del certificado HTTPS de cada servicio vigilado.
• La cuenta: doble autenticación, y paso por un proxy para las sondas que lo necesitan.

Coloque Uptime Kuma en un servidor distinto del de los servicios que vigila. En una máquina aparte, ve la caída desde fuera y envía la alerta mientras sus servicios están detenidos.

Lo que permite la licencia MIT

Uptime Kuma se publica bajo la licencia MIT. Autoriza a usar, copiar, modificar, fusionar, publicar, distribuir, sublicenciar y vender el software, con una condición: conservar el aviso de copyright y el texto de la licencia en toda copia.

Puede, por tanto, ejecutar Uptime Kuma en su empresa, vigilar en él los servicios de sus clientes y abrirles páginas de estado, sin ninguna licencia que comprar.

La instalación con Docker Compose

La documentación de Uptime Kuma empieza por Docker Compose. En un servidor con Docker instalado, cree una carpeta y descargue el archivo oficial:

mkdir uptime-kuma
cd uptime-kuma
curl -o compose.yaml https://raw.githubusercontent.com/louislam/uptime-kuma/master/compose.yaml

El archivo del proyecto publica el puerto 3001 en todas las direcciones del servidor. Detrás de un proxy inverso, límitelo a la dirección local, como propone el README:

services:
  uptime-kuma:
    image: louislam/uptime-kuma:2
    restart: unless-stopped
    volumes:
      - ./data:/app/data
    ports:
      - "127.0.0.1:3001:3001"

docker compose up -d

• Un puerto publicado en 127.0.0.1: Docker publica por defecto en todas las direcciones del servidor, antes de las reglas del cortafuegos ufw. En local, Uptime Kuma solo es accesible a través del proxy inverso.
• Una carpeta data en un disco local: guarda la base kuma.db, los archivos enviados y las capturas de pantalla. El proyecto descarta NFS y los demás sistemas de archivos en red, porque SQLite necesita bloqueos de archivo fiables.
• La etiqueta 2 sigue la versión 2 de Uptime Kuma, y el paso a una versión mayor posterior sigue siendo decisión suya.
• La imagen 2-slim es más ligera, unos 185 MB de descarga frente a 620 MB: deja de lado Chromium y el MariaDB integrado que incluye la imagen 2. La imagen 2 es la que recomienda el proyecto, y una sonda «Browser Engine» requiere entonces un Chromium externo con 2-slim.

En el primer arranque, abra la interfaz: un asistente le hace elegir la base de datos y después crear la cuenta de administrador. Active la doble autenticación desde el primer acceso.

El proyecto no cifra ni la memoria ni el procesador: el tamaño depende del número de servicios que vigilar y de la frecuencia deseada. En un VPS administrado, descríbanos su uso y le recomendamos el tamaño adecuado.

HTTPS y WebSocket: el proxy inverso

En una red pública, el proyecto pide HTTPS. Uptime Kuma se apoya en WebSocket: el proxy inverso debe transmitir las cabeceras Upgrade y Connection. Se sirve en la raíz de un dominio o de un subdominio, y su wiki descarta las subcarpetas como example.com/uptimekuma.

Con Caddy

Caddy obtiene y renueva solo el certificado, y transmite WebSocket sin ningún ajuste más:

uptime.example.com {
    reverse_proxy 127.0.0.1:3001
}

Con Nginx y Certbot

server {
    listen 80;
    server_name uptime.example.com;

    location / {
        proxy_pass         http://localhost:3001;
        proxy_http_version 1.1;
        proxy_set_header   Upgrade $http_upgrade;
        proxy_set_header   Connection "upgrade";
        proxy_set_header   Host $host;
    }
}

Certbot instala después el certificado Let’s Encrypt y la redirección a HTTPS, y renueva el certificado por sí mismo:

sudo certbot --nginx -d uptime.example.com

Cuando Uptime Kuma solo es accesible a través del proxy, abra sus ajustes, «Settings», «Reverse Proxy», «HTTP Headers», y ponga «Trust Proxy» en «Yes»: los registros muestran entonces la dirección real de los visitantes.

SQLite o MariaDB

Desde su versión 2, Uptime Kuma ofrece tres bases de datos, a elegir en el asistente del primer arranque:

Para fijar la elección de antemano, sin pasar por el asistente, las variables UPTIME_KUMA_DB_TYPE, UPTIME_KUMA_DB_HOSTNAME, UPTIME_KUMA_DB_PORT, UPTIME_KUMA_DB_NAME, UPTIME_KUMA_DB_USERNAME y UPTIME_KUMA_DB_PASSWORD se añaden al servicio en compose.yaml.

Las notificaciones, correo electrónico incluido

Una sonda solo sirve si la alerta le llega. Declare sus canales en «Settings», «Notifications», envíe un mensaje de prueba desde cada uno y prevea dos, por ejemplo una mensajería y el correo electrónico: si uno cae, el otro toma el relevo.

Para el correo, Uptime Kuma se conecta a un servidor SMTP. En un VPS de Simafri, el envío pasa por un relé autenticado, en el puerto 587: la dirección de una cuenta de correo que ya tenga, o Simafri Suite.

Copias de seguridad y actualizaciones

Desde la versión 2, la copia de la carpeta data es el único método que admite el proyecto. Con SQLite o con el MariaDB integrado, todo está ahí. Una base SQLite copiada en plena escritura puede quedar dañada: detenga el contenedor mientras dure la copia, sabiendo que las sondas se detienen con él.

docker compose stop
tar -czf uptime-kuma-$(date +%F).tar.gz data
docker compose start

Actualizar

El wiki del proyecto da dos comandos, desde la carpeta del compose.yaml. La carpeta data se queda en su sitio:

docker compose pull
docker compose up -d --force-recreate

Lea las notas de la versión antes de cada actualización: algunas incluyen correcciones de seguridad, como la 2.5.9 del 31 de octubre de 2026. Una copia de seguridad justo antes le da un retroceso sencillo.

El paso de la versión 1 a la versión 2 exige más cuidado: haga copia de la carpeta data con el contenedor detenido y deje que la migración llegue hasta el final, porque una migración interrumpida obliga a restaurar la copia. El proyecto midió unos 7 minutos para 20 sondas y 90 días de historial, y bastante más en una máquina modesta o con más sondas.

Quién hace qué en un VPS administrado

El autoalojamiento exige mantener el servidor además de la aplicación. En un VPS administrado, nuestros equipos se encargan del servidor y siguen su instancia de forma proactiva; Uptime Kuma sigue siendo su software, con sus ajustes y sus datos.

Si prefiere que nuestros equipos intervengan en la propia aplicación, ese servicio se factura por horas o a precio cerrado, con un presupuesto comunicado antes de la intervención.