comparativa de monitoreo como código
¿Tiene Uptime Kuma un proveedor de Terraform?
Uptime Kuma no tiene un proveedor propio, ni una API de gestión documentada sobre la que construir uno. Lo que ofrece el registro en su lugar son siete proveedores de la comunidad montados sobre una biblioteca cliente no oficial. Uno de ellos es bueno de verdad. Lo que hay que sopesar es lo que pide para iniciar sesión.
La tabla de abajo es la comparación completa, sin editar. Léala primero si lo prefiere: es la misma que le enviaríamos.
AGPL-3.0 · un solo binario · plan gratuito · sin tarjeta
Lo que suman siete forks de la comunidad
| Uptime Kuma | Uptimepage | |
|---|---|---|
| proveedor propio | ninguno | sí |
| proveedores en el registro | 7, todos de la comunidad | uno, el nuestro |
| mejor opción de la comunidad | breml/uptimekuma v0.4.0 | no hace falta |
| monitores como código | sí | sí |
| página de estado como código | sí, de la comunidad | sí |
| API de gestión | ninguna documentada | REST, documentada |
| cómo se autentica Terraform | usuario y contraseña de administrador | token de alcance limitado |
El proyecto Uptime Kuma no publica ningún proveedor. El registro devuelve siete de la comunidad: breml/uptimekuma, kenlee20/kuma, kenlee20/upkuapi, ehealth-co-id/uptimekuma, zahornyak/uptime-kuma-wapi, kurtmc/uptimekuma y el de TheodoreHerzfeld.
breml/uptimekuma es el más completo: 63 estrellas, v0.4.0 publicada el 25 de julio de 2026, commits este mes y recursos para monitores, notificaciones, proxies, mantenimiento, etiquetas, páginas de estado e incidentes de páginas de estado.
Uptime Kuma no documenta ninguna API de gestión, así que cada proveedor de esta lista depende de un cliente obtenido por ingeniería inversa. El README de breml indica que sus capacidades se limitan a lo que admite go-uptime-kuma-client.
Las propias claves de API de Uptime Kuma solo exponen métricas, así que el proveedor recibe el nombre de usuario y la contraseña de una cuenta en lugar de un token de alcance limitado.
Verificado el 11 de agosto de 2026 con el Terraform Registry y el repositorio de cada proveedor. Los proveedores publican versiones a menudo, así que compruébelo antes de decidir.
Lo que hay de verdad en el registro
El proyecto Uptime Kuma no publica nada. Una búsqueda en el registro en agosto de 2026 devuelve siete proveedores de la comunidad: breml/uptimekuma, kenlee20/kuma, kenlee20/upkuapi, ehealth-co-id/uptimekuma, zahornyak/uptime-kuma-wapi, kurtmc/uptimekuma y el de TheodoreHerzfeld. El más completo, con gran diferencia, es breml/uptimekuma: 63 estrellas, v0.4.0 publicada el 25 de julio de 2026 y commits este mes. Cubre más de treinta tipos de monitor, alrededor de cien servicios de notificación, proxies, ventanas de mantenimiento, etiquetas y una página de estado con incidentes. Si necesita uno, es ese.
Por qué todos dependen de un cliente no oficial
Uptime Kuma maneja su interfaz por Socket.IO y no documenta ninguna API de gestión. Sus propias claves de API leen métricas y nada más. Así que cada proveedor de esta lista habla con Kuma a través de una biblioteca cliente obtenida por ingeniería inversa, y el README de breml lo dice claramente: sus capacidades se limitan a lo que admite go-uptime-kuma-client. Por tanto, la cobertura sigue el ritmo de un tercer repositorio y no el de las versiones de Kuma, y una actualización de Kuma puede adelantarse a ambos.
La credencial que pide
El bloque provider recibe un endpoint, un nombre de usuario y una contraseña, o la variable UPTIMEKUMA_PASSWORD. Es su inicio de sesión de administrador de Uptime Kuma. El estado de Terraform, su runner de CI y cualquiera que pueda leer un plan obtienen una credencial que hace todo lo que hace la interfaz, incluido borrar. No hay ningún alcance que restringir ni ninguna caducidad en la que apoyarse, porque Kuma no tiene ningún token que emitir. Para un homelab, no pasa nada. Para un pipeline compartido, es lo que hay que pensar antes de mirar la lista de funciones.
Un monitor y un token que solo escribe monitores
provider "uptimepage" {
token = var.uptimepage_write_token # alcance limitado, con caducidad
org = "acme"
}
resource "uptimepage_target" "api" {
name = "api"
interval = 60
check = {
type = "http"
http = {
url = "https://example.com/healthz"
expected_status = { kind = "exact", exact = 200 }
}
}
}Dónde encaja Uptimepage
Si el monitoreo como código es la razón por la que está leyendo esto, la diferencia es que el proveedor es nuestro y no un fork. Monitores, páginas de estado, componentes y canales de notificación son todos recursos, sobre la misma API REST documentada que usa el panel, y una ejecución de Terraform se autentica con un token de alcance limitado y con caducidad en lugar de con la contraseña de una cuenta. Sobre esa API también hay un servidor MCP. Úselo alojado gratis y sin tarjeta, o autoaloje todo el producto bajo AGPL.
- 01Inicie sesión con GitHub o Google. Sin tarjeta, sin llamada comercial.
- 02Pegue una URL. La primera comprobación se ejecuta antes de que termine de leer esto.
- 03Publique la página de estado, o expórtela a Terraform y guárdela en Git.
api99,98 %
p95 142 ms · un incidente en 45 días
dashboard99,91 %
p95 318 ms · dos días degradados
webhooks99,99 %
p95 88 ms · sin incidentes
RESUELTO14 min
Latencia elevada en la API del panel
14:22 resuelto, latencia de nuevo por debajo de 300 ms
14:08 abierto automáticamente por la comprobación del panel
activo degradado caído 45 días · suscriptores por correo y webhook