Uptime Kuma requirements: how big a server, and where to run it

Uptime Kuma's requirements are small, and where it runs matters more than its size. A monitor that goes down with your sites can't tell you they're down, so start with placement, then size the server and set it up in order.

Where it should run

Sandstorm Media, a software agency, ran into this when it moved from UptimeRobot to Uptime Kuma. It didn't want the monitor anywhere near its own servers, so it bought a cloud server in another country.

Put Uptime Kuma on a server that runs none of the sites, apps or databases it checks. If a site's server runs out of memory, a deploy breaks, or a database stops answering, the monitor won't go down with it, and you'll still get the alert.

One of Uptime Kuma's maintainers sets the bar higher: you should not co-locate your uptime status page on the same infrastructure, datacenter or credit card. If your sites already run on DreamHost VPS servers, a second one for Uptime Kuma shares their data center, because DreamHost's Help Center says every VPS is hosted in its US East data center in Ashburn, Virginia. It's on the same bill too. If your sites are hosted with another company, it's fully off their infrastructure. Either way, you'll add one outside check in the setup steps below, and that check tells you if the data center or Uptime Kuma itself goes dark.

How big a server it needs

Uptime Kuma doesn't publish a minimum. Its README asks for Node.js 20.4 or newer on installs without Docker and stops there, and one user couldn't find a RAM or CPU figure anywhere in the docs, so we measured it. On Oct 21 and 22, 2026, we ran Uptime Kuma 2.5.6 in Docker from the project's own compose.yaml, with its default SQLite database, on our test machine with 2 vCPU and 4 GB (arm64), not a DreamHost server. That's the same shape as Stack 4.

With no monitors, it used about 200 MiB of memory. We then added 200 website monitors at the defaults, a check every 60 seconds with no retries, and all 200 went in without errors. After 15 minutes of checks, the container used 237 MiB and 0.45% of the CPU, and 3,408 MB of the machine's 3,904 MB was still free. Our checks hit a tiny test page inside the same machine, so real sites with HTTPS and redirects cost a little more. It ran once, for 15 minutes, so it says nothing about months of history.

A GitHub user measured about 126 MiB for 200 checks on version 1, on a server the same size, and another user in the same thread ran about 250 monitors on a version 2 beta at under 400 MiB on average.

Disk is the thing to watch: every check writes a result, so the database grows with how many monitors you run, how often they check, and how long you keep history. On DreamHost's server you can keep a year of it or keep it forever. The user who projected 9 GB called it an order of magnitude, since it came from an 11-minute sample. Our data folder went from 1.4 MB empty to 5 MB after adding 200 monitors and 15 minutes of checks, too short a sample to project months from. Stack 4 has 75 GB of disk, so check df -h every month or two at first. If you outgrow it, you can move up to a larger Stack plan, and your environment moves with you.

How you reach the dashboard

Uptime Kuma's own reverse proxy guide recommends a regular web server in front with HTTPS, and names Caddy as one that gets and renews certificates on its own. DreamHost's Uptime Kuma server is built that way: you reach the dashboard through Caddy, with real HTTPS on the server's IP.

Status pages and badges are meant to be public, so they stay reachable without a login.

Set it up, step by step

You'll run the commands below as root, or put sudo in front if you sign in as another user.

Sign in and update

1. Give it a server that hosts nothing else

   Order Stack 4 with Uptime Kuma, DreamHost's pick for this job, and keep that server for the monitor alone.

2. Read the login made at first boot

   The admin password is generated at first boot, before the dashboard can be reached. SSH into the server and print it:

   bashCopy

   cat /root/.uptime_kuma_credentials

   Sign in at your server's IP over HTTPS. Keep the password in a password manager. Status pages can each go on a domain of their own later.

3. Update before you add anything

   A new server starts on the version DreamHost pinned and tested, which can trail Uptime Kuma's newest release. The update script takes no backup of its own, so run the backup first:

   bashCopy

   uptime-kuma-backup
   uptime-kuma-update

   The updater stays on version 2 and won't jump a major version without you. As of October 15, 2026, Uptime Kuma's newest release was 2.5.6.

Set up sign-in and alerts

1. Turn on two-factor sign-in

   Go to Settings, then Security, and click 2FA Settings. Uptime Kuma shows a QR code to scan with an authenticator app, then asks for a code from the app to confirm.

2. Tell Uptime Kuma to trust Caddy

   Go to Settings, then Reverse Proxy, then HTTP Headers, and set Trust Proxy to Yes if it isn't already. Uptime Kuma's reverse proxy guide gives this setting for servers reached only through a web server in front. Your logs then show each visitor's real address.

3. Add a notification, then your monitors

   A down monitor only shows on the dashboard until you add a notification service under Settings, then Notifications. Connect email, Slack or Telegram first, then create your monitors.

Watch the monitor and keep a copy

1. Point one outside check at Uptime Kuma

   UptimeRobot's free plan covers 50 monitors at 5-minute checks, and one of them can watch your Uptime Kuma address. One Hacker News commenter runs UptimeRobot for exactly this: I only use it to monitor the Uptime Kuma that monitors the rest of my homelab.

   A heartbeat works too. Healthchecks.io's free plan watches 20 jobs, and its shell docs give a curl line to ping it. Put a quick local check in front of it so the ping only goes out while Uptime Kuma answers, and add the line to the server's crontab with crontab -e:

   bashCopy

   */5 * * * * curl -fsS -m 5 -o /dev/null http://127.0.0.1:3001 && curl -fsS -m 10 --retry 5 -o /dev/null https://hc-ping.com/your-uuid-here

   That heartbeat proves the server, its scheduled jobs and the app are running. The UptimeRobot check also confirms the dashboard answers over HTTPS from outside. UptimeRobot's paid plans are in our guide to UptimeRobot pricing next to Pingdom and Better Stack.

2. Copy each backup off the server

   Uptime Kuma's v2 migration guide calls a copy of the data directory the only supported backup, and uptime-kuma-backup makes one as a local archive and prints where it saved it. From your own computer, copy that file down:

   bashCopy

   scp YOUR-USER@YOUR-SERVER-IP:/path/printed/by/the/script.tar.gz .

   If you sign in as a user other than root, copy the archive to your home folder with sudo cp and take ownership of it with sudo chown before you download it.

   The script writes its archive to the same disk as Uptime Kuma. That copy gets you back from a bad update, but it won't help if you lose the server, so don't leave it there.

3. Follow new releases

   Debian patches itself in the background. The Uptime Kuma container doesn't update itself, so each new release waits until you run the two update commands again. Follow Uptime Kuma's releases from the repository's Watch menu on GitHub, and update to the latest release when one ships.

Uptime Kuma hosting FAQs