Uptime Kuma vs Beszel
These two do not compete — they answer different questions, so pick by the question you have. Uptime Kuma tells you a URL, port or host stopped responding; Beszel tells you a machine is out of disk, pegged on CPU or running hot. Beszel makes no endpoint checks at all, and Uptime Kuma reports nothing about the hardware underneath it. If you serve something to the public and also care about the box under it, run both — together they still fit inside a gigabyte.
Side by side
This is the one comparison on the site where the honest answer is usually "both". Uptime Kuma and Beszel are filed under the same category and get recommended in the same threads, but they are not alternatives to each other — they watch different things from different sides. Uptime Kuma stands outside your service and knocks on the door. Beszel sits inside your machine and takes its temperature. Neither can do the other's job, and picking one because it scored better on a table is how you end up with a green dashboard and a full disk.
Two different jobs
Uptime Kuma is an active prober. It makes requests — HTTP, TCP, ping, DNS, keyword matching, certificate expiry — on an interval, from wherever it happens to be running, and alerts when a response stops arriving or stops matching. It knows nothing about the hardware under any of it, including its own. A server can be at 99% memory and thrashing swap; if the page still returns 200, Uptime Kuma is satisfied.
Beszel is the mirror image. You install a small agent on each machine and a hub collects what it reports: CPU, memory, disk, network, load average, temperature and per-container Docker stats, with history and threshold alerts. It makes no outbound endpoint checks at all — no URL list, no status codes, nothing to point at a domain. Your site can be returning 500 to every visitor on Earth and Beszel will show you a perfectly healthy box, because the box is healthy.
What each one catches first
The split is easiest to see in the failures each one notices:
Uptime Kuma catches:
- the app crashed, or the container is in a restart loop
- a bad deploy that returns 500, or returns 200 with the wrong content
- expired TLS certificates and DNS that stopped resolving
- the whole machine going away — from the outside, that reads as "down"
Beszel catches:
- a disk filling up, days before it takes the service with it
- a memory leak climbing across a week
- CPU pinned by a runaway process, or load average that never comes down
- a drive reporting failing S.M.A.R.T. health, or a machine running hot
Only one of those two lists is about your users. Only one is about the thing that is going to page you at 3am.
What you run
Uptime Kuma is a single container with a data volume, and it is done. The one thing to get right is where it runs: a monitor on the same host as the service it watches cannot report that the host went down. Put it somewhere else, ideally on another provider.
Beszel is a hub plus one agent per machine. The hub is a Go binary built on PocketBase, so its database is embedded — no Postgres or MongoDB to provision, and backing up the data directory backs up everything. Adding a machine is a two-step: create the system in the hub, which issues a public key and a token, then run the agent installer on the target host with those values. The hub connects out to the agent, not the other way around, so the hub needs network reach to each machine.
Both are MIT licensed, and both are small — the catalogue estimates 512 MB for Uptime Kuma and 256 MB for Beszel's hub, with the agents smaller still. Running the pair costs you under a gigabyte, which is why "run both" is a real recommendation and not a cop-out.
Which should you self-host?
Reach for Uptime Kuma if…
- You publish something — a site, an API, a status page — and the question that matters is whether users can reach it.
- You need alerts on certificate expiry, DNS, or a specific string in a response.
- You want cron jobs and backups to check in, and to be told when one does not.
Reach for Beszel if…
- You run several machines and want one place showing CPU, memory, disk and container stats with history.
- The failures that hurt you are capacity failures: disks filling, memory leaking, a host running hot.
- You want machine monitoring without standing up a metrics database.
Run both if…
- You host anything real. The overlap is zero, the combined footprint is under a gigabyte, and each one is blind to exactly the failures the other catches.
Running either on a VPS
The placement rule differs for each, and it is the only sizing decision here. Beszel's hub can live anywhere with network access to your machines — including on one of them. Uptime Kuma should not: a prober sharing a host with its target goes down with it and reports nothing. The common arrangement is Beszel's hub on your main box with agents everywhere, and Uptime Kuma on the cheapest instance you can rent somewhere else. Put TLS in front of both. Setup steps and VPS options are linked below.