Skip to main content

Checkmate: Plataforma local para vigilar infraestructura y servicios

Despliegue y configuración básica de Checkmate, la plataforma open source de monitorización desarrollada por Bluewave Labs.

Introducción

Checkmate es una herramienta moderna de monitorización de infraestructura y servicios, pensada para ofrecer visibilidad completa de sistemas, contenedores y endpoints web desde una interfaz unificada. Combina comprobaciones de disponibilidad, métricas de rendimiento y páginas de estado públicas en una solución autoalojada.

Su arquitectura está dividida en tres componentes principales:

  • Backend — API y lógica de monitorización, desarrollada en Node.js y conectada a MongoDB.
  • Frontend — interfaz React accesible desde navegador, donde se visualizan los monitores, alertas y gráficas.
  • Agente opcional (Capture) — recolector ligero de métricas de hardware y contenedores Docker.

A diferencia de soluciones externas tipo UptimeRobot o BetterStack, Checkmate se ejecuta completamente en la infraestructura propia, sin depender de servicios de terceros ni ceder datos. Su enfoque es sencillo, rápido de desplegar y extensible mediante webhooks, integraciones y alertas.

Requisitos previos

  • Docker y Docker Compose instalados.
  • Subdominio o dominio reservado (solo en la versión expuesta).
  • Caddy funcionando como reverse proxy (en la versión expuesta).

Estructura de archivos

Repositorio en Gitea:

Variante 1 — despliegue interno

Sin exposición al exterior. Todos los contenedores comunican dentro de la red Docker Checkmate_NET.

Puntos clave:

  • El cliente se comunica con el backend usando direcciones locales.
  • No se expone ningún puerto público salvo los internos (8023 y 52345).
  • No hay TLS ni proxy inverso.

Fragmento principal:

UPTIME_APP_API_BASE_URL: "http://192.168.1.20:52345/api/v1"
UPTIME_APP_CLIENT_HOST: "http://192.168.1.20:8023"
CLIENT_HOST=http://192.168.1.20:8023

El acceso se realiza directamente desde el navegador local apuntando a la IP o nombre interno del host.

Variante 2 — despliegue con Caddy

Usa Caddy como reverse proxy para exponer el frontend y la API a través de HTTPS.

Fragmento principal del Caddyfile:

status.tu-dominio.com {
    handle /api/* {
        reverse_proxy 192.168.X.X:52345
    }

    route {
        reverse_proxy 192.168.X.X:8023
    }
}

Requiere certificados válidos y configuración previa de seguridad. Se recomienda integrarlo con políticas de firewall, autenticación o reglas WAF si se publica.

Decisiones importantes

  • Se ha separado la configuración interna y pública para evitar exposición accidental.
  • Se recomienda mantener el JWT_SECRET fuera de los archivos versionados.
  • La base de datos MongoDB se monta en volumen persistente local.
  • El socket Docker se comparte en modo lectura para permitir monitorización de contenedores.

Resumen breve

  • docker-compose.yml: versión interna, sin exposición.
  • docker-compose_caddy.yml: versión pública, con Caddy.
  • Caddyfile: configuración del reverse proxy.
  • Red externa: Checkmate_NET.
  • Evitar exponer MongoDB o el backend directamente.

Referencias

Back to top