# Self-Host Uptime Kuma Anonymous VPS | FYRHost

> Run Uptime Kuma on a no-KYC KVM: Sentry at $7.50 list ($6.00 annual) gives 2 vCPU, 4 GB ECC, 60 GB NVMe. Compose plus a named volume. No ID at signup.

Source: https://fyrhost.com/guides/self-host-uptime-kuma-no-kyc/

[Home](https://fyrhost.com/) / [Guides](https://fyrhost.com/guides/) / Self-Host Uptime Kuma Anonymous VPS Ops guide

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

![self host uptime kuma anonymous vps — private Uptime Kuma on a no-KYC VPS](https://fyrhost.com/img/photo-nokyc-1.jpg) Run Uptime Kuma on a no-KYC KVM: Sentry at $7.50 list ($6.00 annual) gives 2 vCPU, 4 GB ECC, 60 GB NVMe. Compose plus a named volume.

Published 2026-08-30 · Updated 2026-10-09 · FYRHost Editorial · 19 min read

**Short answer** Run Uptime Kuma on a no-KYC KVM: Sentry at $7.50 list ($6.00 annual) gives 2 vCPU, 4 GB ECC, 60 GB NVMe. Compose plus a named volume.

FYRHost: VPS from $3/mo and dedicated from $30.80/mo annual. The map spans forty locations — Reykjavik (Iceland) and Zurich (Switzerland) among them, plus Singapore, Dubai, Cape Town and fourteen others. Signup is email plus a 12-character password, or token-only. No KYC. Checkout is crypto-only across BTC, XMR, ETH, BNB, SOL, LTC, TRX, XRP, DOGE, DASH, ADA, GRAM (TON), and USDT (TRC-20/ERC-20/BEP-20/SPL). No payload or guest traffic logs; connection metadata ≤24h. DDoS included. One SKN company, one crypto checkout. Deploy at https://fyrhost.com/deploy/.

## Why self-host the monitor at all

A SaaS monitor records everything you would rather keep to yourself: every target URL you watch, every incident note, every on-call name, and the response latencies of your own infrastructure as seen from their vantage. Hand a third party that dataset and you have centralized the most honest map of your weaknesses in someone else's database, under someone else's retention policy, purchasable by whoever their acquirer turns out to be. A copy of Uptime Kuma on a no-KYC KVM keeps that file on your disk instead — the monitors, the heartbeats and the incident history stay where you can delete them.

The app itself is a light `Node.js` dashboard: `HTTP`, `TCP` and `ping` probes, heartbeat history in a local `SQLite` database, push monitors for things that cannot be polled, and an optional public status page you can simply never enable. The full source lives in the [uptime-kuma repository](https://github.com/louislam/uptime-kuma), and the wiki there covers features this page does not. Running it costs you one small VPS and the discipline to treat the monitor as production infrastructure rather than a toy — which is the same discipline your main servers already demand of you.

The contract here is explicit about which half is whose. You rent a KVM slice with full root; the checker, its configuration and its data are yours, and nothing on this side touches the process after the invoice credits. Probe only targets you have a right to watch: the [acceptable use policy](https://fyrhost.com/aup/) bans attack traffic, and scanning strangers is attack traffic no matter how benign your dashboard labels it. For the account and payment side of the setup — the inbox, the wallet, the no-KYC flow — the [anonymous VPS guide](https://fyrhost.com/guides/anonymous-vps-crypto-no-kyc/) is the companion page.

Where this breaks: people self-host the monitor and then point its alerting webhooks at accounts that identify them, or publish a status page on a domain with their name in the WHOIS. Those are not uptime failures — the probes work fine — but they undo the privacy of the setup in one configuration screen. The sections that follow walk sizing, provisioning and exposure in the order that keeps both halves intact: quiet billing, then a boring, watchable, recoverable box.

VPS from $3* (fund $50+), storage 1–5 TB NVMe from $24/mo annual-eff, dedicated with IPMI from $30.80/mo. Crypto invoice, no KYC.

[Launch now](https://fyrhost.com/deploy/?kind=vps&plan=business/)

## Sizing: why Scout disappoints and Sentry holds

The cheapest plan on the table looks sufficient, and for a tiny setup it genuinely is: ten quiet monitors fit a single small slice with room to spare. The disappointment arrives on schedule — around monitor forty, when you add a reverse proxy in front of the dashboard, keep twelve months of heartbeat history and let the notification queue grow. Scout — `1 vCPU`, `2 GB` of ECC RAM, 40 GB NVMe, at $5.49/mo list ($3.00 on the annual term) — is that entry rung. SQLite pages, Node's heap and the proxy's workers all live in the same 2 GB, and the first thing a Linux box does under memory pressure is degrade the thing you bought it to do: watch things reliably.

The [Sentry plan at $7.50/mo list](https://fyrhost.com/cheap-vps/) (`$6.00` on the annual term) is the honest floor, buying 2 vCPU on an EPYC 7443P at 3.2 GHz, `4 GB` of DDR4 ECC, `60 GB` of local NVMe, unmetered 1 Gbps, one IPv4 plus a /64. ECC matters more on a monitor than it looks — a flipped bit in a heartbeat database is a false incident, and false incidents burn the trust that makes monitoring useful. A few dozen monitors with a reverse proxy and TLS fit comfortably; upgrade to Ranger ($12.50 list, $10.00 annual-eff, 4 vCPU / 8 GB) when previews, long histories and a second status page join.

Where this breaks: sizing by CPU. Uptime Kuma barely touches the processor — even a hundred HTTP probes at sixty-second intervals is light work — while the memory and disk curves move quietly with retention. Watch `free -m` and the database file size instead of load average, and decide your retention policy before the disk decides it for you. Snapshots ride checkout as an add-on and are your rollback tool; there is no managed backup service for guest volumes in this catalog, so the backup story in the persistence section is yours to run.

Whatever size you land on, the box has to arrive without a name attached — which makes provisioning the next decision rather than a checkout click.

## Provisioning the box without a name

Signup is deliberately thin: an inbox or an anonymous token plus a `12-character` password, no passport, no phone, no card. Checkout runs nineteen coins — XMR and BTC lead, USDT settles on seven networks, and a TRC-20 transfer typically credits at `1–3 min` and `19 blocks`. The VPS images about a minute after the credit lands, so the whole path from decision to root shell fits inside ten quiet minutes. If any of that flow is new, the [no-KYC purchase playbook](https://fyrhost.com/guides/anonymous-vps-crypto-no-kyc/) walks it step by step, from alias mail to first login.

Location is the one decision that changes what you buy with it. One list price covers all forty locations across four continents, with Iceland (+`20%`) and Switzerland (+`35%`) as the only published premiums — so you are choosing latency, not budget. Place the probe between yourself and your targets: a monitor for EU services belongs in Frankfurt or Amsterdam, one for a US fleet on the US coasts, and if your alert latency matters more than probe latency, put it near the people who get woken up. The probes themselves measure from the box's vantage, so a monitor in Reykjavik will honestly report slower responses than one in the same datacenter as the target — both are true numbers, and you should decide which truth you want on your dashboard.

The image is a standard Linux distribution with full root and nested virtualization enabled — Docker and Compose run without argument. Do the boring first hour immediately: key-only SSH with `PasswordAuthentication no`, default-deny firewall, unattended security upgrades, and a check of `ss -tulpn` so you know what is listening before anything else installs. The [hardening checklist](https://fyrhost.com/guides/vps-security-hardening-checklist/) covers the whole sequence; ten minutes there buys you a box that is quiet on the internet instead of loud in the abuse queue.

With a hardened, located, paid-for slice in hand, the deployment itself is one Compose file — and the file is short enough to argue about line by line.

## Docker Compose: the whole service in nine lines

Install Docker from your distribution's own packages rather than a convenience script, then run Uptime Kuma in Compose with two properties that matter more than any other setting: the dashboard binds to localhost, and the data lives on a named volume. The service definition fits in a screen — an image or local build for the source, `127.0.0.1:3001:3001` for the port mapping, `kuma-data:/app/data` for the volume, and an unless-stopped restart policy so the monitor survives the reboots it exists to observe. Bring it up with `docker compose up -d` and the first boot asks you to create the admin user in the browser.

Two of those lines deserve their rationale stated, because skipping them costs real incidents later. The localhost binding means the admin interface has no public surface until you deliberately put a proxy in front of it — the single most effective exposure decision on this page, made once, in the compose file. The named volume is what survives container recreation: images get rebuilt, compose files get edited, but `kuma-data` carries the database and uploads across all of it. Compose mechanics are documented in the [Docker Compose docs](https://docs.docker.com/compose/) if the file format is new to you.

Cap the logs while you are in there — a monitoring tool that runs for a year should not discover a 40 GB log file first. The json-file driver with `max-size: 10m` and `max-file: 3` bounds each container's logs to tens of megabytes forever, and it is the kind of setting that costs thirty seconds now and a Friday evening later. Then add monitors in deliberate order: the thing that pays you first, the thing that wakes you second, everything else as the list earns it.

Where this breaks: the bind-mount shortcut. Mounting a host directory over `/app/data` instead of using the named volume produces UID mismatches (the container runs as uid `1000`), permission errors after the first recreate, and a database that works until it does not. The named volume is also what your backups should read — which makes the next section, persistence, the one that decides whether a bad Tuesday costs you an hour or a year of history.

## Persistence: what lives in /app/data and how to back it up

Everything that matters about your monitoring setup lives in one directory: the SQLite database `kuma.db` with every monitor definition, heartbeat and incident, plus the `upload/` tree for icons and attachments. Lose the volume and you lose the entire configuration — monitors, thresholds, notification channels, history — so the backup job is not optional infrastructure, it is half the product. The consolation is that the dataset is small: even years of heartbeats rarely exceed a few hundred megabytes, which means your backup tooling can be simple, frequent and verified.

Back up a SQLite database correctly or not at all. A plain `cp` of a live database file can catch the file mid-write and produce a copy that restores as garbage — the failure only shows up when you need it, which is the cruelest possible timing. Use the built-in safe path: `sqlite3 /path/kuma.db ".backup '/backups/kuma-safe.db'`" produces a consistent snapshot while the app runs, and the technique is documented on the SQLite [backup page](https://www.sqlite.org/backup.html). Then ship the snapshot off-box with [restic](https://restic.readthedocs.io/en/stable/) or [Borg](https://borgbackup.readthedocs.io/en/stable/) — both deduplicate, encrypt client-side and are happy with a nightly cron — so the backup survives the box it protects. The [backup and restore guide](https://fyrhost.com/guides/vps-backup-and-restore/) covers the general pattern.

Where this breaks: the backup that has never restored. A nightly job that has never been tested is a hope, not a control; restore last week's snapshot into a scratch directory, mount it against a throwaway container, and confirm your monitors appear before you trust the setup with anything real. The second break is monotony of failure: a backup job writing to the same volume it reads dies with the volume, and a backup job to the same provider's snapshot system dies with the provider — the off-box copy is the one that earns its keep.

With the data safe, the remaining risk is exposure — the dashboard is an admin interface, and the next section is about keeping it that way.

## Exposure: localhost, a reverse proxy, and TLS

The dashboard is an authenticated admin interface with no business facing the internet directly, and the architecture should say so. Keep `3001` bound to loopback as configured, and put [nginx](https://nginx.org/en/docs/) in front of it for the public path — proxying to the local port, terminating TLS, and serving nothing else. A certificate from [Let's Encrypt](https://letsencrypt.org/docs/) makes the browser warning go away without buying anything, and the proxy pattern is the same one you would run for any internal tool: the app never listens publicly, the proxy decides who gets to knock.

If the box should stay quiet entirely, skip the public path and tunnel instead. [WireGuard](https://www.wireguard.com/quickstart.php) gives you the dashboard at the same local URL from your laptop, with zero public surface for scanners to find, index or bruteforce — the quick start is a fifteen-minute configuration, and this catalog's L3/L4 DDoS filtering is a floor for the network, not an L7 gatekeeper for your admin UI. The honest framing: a monitor does not need to be reachable, it needs to be *useful*, and you are the only audience the dashboard has until you deliberately publish a status page.

Where this breaks: the deliberate exceptions. Publishing a status page means one path — carefully chosen, on a domain whose WHOIS does not contradict the rest of this setup, with rate limits on the proxy — and it should never share the same hostname as the admin interface. Publishing nothing but leaving `0.0.0.0:3001` in the compose file is the worst of both: all surface, no convenience. After any change, verify what the world sees: `ss -tulpn` from inside, and an external port check from outside, so the listening set and the reachable set are both things you chose.

Exposure settled, the subtler problem remains: the monitoring itself is an activity observers can see, and the next section is about probing without announcing yourself.

## Probing without publishing yourself

Every probe departs from your VPS IPv4, and every target you watch sees and logs that address — this is the footprint, and no payment method changes it. An HTTP probe also announces a `User-Agent`, so assume the target can fingerprint the client as readily as the address. For most setups that is fine and honest: your monitor's IP is right there in the target's logs, plainly a monitor. What you can control is whether your probe IP also appears next to your name anywhere else — and the two places it tends to are status pages and notification channels, both of which publish associations the probes themselves never did.

The status page rule first: skip it on a domain whose `WHOIS` carries your name, because that pairs your quiet probe box with a loud identity in one DNS lookup, and certificate transparency logs do the rest. If you publish one at all, it goes on an anonymous domain, on a separate hostname, and it exposes the minimal set of monitors — not the internal list of everything you watch, which is itself a small map of your infrastructure worth protecting. The [anonymous website hosting](https://fyrhost.com/guides/host-website-anonymously/) guide covers the domain and publishing side if that layer is new to you.

Notification channels are the subtler leak, and they bite months later. A `webhook` into your personal Discord, a Telegram bot on your main account, an alert mail from your everyday address — each one ties the operator to the box in a third party's logs, and a screenshot in a public issue can carry that association further than you intended. Create the channel for the box: a dedicated Discord server or Telegram account, an alias on the same anonymous mailbox that receives the credentials. The [anonymous domain registration](https://fyrhost.com/guides/register-domain-anonymously/) guide pairs with this decision if a status page or alert domain is in your plans.

Where this breaks: convenience drift. The dedicated alert channel works until the day you are debugging at 2 a.m. and forward one alert to the account you actually read — and drift compounds, because the second forward is easier than the first. Decide once: the monitor talks to handles built for it, and if you want its alerts on your phone, the dedicated channel forwards, not your main accounts.

Quiet probing and quiet alerting are the privacy half; the operations half — alerts that fire when they should and stay silent when they should — is the next section.

## Alerts that arrive when it matters and sleep when it does not

The default monitor configuration is a false-alarm generator, and false alarms are not noise — they are the training data that teaches you to ignore the channel where the real outage will eventually arrive. A single failed check at a sixty-second interval is one lost packet with a pager attached. Uptime Kuma has the knobs to prevent this and they are two fields per monitor: the retry count before an alert fires, and the interval between retries. Set heartbeats at `60` seconds with `3` retries and an alert only fires after roughly `3 min` of confirmed failure — long enough to skip the blips, short enough to beat your users' first support message.

Per-monitor tuning beats global defaults, because workloads fail differently. A TCP check on a database port deserves tight intervals and fast escalation; a certificate-expiry check can run at a `24h` interval and still be useful weeks ahead; a `push` monitor for a cron job should alert on absence with a grace period measured in the job's own period, not in seconds. Put flapping targets into maintenance windows rather than disabling them — the window mutes alerting but keeps recording, so you keep the history that makes the post-mortem honest. And give every monitor a name that a tired person at 3 a.m. can act on: target, port, severity, who owns it.

Where this breaks: the opposite failure, the silent monitor. An alerting setup tuned so carefully that nothing has fired in six months is not evidence of reliability — it is evidence nobody has verified the alert path since setup. End-to-end test it once a quarter: stop a service on purpose, watch the retry schedule elapse, receive the alert on the device you will actually be holding at 3 a.m., then resolve and watch the recovery notice. Two minutes of manufactured downtime per quarter is the cheapest insurance the whole stack sells.

One probe box, however honest, is still one vantage point — and the moment your infrastructure spans regions, the monitor itself becomes a single point of failure worth solving.

## When one probe box is not enough

A single monitor answers "is it down" with a single opinion, and opinion is exactly what you get when the monitor shares a fate with the monitored. The classic trap: your fleet lives in one region, your probe box lives in the same region, and the network event that takes the region down takes your visibility down with it — the monitor reports nothing, which your alerting config interprets as everything being fine. The fix is geographic, and it is cheap: a second small VPS in another flag, watching the first box and a subset of the critical targets, turns every outage question from one opinion into two.

Size the second box for its actual job. A watcher-of-the-watcher needs almost nothing — Scout at $5.49/mo list ($3.00 on the annual-eff term) holds a heartbeat monitor, a push check and a handful of HTTP probes without breathing hard. Point one `push` monitor from the primary at the second box so absence-of-heartbeat is itself alertable, and accept the asymmetry: the second box watches fewer things, less often, and that is correct — its product is independence, not symmetry. Rent the second Scout in a different jurisdiction from your Sentry and the pair survives most single-fault scenarios, provider-level ones included.

Where this breaks: probe sprawl. Five boxes probing one service from five flags turns every two-second hiccup into a quorum debate, and you have rebuilt a SaaS monitor with more maintenance and worse caching. The workable escalation is by need: one primary at Sentry, one independent Scout as witness, and a third region only when your users demonstrably live in one. If history grows past what `60 GB` holds comfortably, the archive copy belongs on the [storage tiers](https://fyrhost.com/storage/) — 1 TB NVMe from `$24`/mo annual-eff — rather than on a forever-growing volume beside the database.

All of the above composes into one sequence, and the order is the part worth keeping — the deployment timeline follows.

## The Uptime Kuma deployment, in the order to run it

A week out, make the two decisions that shape everything after: the plan and the place. Sentry is the honest floor — $7.50/mo list, $6.00 on the annual term, 2 vCPU / 4 GB ECC / 60 GB NVMe — and the location should sit between you and your targets, since one list price covers all forty flags and only the premiums price differently. Sketch your monitor list on paper with its notification policy: what gets watched, at what interval, alerting to which dedicated channel after how many retries. Decide the retention policy now, because the answer changes the disk math and the backup size, and both are cheaper to change before monitors exist.

One day out, build the box in the order that keeps the quiet half quiet. Provision through the no-KYC flow — inbox or token, `12-character` password, a single crypto invoice, root about a minute after the credit lands. Harden before you install anything: key-only SSH with `PasswordAuthentication no`, default-deny firewall, unattended upgrades, and a first `ss -tulpn` you actually read. Then the stack: Docker from distro packages, the Compose file with `127.0.0.1:3001:3001` and the `kuma-data` named volume, log caps at `10m` across three files, and the stack brought up with `docker compose up -d`. Create the admin user, and if the dashboard ever leaves localhost, it does so behind your own proxy and TLS — or better, behind WireGuard, never publicly.

At the window, wire the monitoring like an operator. Add monitors in deliberate order — the revenue path first, the wake-you-at-night path second — each with its retry count and interval chosen for the workload rather than the default, each alerting into the dedicated channel you created for this box. Back up the volume before trusting it: one `sqlite3 .backup` snapshot shipped off-box with restic or Borg, and one restore into a scratch container to prove the copy is real. Schedule the quarterly alert-path drill in whatever calendar you actually read, and stand up the witness Scout in another flag once the primary has a calm week behind it. From there the maintenance loop is small on purpose: watch the memory and the database size monthly, test the restore quarterly, and let the thing you built to watch things do exactly that, unattended, from a rack that never learned your name.

Is Sentry enough for Uptime Kuma? Yes — 2 vCPU, 4 GB DDR4 ECC and 60 GB NVMe at $7.50/mo list ($6.00 annual-eff) comfortably carry a few dozen monitors plus a reverse proxy. Scout holds only very small setups; Ranger is the step when histories, previews and a second status page arrive.

Does FYRHost operate Uptime Kuma for me? No — you rent a KVM slice with full root and run Compose yourself, own the volume and keep the data. Nothing on the provider side touches the checker after the invoice credits, which is precisely the privacy property.

Should I publish a public status page? Only if you accept two exposures: the page is public, and it pairs your probe box's IP with whatever domain serves it. Bind the dashboard to localhost, tunnel in for admin work, and keep any status page on a separate, anonymous-domain hostname showing the minimal monitor set.

Where should the probe box live? Between you and your targets, weighted toward whoever gets alerted: EU targets want an EU probe, and a monitor that wakes people should live near them. One list price covers every flag, so latency — not budget — is the variable you are choosing.

How do I back up the Uptime Kuma data? Snapshot the SQLite database safely with the sqlite3 .backup command rather than a raw copy of the live file, then ship it off-box nightly with restic or Borg. Test the restore into a scratch container once before you trust it, and again quarterly after that.

Can I pay for the monitor without KYC? Yes — signup is an inbox or token plus a twelve-character password, checkout runs nineteen coins including XMR, BTC and USDT on seven networks, and the image is ready about a minute after a TRC-20 transfer credits.

## Primary sources

- [Uptime Kuma — official repository](https://github.com/louislam/uptime-kuma)
- [Docker Compose documentation](https://docs.docker.com/compose/)
- [SQLite backup documentation](https://www.sqlite.org/backup.html)

## Related guides

- [Minimum-data no-KYC checkout](https://fyrhost.com/guides/anonymous-vps-crypto-no-kyc/)
- [Buy a VPS with crypto](https://fyrhost.com/buy-vps-with-crypto/)
- [No-KYC VPS: requirements and limits](https://fyrhost.com/no-kyc-vps/)
- [Pay with Monero](https://fyrhost.com/monero-vps/)
- [Offshore VPS](https://fyrhost.com/offshore-vps/)
- [VPS vs dedicated bare-metal](https://fyrhost.com/guides/vps-vs-dedicated/)
- [Best no-KYC VPS 2026](https://fyrhost.com/best-no-kyc-vps-2026/)
- [FAQ: crypto VPS](https://fyrhost.com/guides/faq-crypto-vps/)

## More ways to pay

[Pay with Bitcoin](https://fyrhost.com/bitcoin-vps/) · [Pay with Monero](https://fyrhost.com/monero-vps/) · [Pay with USDT (TRC-20/ERC-20/SPL)](https://fyrhost.com/usdt-vps/) · [Pay with XRP](https://fyrhost.com/xrp-vps/) · [Pay with TRX](https://fyrhost.com/tron-vps/) · [Pay with Dogecoin](https://fyrhost.com/dogecoin-vps/) · [Pick the jurisdiction first](https://fyrhost.com/jurisdiction/).

## Checkout facts

- **Price** VPS from $3/mo. Dedicated from $30.80/mo.
- **Identity** No KYC. Token-only (no email) or email plus a 12-character password. No passport, phone, or card.
- **Payment** Nineteen ways to settle, none of them a card: XMR and BTC lead, ETH, SOL, LTC, BNB and TRX follow, then XRP, DOGE, DASH and ADA, GRAM (TON) for Telegram-adjacent rails, and USDT on seven networks — TRC-20, ERC-20, BEP-20, SPL, Polygon, Arbitrum, Optimism. Live-rate invoice.
- **Logs** No payload / no guest traffic logs. Billing and panel actions retained. Connection metadata ≤24h.
- **Platform** KVM on ECC and local NVMe. DDoS filtering included. Facilities in 40 cities across four continents — the locations table lists each one's tier, uplink and governing law. Need Iceland or Switzerland plus no KYC? Those two carry a published premium (+20% / +35%); every other flag stays at base list. Pay BTC, USDT, XMR, BNB, XRP, GRAM (TON) or 10 more. Open deploy to pick a plan.

## Ready to launch?

Build the box — VPS, storage or bare metal — create the password, pay the invoice that follows.

[Launch now](https://fyrhost.com/deploy/?kind=vps&plan=business/)[Dedicated](https://fyrhost.com/dedicated/)