{"id":1557,"date":"2026-09-11T18:49:17","date_gmt":"2026-09-11T21:49:17","guid":{"rendered":"https:\/\/www.linuxpro.com.br\/?p=1557"},"modified":"2026-09-11T18:54:03","modified_gmt":"2026-09-11T21:54:03","slug":"uptime-kuma-no-linux-monitoramento-self-hosted-com-docker-e-nginx","status":"publish","type":"post","link":"https:\/\/www.linuxpro.com.br\/es\/2026\/09\/uptime-kuma-no-linux-monitoramento-self-hosted-com-docker-e-nginx\/","title":{"rendered":"Uptime Kuma en Linux: monitorizaci\u00f3n autoalojada con Docker y Nginx"},"content":{"rendered":"

\"Mascote<\/p>\n

Cuando un sitio, una API o un servidor deja de responder, descubrirlo por el usuario llega demasiado tarde. O Uptime Kuma<\/strong> es una herramienta de monitorizaci\u00f3n self-hosted<\/em> con interfaz web: ejecuta comprobaciones a intervalos regulares, registra el hist\u00f3rico y env\u00eda alertas cuando un servicio cambia de estado. En esta gu\u00eda, lo instalaremos con Docker Compose, lo publicaremos con Nginx y configuraremos los primeros monitores con seguridad.<\/p>\n

Por qu\u00e9 usar Uptime Kuma<\/h2>\n

Kuma tiene sentido cuando necesitas saber r\u00e1pidamente si algo que consume el usuario sigue accesible: un sitio web, una API, un puerto TCP, una resoluci\u00f3n DNS o la finalizaci\u00f3n de un trabajo. Re\u00fane la comprobaci\u00f3n, el historial, el cambio de estado, la notificaci\u00f3n y una p\u00e1gina de estado en una interfaz sencilla. Como es self-hosted<\/em>, las URL, las credenciales de notificaci\u00f3n y el historial permanecen en tu infraestructura, en lugar de en una cuenta de monitorizaci\u00f3n de terceros.<\/p>\n

Esto no lo convierte en un sustituto universal. El tiempo de actividad no es observabilidad completa: un endpoint puede responder y aun as\u00ed estar lento, sin espacio en disco o con una cola acumulada. La mejor elecci\u00f3n es usarlo como la capa de disponibilidad y alerta r\u00e1pida, junto con m\u00e9tricas y registros cuando la operaci\u00f3n necesite un diagn\u00f3stico profundo.<\/p>\n

En qu\u00e9 lenguaje est\u00e1 desarrollado<\/h2>\n

Uptime Kuma es una aplicaci\u00f3n para Node.js<\/strong>, predominantemente en JavaScript. La interfaz web utiliza Vue 3<\/strong> e Vite<\/strong>; el repositorio tambi\u00e9n incluye TypeScript en la cadena de desarrollo. Por eso la ejecuci\u00f3n sin Docker exige Node.js 20.4 o superior, pero la ruta con contenedor evita instalar Node y dependencias del proyecto directamente en el host.<\/p>\n

Qu\u00e9 monitoriza Uptime Kuma<\/h2>\n

El proyecto es una alternativa ligera para acompanhar la disponibilidad de servicios sin externalizar el panel. Admite monitores HTTP(S), TCP, b\u00fasqueda de palabras clave y consulta JSON en HTTP(S), WebSocket, ping, DNS, push<\/em>, servidores Steam y contenedores Docker. Tambi\u00e9n ofrece p\u00e1ginas p\u00fablicas de estado, gr\u00e1fica de latencia, informaci\u00f3n de certificado, soporte para proxy, autenticaci\u00f3n de dos factores e integraciones de notificaci\u00f3n.<\/p>\n

No sustituye a m\u00e9tricas detalladas: para CPU, memoria, disco y series temporales de servidores, comb\u00ednalo con Prometheus y Node Exporter<\/a>. Kuma responde a otra pregunta: \u201c\u00bfeste endpoint est\u00e1 accesible ahora y alguien fue avisado?\u201d.<\/p>\n

Instala Docker, Compose y Nginx en Ubuntu<\/h2>\n

Los comandos siguientes son para Ubuntu 22.04 LTS, 24.04 LTS o posterior soportado por Docker. Utilizan el repositorio oficial de Docker, que ofrece el Engine y el plugin moderno docker compose<\/code>. En una m\u00e1quina que ya ejecuta contenedores, no elimines ni sustituyas paquetes sin revisar el impacto: la documentaci\u00f3n de Docker lista docker.io<\/code>, docker-compose<\/code>, containerd<\/code> e runc<\/code> entre los paquetes que pueden entrar en conflicto con la instalaci\u00f3n oficial.<\/p>\n

En un host nuevo, instala los requisitos previos, Nginx y la clave del repositorio:<\/p>\n

sudo apt update\nsudo apt install -y ca-certificates curl nginx\nsudo install -m 0755 -d \/etc\/apt\/keyrings\nsudo curl -fsSL https:\/\/download.docker.com\/linux\/ubuntu\/gpg \n  -o \/etc\/apt\/keyrings\/docker.asc\nsudo chmod a+r \/etc\/apt\/keyrings\/docker.asc<\/code><\/pre>\n
A\u00f1ade la fuente APT. El comando lee autom\u00e1ticamente el nombre clave y la arquitectura de la instalaci\u00f3n actual:<\/p>\n
sudo tee \/etc\/apt\/sources.list.d\/docker.sources <<EOF\nTypes: deb\nURIs: https:\/\/download.docker.com\/linux\/ubuntu\nSuites: $(. \/etc\/os-release && echo \"${UBUNTU_CODENAME:-$VERSION_CODENAME}\")\nComponents: stable\nArchitectures: $(dpkg --print-architecture)\nSigned-By: \/etc\/apt\/keyrings\/docker.asc\nEOF\n\nsudo apt update<\/code><\/pre>\n
Instale Docker Engine, Compose y habilite los servicios:<\/p>\n
sudo apt install -y docker-ce docker-ce-cli containerd.io \n  docker-buildx-plugin docker-compose-plugin\nsudo systemctl enable --now docker nginx\nsudo docker run hello-world\ndocker compose version<\/code><\/pre>\n
El primer comando de prueba descarga una imagen peque\u00f1a y se cierra; confirma que el daemon funciona. Mant\u00e9ngase sudo<\/code> en los comandos de Docker o configure el acceso posterior a la instalaci\u00f3n de forma consciente: pertenecer al grupo docker<\/code> equivale, en la pr\u00e1ctica, a tener poder administrativo sobre el host. Antes de exponer puertos de contenedores, revise tambi\u00e9n el cortafuegos: las reglas publicadas por Docker pueden sortear las reglas de UFW.<\/p>\n
Antes de empezar<\/h2>\n
Necesita un host Linux con Docker Engine y el plugin Docker Compose. El ejemplo usa un directorio propio en \/opt<\/code>, un volumen local para los datos y el puerto del servicio limitado a 127.0.0.1<\/code>. As\u00ed, la interfaz no queda abierta directamente en internet; Nginx ser\u00e1 la \u00fanica puerta de entrada.<\/p>\n
La base de datos de Uptime Kuma se encuentra en el directorio de datos. No coloque ese directorio en NFS: el proyecto no lo admite, porque los bloqueos de archivo necesarios para SQLite no son adecuados en ese escenario. Incluya \/opt\/uptime-kuma\/data<\/code> en la copia de seguridad del servidor.<\/p>\n
Levanta Uptime Kuma con Docker Compose<\/h2>\n
Cree el directorio y el archivo compose.yaml<\/code>:<\/p>\n
sudo install -d -m 0755 \/opt\/uptime-kuma\nsudoedit \/opt\/uptime-kuma\/compose.yaml<\/code><\/pre>\n
Use esta configuraci\u00f3n. La etiqueta :2<\/code> sigue la versi\u00f3n m\u00e1s reciente de la l\u00ednea 2 y es la recomendada por el proyecto. Para fijar una versi\u00f3n concreta, use una etiqueta 2.x.x<\/code>. No use :latest<\/code> como atajo para la versi\u00f3n 2: ese nombre est\u00e1 obsoleto y a\u00fan apunta a la rama 1.<\/p>\n
services:\n  uptime-kuma:\n    image: louislam\/uptime-kuma:2\n    container_name: uptime-kuma\n    restart: unless-stopped\n    volumes:\n      - .\/data:\/app\/data\n    ports:\n      - \"127.0.0.1:3001:3001\"<\/code><\/pre>\n
Inicie y confirme el estado:<\/p>\n
cd \/opt\/uptime-kuma\nsudo docker compose up -d\nsudo docker compose ps\ncurl -I http:\/\/127.0.0.1:3001<\/code><\/pre>\n
En la primera apertura, cree la cuenta administrativa. Guarde esa contrase\u00f1a en un gestor de contrase\u00f1as y active 2FA en los ajustes. Para seguir el inicio, use sudo docker compose logs -f<\/code>.<\/p>\n
Publica con Nginx y HTTPS<\/h2>\n
Elija un subdominio, por ejemplo status-admin.exemplo.com<\/code>, y apunte el DNS al servidor. Uptime Kuma debe quedar en la ra\u00edz de ese subdominio; no admite la instalaci\u00f3n en un subdirectorio como exemplo.com\/kuma\/<\/code>.<\/p>\n
Primero, emita un certificado TLS para el subdominio mediante el m\u00e9todo empleado en su servidor. No abra la interfaz ni cree la cuenta administrativa antes de que HTTPS est\u00e9 activo<\/strong>: el inicio de sesi\u00f3n por HTTP expone la credencial. Despu\u00e9s, cree el server block<\/em> final. Ajuste las rutas del certificado a su entorno; la compatibilidad con WebSocket es importante para que la interfaz se actualice en tiempo real:<\/p>\n
server {\n    listen 80;\n    server_name status-admin.exemplo.com;\n    return 301 https:\/\/$host$request_uri;\n}\n\nserver {\n    listen 443 ssl;\n    server_name status-admin.exemplo.com;\n\n    ssl_certificate \/etc\/letsencrypt\/live\/status-admin.exemplo.com\/fullchain.pem;\n    ssl_certificate_key \/etc\/letsencrypt\/live\/status-admin.exemplo.com\/privkey.pem;\n\n    location \/ {\n        proxy_pass http:\/\/127.0.0.1:3001;\n        proxy_http_version 1.1;\n        proxy_set_header Upgrade $http_upgrade;\n        proxy_set_header Connection \"upgrade\";\n        proxy_set_header Host $host;\n        proxy_set_header X-Real-IP $remote_addr;\n        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;\n        proxy_set_header X-Forwarded-Proto $scheme;\n    }\n}<\/code><\/pre>\n
Pruebe antes de recargar:<\/p>\n
sudo nginx -t\nsudo systemctl reload nginx<\/code><\/pre>\n
Valide https:\/\/status-admin.exemplo.com<\/code> y solo entonces haga el primer inicio de sesi\u00f3n. Al activar la opci\u00f3n Trust Proxy<\/em> en Kuma, h\u00e1galo solamente si toda solicitud llega a trav\u00e9s de un proxy inverso que usted controla; de lo contrario, los encabezados reenviados pueden falsificar la IP de origen. Para una revisi\u00f3n de Nginx en Debian o Ubuntu, consulte nuestra gu\u00eda sobre Nginx y versiones de PHP<\/a>.<\/p>\n
Crea monitores que realmente avisen algo \u00fatil<\/h2>\n
En el panel, haga clic en Add New Monitor<\/strong>. Comience con pocas comprobaciones que representen un recorrido real:<\/p>\n