Self-Host Uptime Kuma on an Anonymous No-KYC VPS

Self-host Uptime Kuma on a no-KYC VPS. Starter is $6.80: 2 vCPU, 4 GB, 60 GB NVMe. Compose + volume. Deploy →

Published 2026-08-30 · Updated 2026-10-21 · BitCloudVPS Editorial

Why self-host Uptime Kuma

SaaS status pages see every probe: target URLs, incident notes, who is on-call. A copy you run on a no-KYC KVM keeps that file on your disk. Uptime Kuma is a small Node dashboard: HTTP/TCP/ping monitors, heartbeats, a status page if you turn one on. We rent root; we do not operate the checker. Legal targets only. CSAM and attacks are AUP fails. For checkout hygiene (inbox, wallet, tunnel) use the anonymous VPS guide.

Specs: Starter from $6.80

Catalog Starter (data.py): $6.80/mo, 2 vCPU (AMD EPYC 7443P / 3.2 GHz), 4 GB DDR4 ECC, 60 GB NVMe, unmetered / 1 Gbps, 1× IPv4 + /64. Same list price in all twenty-one locations. Nested virt is on, so Docker Compose is in-scope. Nano ($3, 1 vCPU / 2 GB) can run a quiet checker; Starter is the honest floor if you also keep a reverse proxy and a few dozen monitors. Included L3/L4 DDoS filtering is on the SKU; it is not an L7 WAF for the dashboard. Token-only or email + password; crypto invoice. Open the Starter plan from $6.80.

Docker Compose install

Install Docker from distro packages. Put the Uptime Kuma tree you already have on the box (scp/rsync). Do not paste marketplace or VCS clone URLs. Persist /app/data on a named volume so recreating the container does not wipe monitors.

# Save as docker-compose.yml next to ./uptime-kuma/
# Local build only. No registry or VCS URLs.
services:
  uptime-kuma:
    build:
      context: ./uptime-kuma
    container_name: uptime-kuma
    restart: unless-stopped
    ports:
      - "127.0.0.1:3001:3001"
    volumes:
      - kuma-data:/app/data
    logging:
      driver: json-file
      options:
        max-size: "10m"
        max-file: "3"
volumes:
  kuma-data:

# docker compose up -d

Bind 3001 to localhost until you put TLS in front. First boot: create the admin user in the UI, then add monitors. Snapshots are your rollback, not our managed backup SLA.

Monitor anonymously

The checker’s source IP is the VPS IPv4. Targets you ping will log that address. Do not put a public status page on a domain with real-name WHOIS if the point is a quiet probe box. Prefer SSH tunnel or WireGuard to the bound 3001 port instead of exposing the dashboard. Notification webhooks (Telegram, Discord, email) can name you — use a burner channel. Paying in crypto and skipping KYC does not anonymize the HTTP User-Agent Kuma sends. Harden sshd, then keep the dashboard off the public internet.

Need the checkout playbook again? anonymous VPS guide. Ready to size the box? Starter plan from $6.80.

Placement: why the monitor must not live where your infrastructure lives

The direct answer: a monitor that runs on the same server it watches is a smoke detector wired to the burning house — the single most common self-hosting mistake with Uptime Kuma. The whole point of the tool is independent observation, so rule one is: deploy Kuma on a separate box, from a separate provider or at minimum a separate network location, from everything it monitors.

The failure it prevents: your application crashes, the box goes down, and your monitor — running on that box — dies with it, so you learn about the outage when a user emails. Correlated failure is the entire threat model of monitoring. A second box on the same physical host or the same provider rack still shares failure domains: provider-wide incidents, network maintenance, DDoS on the shared edge taking down both. Different provider or, at minimum, different datacenter and uplink is the standard. With 21 locations on one checkout, putting the monitor in a different city from the workload is a dropdown choice, and the latency figures on each location page tell you what measurement bias to expect before you place it.

The anonymity angle is specific to no-KYC setups: the monitor holds your infrastructure's complete attack surface map — every URL, every port, every hostname — in one SQLite file. If your main servers are anonymous and the monitor is registered to your name, you have built a central index of your hidden infrastructure under your identity. The monitor box should be acquired through the same rails as what it watches: token-only signup, crypto payment, dedicated mailbox. One identity per monitoring domain, same as the nodes.

What the monitor box needs is modest: Kuma is a single Node.js process with a SQLite database — 1 vCPU, 1-2 GB RAM, 20 GB of disk is generous for years of check history at sane intervals. Network egress is the real resource: every check is an outbound request, so hundreds of monitors at short intervals add up to real traffic — one more reason the unmetered port matters on the watcher as much as on the watched.

Docker Compose install, updates, and the backup file

The direct answer: the install is a four-line compose file, updates are pull-and-up, and the state of the entire system is one SQLite file plus the upload directory — which makes backup, migration, and the anonymous-storage routine almost trivial. Run it in Docker unless you have a reason not to; the container isolates the Node runtime from the host and makes version pinning explicit.

The compose file, reduced to what matters:

services: kuma: image: louislam/uptime-kuma:1 (pin the major version; :latest is how monitoring dies during an unattended update), ports: - "127.0.0.1:3001:3001" — bind to localhost and put the real exposure behind a reverse proxy with TLS, not raw on the public port — and volumes: - ./data:/app/data so state lives in a directory you control, not an anonymous Docker volume. restart: unless-stopped so a host reboot self-heals. Bring it up with docker compose up -d, create the admin account on first visit, done.

Updates: docker compose pull && docker compose up -d, then check the release notes for migration notices — Kuma's SQLite migrations are one-way. This is why the update procedure starts with a backup: tar czf kuma-$(date +%F).tar.gz data/ captures everything (database, certificates, uploaded icons). Automate it nightly and ship the tarball off-box — to the storage line or a second small box on the same account. Restoring is untarring on a fresh host: a five-minute recovery you should test once, because a monitoring system you cannot restore is a single point of failure dressed as a safety net.

Hardening the setup: the admin panel is the keys to your infrastructure map, so the reverse proxy in front should enforce TLS, and admin credentials should be unique to this box — reused credentials from your main servers would link the monitor to the monitored in exactly the way its network placement tries to avoid.

Monitor design: intervals, retries, and notification rules that don't cry wolf

The direct answer: a monitoring setup is judged by its false-alarm rate, and three settings decide it — interval, retry count, and notification grouping. Get them right and alerts mean something; get them wrong and you mute the channel within a month, which is worse than no monitoring at all.

Intervals: match the check rate to the consequence. A personal site with no SLA does not need 20-second checks — 60 seconds is plenty and cuts your outbound traffic five-fold versus reflexive short intervals. Critical infra that pages you at night can run 30-60 seconds, but then retries must absorb transient blips: Kuma's default single-failure alerting is the false-positive factory. Set Retries to 2-3 so an alert fires only after consecutive failures, and configure Retry Interval so the re-checks happen faster than the normal cadence — the semantics are "fail fast in private, alert in public only when it's real."

Check types matter more than count. An HTTP(s) check should assert a keyword, not just a 200 — a reverse proxy happily returns 200 from an error page — and should validate the TLS certificate expiry warning, which turns Kuma into your certificate renewal nag for free. TCP/port checks for things HTTP can't see: databases, mail, SSH. DNS monitors for the record you depend on. Push monitors are the clever one for batch jobs: your cron script curls a unique URL on completion, and Kuma alerts when the push doesn't arrive — dead-man's-switch semantics for backups, where the failure mode is silence.

Notifications: one channel, well-routed, beats five channels half-ignored. Kuma supports dozens of integrations (Telegram, email, webhooks, and more); pick the one you actually read. Group alerts during incident storms — notification aggregation in the channel, plus Kuma's own status pages for the human-readable view — so a network blip touching twelve monitors produces one message, not twelve. And write the acceptance test into the setup: deliberately stop one non-critical service and confirm the alert arrives with the right severity. An untested notification path is a configuration, not a monitoring system.

Status pages, a second probe, and reading the latency numbers honestly

The direct answer: Kuma's public status pages and its per-monitor latency history are more useful than they first appear — one gives you a shareable incident record, and the other is a free network-quality dataset, provided you account for where the probe physically sits. Both features cost nothing but deliberate configuration.

Status pages: create one public page per audience rather than one giant list — a page for "services friends depend on" with the five monitors that matter beats exposing the complete infrastructure map. Decide the exposure carefully in a no-KYC context: a public status page is a public list of hostnames and endpoints you operate. If the infrastructure's existence is meant to be low-profile, keep the status page behind auth or omit hostnames from the public titles — Kuma lets you name monitors anything, so "API gateway" can stand in for the real URL. The incident-history view (uptime percentages, event log) is the part worth publishing; it turns "the site was down for you?" arguments into a factual record.

The second probe: one monitoring box gives you one vantage point, and a single vantage point cannot distinguish "service down" from "route to service down." The clean fix is a second Kuma instance in a different location monitoring the critical subset, with both feeding the same notification channel — two probes agreeing on an outage is a fact, one probe is a hypothesis. With locations across Europe, Asia, and the Americas on one checkout, pick the second probe where your users actually are, not where the server is.

Reading the latency history honestly: Kuma's graphs show round-trip time from the probe, which includes the probe's own distance and route. A monitor in Europe watching an Asian endpoint will read ~150-250 ms baseline regardless of server health; the number to watch is deviation from that baseline, not the absolute value. Sudden step changes in the baseline usually mean a route change upstream of your control — useful to know, and exactly the kind of thing you cannot see from inside the monitored box. That is the argument for the whole exercise: the monitor sees the network the way a user does, which is the only view that matters at 3 a.m.

Troubleshooting: false positives, cert errors, and a database that keeps growing

The direct answer: three failure patterns account for nearly all Kuma operational pain — false positives from thin retry settings, TLS-related check failures, and SQLite growth from heartbeat accumulation — and each has a diagnosis you can make from the UI plus a fix you apply once.

Symptom: monitors flip down briefly at random intervals, alerts fire, then everything recovers before you look. Cause: single-failure alerting plus transient network loss somewhere between probe and target — the default retry count of one turns every blip into a page. Fix: retries to 2-3, verify the probe box's own network is stable (ping -c 100 to a reliable anchor and read the loss), and if blips cluster at the same time daily, suspect provider-side maintenance windows rather than your service.

Symptom: HTTP monitors fail with certificate errors while browsers open the site fine. Cause: an incomplete TLS chain (browsers cache intermediates, Kuma's TLS stack fetches clean), an expired certificate Kuma noticed first — which is Kuma doing its job — or a certificate whose hostname doesn't match the monitor URL after a rename. Fix: diagnose with openssl s_client -connect host:443 and read the chain; if it's a self-signed internal endpoint you intentionally monitor, configure the monitor to ignore TLS errors — a deliberate, per-monitor decision, never a global one.

Symptom: the data directory grows by gigabytes over months. Cause: heartbeats — every check result is a row — plus stats history. At hundreds of monitors and 20-second intervals this is arithmetic, not a bug. Fix: lengthen intervals on monitors that don't need fast reaction, and archive or reset stats periodically; Kuma exposes a clear-stats function for exactly this. Symptom: the UI gets slow with many monitors. Cause: single-instance Node serving both checking and UI load. Fix is placement, not tuning: a second Kuma instance partitioning the monitor list by importance — critical infra on the fast box, everything else on the cheap one — keeps each instance responsive and gives you the two-vantage-point setup of the previous section for free.

The first ten monitors: an ordering that turns Kuma into documentation

The direct answer: the monitors you define in the first hour decide whether Kuma becomes infrastructure documentation or a random list of URLs — so add them in dependency order, one per failure mode you would actually act on. A monitor you would not wake up for, or stay up for, does not belong on the list.

1. The edge: your sites' public URLs, HTTP with keyword asserts. This is what users see failing, and it is the signal everything else explains.
2. TLS certificates on every hostname you serve, with expiry notification — expired certificates are the most common self-inflicted outage in self-hosting and Kuma warns weeks ahead.
3. DNS records you depend on — the domain's A record and the delegation chain. DNS breakage masquerades as total outage and has nothing to do with your servers.
4. The reverse proxy / ingress host as a TCP check, distinct from the sites behind it — this splits "site broken" from "network path broken" in one glance.
5. Each origin server itself (ICMP or SSH port), so a dead box is distinguishable from a dead service on a live box.
6. Databases and stateful services (PostgreSQL, Redis) on their local ports via a check from the box's own network path — or accepted-unreachable if you keep them firewalled, in which case a push monitor driven by a local cron stands in.
7. Backup jobs as push monitors — the dead-man's switch. A backup that stops running is the failure you will not notice for months any other way.
8. Certificate renewals, disk space, and other cron-driven health scripts as push monitors too: anything that runs on a schedule should prove it ran.

Two habits keep the list honest. Name monitors for the function, not the URL — "newsletter site" survives a hostname change, "web02.example.com" rots — and in a no-KYC setup the function name doubles as OPSEC, since the monitor list is exactly the infrastructure map you do not want published if the status page ever leaks. Second, review quarterly: retire monitors for dead services, and when you add a service, adding its monitor is part of the deploy checklist, not a follow-up. A monitor added "later" is a monitor that documents nothing during the first incident — which is, of course, the only time documentation matters.

Uptime Kuma as the watcher that nobody links to you

Uptime Kuma is a light workload — a Node service, a SQLite database, a heartbeat loop — and the sizing rule is that almost any tier outruns it. Starter at $6.80/mo annual (2 vCPU, 4 GB ECC, 60 GB NVMe) monitors hundreds of targets comfortably; even the $36/yr Nano runs a modest instance. What the choice of host actually changes for a monitoring box is threefold. Independence: your watcher must not share fate with the watched, which argues for racking it away from your production boxes — with 21 locations at identical prices, a watcher in IS-RKV watching production in DE-FRA is the pattern, and the failure-domain separation costs nothing extra. Reachability: monitors probe over the network constantly, and unmetered 1–10 Gbps ports make the probe traffic — thousands of small checks a day — invisible on the bill. And identity: a monitoring system that alerts you when infrastructure misbehaves is exactly the asset you do not want subscribed to your name through a card processor.

That last point is where the no-KYC checkout earns its place in the design: token signup, optional email, 19 crypto assets at settlement, Harborline Node Ltd. of Saint Kitts and Nevis as the operator of record — the monitoring layer contributes no identity link to the map an adversary could draw. Two deployment notes complete it. Notifications: Kuma's alert channels (webhooks, messaging bridges) are correlation surfaces of their own, so route them through identities established for the purpose rather than your personal accounts. And TLS: the Kuma web UI should sit behind your own certificate or a WireGuard tunnel rather than a public cert that logs the hostname into Certificate Transparency — a discipline this site's limits page applies everywhere. Probe targets over IPv4 or the /64 IPv6 block each VM carries; both faces are standard on the sheet. Sixty seconds of deployment is the entire cost of finding out.

Where the limits are (October 2026)

Keep the threat model precise. Anonymous-adjacent hosting removes the host-side identity trail: token-only signup, optional email, no KYC review, crypto invoices that record a txid rather than a name. It does not blind the host to traffic it must carry, it does not make a logged-in panel session anonymous, and it does not protect workloads that identify themselves — an admin login from your home IP defeats the whole design. Exact limits of no-KYC anonymity. OPSEC guide. Full checklist. Payment-side note: chain analysis happens on public blockchains, not at the host. Coin choice and network choice are your OPSEC knobs, and the checkout keeps 19 of them open.