Vereisten van Uptime Kuma: hoe groot een server, en waar je het draait

De vereisten van Uptime Kuma zijn klein, en waar het draait is belangrijker dan hoe groot de server is. Een monitor die samen met je sites uitvalt, kan je niet vertellen dat ze offline zijn. Begin dus met de plek, kies dan de servergrootte en richt alles in de juiste volgorde in.

Waar het moet draaien

Softwarebureau Sandstorm Media liep hier tegenaan toen het overstapte van UptimeRobot naar Uptime Kuma. Het wilde de monitor nergens in de buurt van de eigen servers hebben en kocht daarom een cloudserver in een ander land.

Zet Uptime Kuma op een server die geen van de sites, apps of databases draait die het controleert. Als de server van een site door zijn geheugen heen raakt, een deploy misgaat of een database niet meer reageert, gaat de monitor niet mee onderuit en krijg je nog steeds de melding.

Een van de beheerders van Uptime Kuma legt de lat hoger: je should not co-locate your uptime status page on the same infrastructure, datacenter or credit card. Draaien je sites al op VPS-servers van DreamHost, dan deelt een tweede server voor Uptime Kuma hun datacenter, want volgens het Help Center van DreamHost wordt elke VPS gehost in het datacenter US East in Ashburn, Virginia. Hij staat ook op dezelfde rekening. Worden je sites bij een ander bedrijf gehost, dan staat hij volledig los van hun infrastructuur. Hoe dan ook voeg je in de stappen hieronder één externe controle toe, en die laat je weten als het datacenter of Uptime Kuma zelf op zwart gaat.

Hoe groot de server moet zijn

Uptime Kuma publiceert geen minimumvereisten. De README vraagt om Node.js 20.4 of nieuwer bij installaties zonder Docker en houdt het daarbij, en een gebruiker kon nergens in de documentatie een RAM- of CPU-cijfer vinden. Daarom hebben we het zelf gemeten. Op 21 en 22 oktober 2026 draaiden we Uptime Kuma 2.5.6 in Docker met het compose.yaml van het project zelf en de standaard SQLite-database. Dat deden we op onze testmachine met 2 vCPU en 4 GB (arm64), dus niet op een server van DreamHost. Dat is dezelfde opbouw als Stack 4.

Zonder monitors gebruikte het ongeveer 200 MiB geheugen. Daarna voegden we 200 websitemonitors toe met de standaardinstellingen: een controle elke 60 seconden, zonder nieuwe pogingen. Alle 200 werden zonder fouten toegevoegd. Na 15 minuten controleren gebruikte de container 237 MiB en 0,45% van de CPU, en was er nog 3.408 MB van de 3.904 MB van de machine vrij. Onze controles riepen een kleine testpagina op dezelfde machine aan, dus echte sites met HTTPS en omleidingen kosten iets meer. De test draaide één keer, 15 minuten lang, en zegt dus niets over maanden aan geschiedenis.

Een GitHub-gebruiker mat ongeveer 126 MiB voor 200 controles op versie 1, op een server van dezelfde grootte, en een andere gebruiker in dezelfde thread draaide ongeveer 250 monitors op een bèta van versie 2, met gemiddeld minder dan 400 MiB.

Schijfruimte is waar je op moet letten. Elke controle schrijft een resultaat weg, dus de database groeit met het aantal monitors, met hoe vaak ze controleren en met hoe lang je de geschiedenis bewaart. Op de server van DreamHost kun je die een jaar of voor altijd bewaren. De gebruiker die 9 GB schatte, noemde het an order of magnitude, omdat de schatting op een steekproef van 11 minuten was gebaseerd. Onze datamap groeide van 1,4 MB leeg naar 5 MB na het toevoegen van 200 monitors en 15 minuten controles, te kort om maanden vooruit te schatten. Stack 4 heeft 75 GB schijfruimte, dus controleer df -h in het begin elke maand of twee. Groei je eruit, dan kun je overstappen naar een groter Stack-abonnement, en je omgeving verhuist mee.

Hoe je het dashboard bereikt

De eigen reverse-proxygids van Uptime Kuma raadt een gewone webserver met HTTPS ervoor aan en noemt Caddy als een server die zelf certificaten aanvraagt en vernieuwt. De Uptime Kuma-server van DreamHost is zo gebouwd: je bereikt het dashboard via Caddy, met echte HTTPS op het IP-adres van de server.

Statuspagina's en badges zijn bedoeld om openbaar te zijn, dus ze blijven bereikbaar zonder in te loggen.

Stap voor stap instellen

Je voert de onderstaande opdrachten uit als root, of zet er sudo voor als je inlogt als een andere gebruiker.

Inloggen en bijwerken

1. Geef het een server die verder niets host

   Bestel Stack 4 met Uptime Kuma, de keuze van DreamHost voor deze taak, en gebruik die server alleen voor de monitor.

2. Lees de login uit die bij de eerste start is aangemaakt

   Het beheerderswachtwoord wordt aangemaakt bij de eerste keer opstarten, nog voordat het dashboard bereikbaar is. Maak via SSH verbinding met de server en toon het wachtwoord:

   bashKopiëren

   cat /root/.uptime_kuma_credentials

   Log via HTTPS in op het IP-adres van je server. Bewaar het wachtwoord in een wachtwoordmanager. Statuspagina's kunnen later elk een eigen domein krijgen.

3. Werk bij voordat je iets toevoegt

   Een nieuwe server start op de versie die DreamHost heeft vastgezet en getest, en die kan achterlopen op de nieuwste release van Uptime Kuma. Het updatescript maakt zelf geen back-up, dus maak eerst een back-up:

   bashKopiëren

   uptime-kuma-backup
   uptime-kuma-update

   De updater blijft op versie 2 en springt niet zonder jou naar een nieuwe hoofdversie. Op 15 oktober 2026 was 2.5.6 de nieuwste release van Uptime Kuma.

Inloggen en meldingen instellen

1. Zet inloggen in twee stappen aan

   Ga naar Settings, dan Security, en klik op 2FA Settings. Uptime Kuma toont een QR-code die je scant met een authenticatie-app en vraagt daarna om een code uit de app ter bevestiging.

2. Laat Uptime Kuma Caddy vertrouwen

   Ga naar Settings, dan Reverse Proxy, dan HTTP Headers, en zet Trust Proxy op Yes als dat nog niet zo is. De reverse-proxygids van Uptime Kuma geeft deze instelling voor servers die alleen bereikbaar zijn via een webserver die ervoor staat. Je logs tonen dan het echte adres van elke bezoeker.

3. Voeg een melding toe, daarna je monitors

   Een uitgevallen monitor verschijnt alleen op het dashboard, totdat je onder Settings, dan Notifications, een meldingsdienst toevoegt. Koppel eerst e-mail, Slack of Telegram en maak daarna je monitors aan.

Houd de monitor in de gaten en bewaar een kopie

1. Richt één externe controle op Uptime Kuma

   Het gratis abonnement van UptimeRobot omvat 50 monitors met controles elke 5 minuten, en een daarvan kan je Uptime Kuma-adres in de gaten houden. Een reageerder op Hacker News gebruikt UptimeRobot precies hiervoor: I only use it to monitor the Uptime Kuma that monitors the rest of my homelab.

   Een heartbeat werkt ook. Het gratis abonnement van Healthchecks.io bewaakt 20 taken, en de Shell-documentatie geeft een curl-regel om de dienst te pingen. Zet er een snelle lokale controle voor, zodat de ping alleen uitgaat als Uptime Kuma reageert. Voeg de regel daarna toe aan de crontab van de server met crontab -e:

   bashKopiëren

   */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

   Die heartbeat bewijst dat de server, de geplande taken en de app draaien. De controle van UptimeRobot bevestigt daarnaast dat het dashboard van buitenaf via HTTPS reageert. De betaalde abonnementen van UptimeRobot vind je in onze gids over de prijzen van UptimeRobot naast Pingdom en Better Stack.

2. Kopieer elke back-up van de server af

   De migratiegids voor v2 van Uptime Kuma noemt een kopie van de datamap de enige ondersteunde back-up. uptime-kuma-backup maakt er een als lokaal archief en toont waar het dat heeft opgeslagen. Kopieer dat bestand vanaf je eigen computer:

   bashKopiëren

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

   Log je in als een andere gebruiker dan root? Kopieer het archief dan eerst met sudo cp naar je thuismap en maak jezelf met sudo chown eigenaar, voordat je het downloadt.

   Het script schrijft het archief naar dezelfde schijf als Uptime Kuma. Met die kopie kom je terug na een mislukte update, maar ze helpt je niet als je de server kwijtraakt. Laat haar daar dus niet staan.

3. Volg nieuwe releases

   Debian werkt zichzelf op de achtergrond bij. De container van Uptime Kuma werkt zichzelf niet bij, dus elke nieuwe release wacht tot je de twee updateopdrachten opnieuw uitvoert. Volg de releases van Uptime Kuma via het Watch-menu van de repository op GitHub, en werk bij naar de nieuwste release zodra er een verschijnt.

Veelgestelde vragen over Uptime Kuma-hosting