Uptime Kuma VPS requirements: RAM, CPU, disk, and where to run it

Sizing guide

Our recommendations, derived from the sourced figures below. Not measurements.

Official requirements

What people report in practice

Individual reports, not controlled tests. Versions, hardware and settings differ, so treat these as data points, not guarantees.

• Uptime Kuma 2.5.7 (full image, SQLite) idled at 129 MiB with an admin account and no monitors, peaked at 146 MiB with 30 monitors (25 HTTP, 3 TCP, 2 ping) checking every 20 seconds, and hit 159 MiB at startup. CPU averaged 1.5% of one core under that load. The image is 617 MB compressed and 1.7 GB unpacked

  Third-party test site, median of three runs on a 2 vCPU GitHub Actions runner, 26 Oct 2026. Ten-minute window against a local nginx, so no DNS or TLS work and no long-term history

  Test site Self Host Bench: Uptime Kuma Docker Compose, 129 MiB idle, 30 monitors · checked Oct 28, 2026

• Uptime Kuma 1.x used 104.7 MiB with no monitors and 114–132 MiB with 60 monitors at a 60-second interval, about 0.19 MiB per monitor. CPU bursts reached 23.2% on a 2 vCPU VPS. The database grew about 359 bytes per heartbeat, about 30 MB a day for 60 monitors

  Blog test on a live 2 vCPU, 7.8 GiB VPS that also served five sites, 6 Sep 2026. Image tag louislam/uptime-kuma:1, so the disk figures describe v1 (see what drives disk use, below)

  Blog StackRecipes: Uptime Kuma on a $9 VPS, what 60 monitors actually cost · checked Oct 28, 2026

• Container RSS went from 102 MiB with 0 monitors to 106, 116 and 126 MiB with 50, 100 and 200 HTTP monitors, about 0.12 MiB per monitor, at 2–3% of 2 vCPUs. Another commenter runs about 250 monitors on a v2 beta as a systemd service with SQLite, averaging below 400 MiB. The original poster hit out-of-memory crashes on a 2 GB box with about 50 monitors on the embedded MariaDB, which a maintainer called "the biggest contributor"

  GitHub issue thread, June 2025 to Sep 2026. The 0–200 monitor test used 1.23.17 with SQLite and HTTP monitors only

  GitHub GitHub issue #5884: What are the minimum and recommended system requirements · checked Oct 28, 2026

• "We have an uptime instance running more than 110 monitors. It's been running on a 1 cpu/1gb VM for years now. Currently using 600mb of ram." Another user ran about 30 monitors on v1 in a 512 MB VM; after moving to v2 it "appeared to struggle more" with sporadic outages, needed 1 GB for the database migration, and has been "rock solid" at 1 GB since

  r/UptimeKuma thread, Feb 2026

  Reddit Reddit r/UptimeKuma: RAM on Proxmox for Uptime Kuma? · checked Oct 28, 2026

• "I have tested 700 (http + keyword) monitors on 4core and 6gb Ram with tunning mariadb work fine." Other replies run from 19 to 800+ monitors

  r/UptimeKuma thread, Feb 2025. One user's report; no memory figure given

  Reddit Reddit r/UptimeKuma: How many monitors? · checked Oct 28, 2026

• Memory grew from about 150 MB to more than 1 GB over days (3 GB and 6 GB in two reports) on 2.x installs with 12–23 monitors, and dropped back after each restart. The cause the maintainer reproduced was TCP monitors with a TLS or STARTTLS certificate check that left closed sockets referenced (one user counted about 4,900 socket handles). The maintainer released the fix in 2.5.5

  GitHub issue thread, June to Sep 2026, versions 2.2.1 to 2.5.4

  GitHub GitHub issue #7537: Memory of Uptime Kuma Slim is increasing over time · checked Oct 28, 2026

• With 34 monitors, 4 of them Browser Engine checks, and the embedded MariaDB and Chromium, a 2 GB container limit was reached within 24 hours and the container was OOM-killed repeatedly. A maintainer replied that the embedded Chrome has a memory leak "which we did not have time to debug"

  GitHub issue thread, Mar 2025, version 2.0.0-beta.1 (same on 1.23.16)

  GitHub GitHub issue #5654: too much virtual memory usage · checked Oct 28, 2026

What drives Uptime Kuma's RAM use

The Node.js floor, not the monitor count

An empty install sits at 100–130 MiB, and each ordinary monitor adds roughly 0.1–0.2 MiB in the tests above (#5884, StackRecipes). Going from 10 to 100 HTTP monitors barely changes the RAM line. What does change it is the kind of check.

Browser checks, big keyword pages and the database

The Browser Engine monitor runs a full Chromium, the heaviest thing Uptime Kuma can do. Keyword monitors keep the whole response in memory while they search it, so watching a large page every 20 seconds costs more than a small one. The embedded MariaDB in the full image is the largest single contributor, according to a maintainer in #5884. SQLite, the default, is the light option.

Disk: v2 keeps far less raw history than v1

Our reading of the 2.5.8 source, not a measurement: v2 deletes ordinary heartbeats older than 24 hours and keeps the last 100 per monitor plus status changes (database.js). Long-term charts come from summary tables: per-minute data for 24 hours, per-hour for 30 days, and per-day for the 365-day keep period (uptime-calculator.js). A SQLite incremental vacuum runs every 5 minutes. The multi-gigabyte projections you'll see for 50–200 monitors (2.2 GB to 8.8 GB at 180 days) were made on v1, which stored every heartbeat for the whole retention period. We haven't measured v2's database growth. The full image itself takes about 1.7 GB unpacked (Self Host Bench).

CPU is spiky, not heavy

Average CPU stayed at 1.5% of one core with 30 monitors at a 20-second interval, with short spikes when monitors start (Self Host Bench). Ping checks and short intervals cost the most CPU. One shared vCPU is enough for most personal setups.

Gotchas on a VPS

• Don't run it on the server it watches. A status page on the monitored machine reports everything fine until that machine dies, and then reports nothing (StackRecipes). Put Uptime Kuma on a separate small VPS, ideally at a different provider from your other servers. Checks from a single VPS come from one location, so an outage that only hits one region can be missed.
• It can't see your home network on its own. A VPS can check public URLs and ports, but not devices behind your router. For services at home, use Push monitors (your service calls Uptime Kuma on a schedule, and silence means down), or reach them over a tunnel or VPN such as Pangolin, Tailscale or WireGuard.
• Update to 2.5.5 or later. TCP port monitors with a TLS or STARTTLS certificate check leaked sockets and memory in 2.x releases before 2.5.5; users saw 150 MB grow to several GB (#7537). On a 1 GB VPS that ends in swapping or an OOM kill. Pin a current 2.x tag and set a container memory limit so a leak restarts the app instead of freezing the server.
• The first start waits for a database choice. Without UPTIME_KUMA_DB_TYPE, v2 opens a setup-database page on first visit and doesn't start monitoring until someone answers it. The container still reports healthy while it waits (Self Host Bench). Set UPTIME_KUMA_DB_TYPE=sqlite in the compose file if you deploy unattended.
• Port 3001 is public by default. The official compose file publishes 3001:3001 on every interface, and Docker's port rules bypass UFW, so a firewall that says "deny" doesn't protect it (StackRecipes). Bind it to 127.0.0.1 and put a reverse proxy with HTTPS and WebSocket headers in front (wiki), or use the provider's firewall.
• Use the slim image if you don't need Chromium. The 2-slim image is about 185 MB compressed against 617 MB for the full one, and leaves out the embedded MariaDB and Chromium (Docker Tags). On a 25 GB disk that difference adds up with every update.
• Keep the data folder on local disk. SQLite needs real file locks, so the docs rule out NFS (install wiki). Use the VPS's own disk or an attached block volume, not a network share.

Cheapest plans that fit

Uptime Kuma 2 with SQLite, ordinary monitors: 1 GB RAM and 1+ vCPU

Threshold: No official figure. Tests reported 102–159 MiB with up to 200 monitors, and a v2 user found 512 MB unstable and 1 GB solid (source). Only plans with at least 1 vCPU are listed.

Uptime Kuma 2 with Browser Engine checks or embedded MariaDB: 2 GB RAM and 1+ vCPU

Threshold: No official figure. Embedded MariaDB was named the biggest memory user, and four Chromium checks filled a 2 GB limit within a day, so 2 GB is a floor, not a guarantee (source). Only plans with at least 1 vCPU are listed.

Prices checked Oct 28, 2026 on each provider's official pricing page. EUR prices converted at the ECB rate of Oct 27, 2026 (1 € = $1.115) only for ranking. See all plans on the cheapest 4 GB VPS page.

Related pages

• Vaultwarden requirements: Watch your vault from outside: Uptime Kuma on a separate small VPS can check Vaultwarden's login page and certificate.
• n8n requirements: Uptime Kuma can send alerts to a webhook, so n8n can run follow-up workflows when a monitor goes down.
• Pangolin requirements: If your services live at home, Pangolin can publish them from a VPS, and Uptime Kuma can then check them from outside.
• Home Assistant requirements: Home Assistant has an Uptime Kuma integration (since 2025.8) that turns monitors into entities for dashboards and automations.
• Coolify requirements: Uptime Kuma is a one-click service in Coolify, but a monitor on the Coolify server can't report that server going down.