comparing monitoring as code
Does Uptime Kuma have a Terraform provider?
Uptime Kuma has no provider of its own, and no documented management API to build one on. What the registry offers instead is seven community providers riding an unofficial client library. One of them is genuinely good. The thing to weigh is what it asks for to log in.
The table below is the whole comparison, unedited. Read it first if you like, it is the same one we would send you.
AGPL-3.0 · one binary · free tier · no card required
What seven community forks add up to
| Uptime Kuma | Uptimepage | |
|---|---|---|
| provider from the vendor | none | yes |
| providers on the registry | 7, all community | one, ours |
| best community option | breml/uptimekuma v0.4.0 | not needed |
| monitors as code | yes | yes |
| status page as code | yes, community | yes |
| management API | none documented | REST, documented |
| how Terraform authenticates | admin user and password | scoped token |
The Uptime Kuma project publishes no provider. The registry returns seven community ones: breml/uptimekuma, kenlee20/kuma, kenlee20/upkuapi, ehealth-co-id/uptimekuma, zahornyak/uptime-kuma-wapi, kurtmc/uptimekuma and TheodoreHerzfeld's.
breml/uptimekuma is the most complete: 63 stars, v0.4.0 released 25 July 2026, commits this month, and resources for monitors, notifications, proxies, maintenance, tags, status pages and status-page incidents.
Uptime Kuma documents no management API, so every provider here depends on a reverse-engineered client. breml's README states its capabilities are limited to what go-uptime-kuma-client supports.
Uptime Kuma's own API keys expose metrics only, so the provider takes an account username and password instead of a scoped token.
Verified 11 August 2026 against the Terraform Registry and each provider's repository. Providers ship often, so check before you decide.
What the registry actually has
The Uptime Kuma project publishes nothing. Searching the registry in August 2026 returns seven community providers: breml/uptimekuma, kenlee20/kuma, kenlee20/upkuapi, ehealth-co-id/uptimekuma, zahornyak/uptime-kuma-wapi, kurtmc/uptimekuma and TheodoreHerzfeld's. The most complete by a wide margin is breml/uptimekuma, 63 stars, v0.4.0 released 25 July 2026 with commits this month. It covers more than thirty monitor types, around a hundred notification services, proxies, maintenance windows, tags, and a status page with incidents. If you need one, that is the one.
Why they all ride an unofficial client
Uptime Kuma drives its UI over Socket.IO and documents no management API. Its own API keys read metrics and nothing else. So every provider here talks to Kuma through a reverse-engineered client library, and breml's README says so plainly: capabilities are limited to what go-uptime-kuma-client supports. Coverage therefore tracks a third repository rather than Kuma releases, and a Kuma upgrade can move ahead of both.
The credential it asks for
The provider block takes an endpoint, a username and a password, or the UPTIMEKUMA_PASSWORD variable. That is your Uptime Kuma admin login. Terraform state, your CI runner and anyone who can read a plan get a credential that does everything the UI does, deletion included. There is no scope to narrow and no expiry to lean on, because Kuma has no token to issue. For a homelab that is fine. For a shared pipeline it is the part to think about before the feature list.
A monitor, and a token that only writes monitors
provider "uptimepage" {
token = var.uptimepage_write_token # scoped, expiring
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 }
}
}
}Where Uptimepage fits
If monitoring as code is the reason you are reading this, the provider being ours rather than a fork is the difference. Monitors, status pages, components and notification channels are all resources, against the same documented REST API the dashboard uses, and a Terraform run authenticates with a scoped, expiring token rather than an account password. There is an MCP server on that API too. Hosted free with no card, or self-host the whole thing under AGPL.
- 01Sign in with GitHub or Google. No card, no sales call.
- 02Paste a URL. The first check runs before you have finished reading this.
- 03Publish the status page, or export it to Terraform and keep it in Git.
api99.98%
p95 142ms · one incident in 45 days
dashboard99.91%
p95 318ms · two degraded days
webhooks99.99%
p95 88ms · no incidents
RESOLVED14 min
Elevated latency on the dashboard API
14:22 resolved, latency back under 300ms
14:08 opened automatically by the dashboard check
up degraded down 45 days · email & webhook subscribers