Monitoring · no KYC
Host Uptime Kuma on an Offshore VPS
Run your own uptime monitor and public status page on an offshore VPS, with no third-party SaaS holding your endpoint list or your identity.
What it is
Uptime Kuma is a self-hosted monitoring tool that checks the availability of your websites, APIs, TCP ports, DNS records, and containers, then alerts you when something goes down over 90+ notification channels. It ships a clean web dashboard and can publish public or private status pages, all backed by a single embedded SQLite database.
Why host it offshore
A monitoring server holds a full map of your infrastructure — every hostname, IP, port, and API key you watch — so where it lives and who can subpoena it matters. Hosting Uptime Kuma on a no-KYC, crypto-paid offshore VPS keeps that inventory off SaaS dashboards and out of the jurisdiction your production sits in, while unmetered bandwidth makes constant polling free.
The deploy
A working reference setup
Copy this onto a fresh ChainVPS instance. Replace the placeholders, then bring it up.
# 1) Install Docker + compose plugin (Ubuntu 24.04)
# curl -fsSL https://get.docker.com | sh
#
# 2) docker-compose.yml — Uptime Kuma behind Caddy for automatic HTTPS
# Replace status.example.com with your domain (A record -> this VPS).
services:
uptime-kuma:
image: louislam/uptime-kuma:1
container_name: uptime-kuma
restart: unless-stopped
volumes:
- ./uptime-kuma-data:/app/data
# Bound to loopback: only Caddy reaches it, never the public internet.
ports:
- "127.0.0.1:3001:3001"
caddy:
image: caddy:2
container_name: caddy
restart: unless-stopped
ports:
- "80:80"
- "443:443"
volumes:
- ./Caddyfile:/etc/caddy/Caddyfile:ro
- caddy-data:/data
- caddy-config:/config
volumes:
caddy-data:
caddy-config:
# 3) Caddyfile (same directory) — TLS is issued automatically:
# status.example.com {
# reverse_proxy uptime-kuma:3001
# }
#
# 4) docker compose up -d
# Open https://status.example.com and create the admin user
# on first visit (do this immediately — the setup screen is unauthenticated).Firewall
Ports to open
| Port | Protocol | Purpose |
|---|---|---|
| 3001 | TCP | Uptime Kuma web UI / WebSocket — keep bound to 127.0.0.1, never expose publicly |
| 443 | TCP | HTTPS via reverse proxy (Caddy/nginx) — the only inbound port users need |
| 80 | TCP | HTTP, used only for ACME/Let's Encrypt certificate issuance and redirect to 443 |
Right-sizing
Which plan you need
VPS Nano / Small (1 vCPU, 1-2 GB RAM)
Personal use, up to ~50 monitors at 60s intervals. Uptime Kuma idles at a few hundred MB.
VPS Pro (2-4 vCPU, 4-8 GB RAM)
Small team, a few hundred monitors plus several public status pages and frequent checks.
VPS Pro (large) or entry Dedicated
1000+ monitors at short intervals. SQLite write contention becomes the limit — give it fast NVMe and a full CPU core, and lengthen check intervals before adding RAM.
Best locations: Pick a privacy-tier location (NL, CH, RO, IS, MD, LU) so the box that stores your full endpoint inventory sits in a friendly jurisdiction — NL and CH also have excellent connectivity, which keeps probe latency low and false-positive alerts down. If you monitor targets concentrated in one region, a well-connected location near them gives the most accurate up/down signal.
Lock it down
Hardening checklist
- Never expose port 3001 to the internet. Bind it to 127.0.0.1 (as above) and reach the UI only through the TLS reverse proxy; add a UFW rule allowing just 80/443 and SSH.
- Create the admin account on first visit immediately after `up -d` — the initial setup page has no authentication, so anyone who loads the UI before you can seize the instance. Then enable 2FA under Settings > Security.
- Back up ./uptime-kuma-data regularly (it is a single SQLite DB). Stop the container or use Uptime Kuma's built-in backup before copying to avoid a half-written database, and store copies off the monitoring box.
- Keep public status pages minimal — they can leak internal hostnames and IPs. Use private status pages or per-page access, and give monitors generic display names rather than real server hostnames.
- Route alerts through a channel that does not tie back to your identity (a dedicated Telegram bot or self-hosted Apprise/ntfy) rather than a personal email, and treat notification tokens in the DB as secrets.
- Pin the image to the `1` major tag and run `docker compose pull && up -d` on a schedule; watch the project's release notes since Uptime Kuma is under active development.
Deploy it on
The right ChainVPS product
Questions
Hosting Uptime Kuma — FAQ
Does Uptime Kuma need a separate database server?
No. It uses an embedded SQLite database stored in /app/data, so the single container plus a data volume is the whole stack. That is also why a fast disk matters more than lots of RAM at high monitor counts.
Why put it behind Caddy or nginx instead of just opening port 3001?
Uptime Kuma serves plain HTTP on 3001 with no TLS of its own. A reverse proxy adds automatic HTTPS, keeps the app on loopback, and lets you add access controls — exposing 3001 directly would send your admin login over unencrypted HTTP.
Can it monitor servers in other countries from a ChainVPS box?
Yes. Monitoring is outbound — the VPS reaches out to your targets over HTTP(S), TCP, ICMP ping, DNS, and more. Unmetered bandwidth means frequent checks cost nothing, and a well-connected location keeps latency-based false alerts low.
How much resource does it actually use?
An idle instance with a handful of monitors runs comfortably in about 200-400 MB of RAM on a single vCPU. Usage scales with the number of monitors and how often they run, so lengthen intervals before upgrading hardware.
Will my status page and endpoint list stay private?
That is under your control. Status pages are opt-in and can be private; the monitor list lives only in your SQLite DB on the VPS. On a no-KYC offshore host there is no third-party SaaS copy of what you monitor and no identity tied to the account.
More to self-host
Other one-click stacks
Spin up Uptime Kuma
in the next 60 seconds.
Unmetered bandwidth · DDoS included · 21 cryptocurrencies · no KYC.