Self-Host Uptime Kuma on a VPS With Nginx HTTPS

Most “uptime monitoring” SaaS plans charge you for basics you can run yourself. Think a handful of HTTP checks, a few alert channels, and a status page.

If you already operate a VPS or dedicated server, it’s often cleaner to self-host Uptime Kuma. You keep monitoring close to your infrastructure. You also control retention rules and notification routes.

Uptime Kuma is a self-hosted monitoring dashboard for websites, APIs, and TCP services. It runs scheduled checks, tracks incidents over time, pushes alerts to common notification tools, and can publish a public status page.

It fits production WordPress sites, customer apps, internal services, or a small server fleet. You get quick “is it up?” answers without another monthly bill.

Uptime Kuma in plain terms: what it solves, and who it’s for

Uptime Kuma is built for day-to-day operational clarity. You define monitors for HTTP(S), TCP ports, ping, DNS, keyword matching, and more.

Then you set check intervals and retries. Finally, you route alerts to channels your team will actually notice.

• Website owners: catch DNS mistakes, SSL renew failures, expired domains, broken WordPress updates, and upstream outages.
• Application operators: monitor API health endpoints, worker ports, and third-party dependencies routed through your stack.
• Server admins: watch SSH reachability, database ports, and reverse-proxy endpoints from outside your network.

Licensing is refreshingly simple. Uptime Kuma is open source under the MIT License, so you can run it commercially and modify it with minimal restrictions.

How self-host Uptime Kuma compares to hosted monitoring

Hosted monitoring tools usually win on global probe networks and polished incident workflows. Uptime Kuma wins on cost, control, and privacy.

You also avoid getting boxed in by a vendor’s data model for monitors and incident history.

• Replace or complement SaaS: run Kuma as your main monitor set, or pair it with a small SaaS plan for multi-region confirmation.
• Data ownership: your targets, auth headers, and logs stay on your server.
• Status pages: publish a basic status page without paying per component.

Be honest about the tradeoff. If your monitoring VPS sits in the same region as your app, it can miss regional routing problems.

Many operators host Kuma in a different location than the application. Another option is a second small instance for redundancy.

What you’ll run it on (and why a VPS is the default)

Uptime Kuma is lightweight, but it’s still production software. It needs stable storage, sensible backups, and HTTPS.

A small VPS is the practical baseline.

If you already host customer workloads, consider putting monitoring on its own VM. That way, an application incident (or a runaway disk) doesn’t take your monitors down with it.

If you want a clean, always-on host with predictable resources, a HostMyCode VPS is the straightforward choice.

If you’d rather avoid handling OS patching and baseline maintenance yourself, managed VPS hosting keeps the underlying server in better shape. You can stay focused on monitors and incident response.

Resource requirements that hold up in real use

Your monitor count and check frequency drive the real requirements. The UI stays responsive on modest hardware.

Short intervals increase CPU wakeups and grow the database faster.

• Small setup (up to ~50 monitors at 60s intervals): 1 vCPU, 1 GB RAM, 10–20 GB SSD.
• Medium (~200 monitors, mixed intervals, several notifications): 2 vCPU, 2 GB RAM, 30+ GB SSD.
• Busy (hundreds of monitors + aggressive intervals + status page traffic): 2–4 vCPU, 4 GB RAM, 40+ GB SSD.

Disk is the quiet constraint. If you keep long history and run frequent checks, set retention expectations early.

Also watch volume usage over time.

If your Docker host runs other services, plan regular cleanup of unused images and logs. (If you’ve ever had a VM go read-only from a full disk, keep this handy: Disk space troubleshooting on a Linux VPS.)

Deploy to a VPS with Docker Compose (minimal moving parts)

This is a blog post, not a recipe card. Still, your deployment should survive routine maintenance.

A simple production layout looks like this:

• Uptime Kuma container on an internal Docker network
• Nginx on the host (or in a separate container) as the public reverse proxy
• Let’s Encrypt certs managed by Certbot
• Named volume for persistent data

On Ubuntu 24.04/24.10 or Debian 12/13, install Docker Engine and the Compose plugin. Then create a project directory:

sudo mkdir -p /opt/uptime-kuma
cd /opt/uptime-kuma

A sane compose.yml looks like this. Keep it boring. Boring is what you want at 3 a.m.:

services:
  uptime-kuma:
    image: louislam/uptime-kuma:latest
    container_name: uptime-kuma
    restart: unless-stopped
    ports:
      - "127.0.0.1:3001:3001"
    volumes:
      - uptime_kuma_data:/app/data

volumes:
  uptime_kuma_data:

Then bring it up:

sudo docker compose up -d
sudo docker compose ps

That 127.0.0.1 bind is intentional. You’ll terminate TLS at Nginx. You also avoid exposing the app directly to the internet.

Reverse proxy with Nginx + HTTPS (and the few headers that matter)

Give Kuma a dedicated subdomain like status.example.com or uptime.example.com. Point the DNS A/AAAA record at your VPS.

If you manage domains with HostMyCode, keeping renewals and DNS edits together is straightforward with HostMyCode domains.

Create an Nginx server block at /etc/nginx/sites-available/uptime-kuma:

server {
    listen 80;
    server_name uptime.example.com;

    location /.well-known/acme-challenge/ {
        root /var/www/html;
    }

    location / {
        return 301 https://$host$request_uri;
    }
}

Enable it and reload:

sudo ln -s /etc/nginx/sites-available/uptime-kuma /etc/nginx/sites-enabled/uptime-kuma
sudo nginx -t
sudo systemctl reload nginx

Issue the certificate with Certbot. The Nginx plugin and webroot method both work.

Use whichever matches how you already manage certs. For a full walk-through and common fixes, see: Configure HTTPS with Let’s Encrypt on a VPS.

After the cert is issued, replace your Nginx config with an HTTPS server block. Proxy requests to Kuma on localhost:

server {
    listen 443 ssl http2;
    server_name uptime.example.com;

    ssl_certificate     /etc/letsencrypt/live/uptime.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/uptime.example.com/privkey.pem;

    # Keep these modest; Kuma is a web app with websockets
    client_max_body_size 10m;

    location / {
        proxy_pass http://127.0.0.1:3001;
        proxy_http_version 1.1;

        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        # WebSocket support
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";

        proxy_read_timeout 60s;
        proxy_send_timeout 60s;
    }

    # Basic hardening (keep compatible; don’t over-tighten without testing)
    add_header X-Content-Type-Options nosniff always;
    add_header Referrer-Policy no-referrer-when-downgrade always;
    add_header X-Frame-Options SAMEORIGIN always;
}

Reload Nginx again, then sign in over HTTPS. The first-run admin setup is quick.

Do it once. Then decide how tightly you want to restrict access.

Operational hardening: keep the monitors up when the internet gets noisy

Monitoring endpoints attract attention because they’re always reachable. You can reduce risk without turning this into a month-long security project:

• Firewall: allow only 22/tcp (SSH), 80/tcp, and 443/tcp to the VPS. If possible, restrict SSH by IP or put admin access behind WireGuard.
• Rate limiting: if you publish a public status page, add basic protection against bot floods. Nginx rate limiting works well when tuned conservatively.

For a clean baseline, follow Set up UFW firewall on Ubuntu for a web server.

For bot control that won’t punish real users, see Nginx rate limiting in 2026.

One practical rule: don’t host your public marketing site and your monitoring dashboard on the same tiny VM unless you have no alternative.

If a traffic spike takes down the box, Kuma can’t tell you it’s down.

Backups you can actually restore (and what to back up)

Uptime Kuma stores its state in /app/data inside the container. You mapped that path to the named volume uptime_kuma_data.

That volume is the backup target. Any custom status page assets (like logos) live there too.

For a backup that works on any Linux VPS, archive the volume contents and push it offsite. A simple approach:

• Stop the container briefly (or accept a small risk of in-flight writes).
• Tar the volume data directory.
• Upload to object storage or another server you control.

Find where Docker stores named volumes (commonly /var/lib/docker/volumes) and back up:

sudo docker compose stop
sudo tar -C /var/lib/docker/volumes -czf /root/uptime-kuma-data.tgz uptime_kuma_data
sudo docker compose start

That file stays small for most setups. The important part is storing it off the VPS.

If you’re building a tested recovery plan, pair this with a restore drill and a DNS cutover checklist. This is a solid reference: Disaster recovery plan for a VPS.

If you want encrypted, deduplicated backups with retention you can audit, Borg remains a good choice in 2026.

Whatever tool you pick, document the restore path. Don’t document only the backup command.

Safe updates: keep uptime monitoring online while you patch

Uptime Kuma updates are usually painless. Still, don’t roll changes mid-incident.

A basic update rhythm keeps you out of trouble:

• Take a backup first (volume snapshot or tarball).
• Pull the new image.
• Restart the container.
• Verify the UI, notifications, and a few critical monitors.

cd /opt/uptime-kuma
sudo docker compose pull
sudo docker compose up -d
sudo docker image prune -f

If you pinned :latest, “pull then up” grabs the newest release available at that moment.

If you need tighter change control, pin a specific tag. Update only after reviewing release notes.

Status pages that don’t leak internals

Status pages are useful, but they can also reveal too much. A few habits keep yours customer-friendly:

• Group public-facing services (homepage, app, API, checkout) separately from internal dependencies (Redis, DB, admin panels).
• Avoid private hostnames in monitor names. Use product names, not internal DNS.
• Use a dedicated “health endpoint” for apps instead of monitoring admin routes.

If you run WordPress, consider a lightweight endpoint (even a cached page). It should exercise TLS, routing, and PHP.

It should also avoid forcing a full uncached page render every minute.

Common pitfalls (seen in real VPS deployments)

• Publishing port 3001 to the internet: you lose TLS termination control and make firewalling harder. Keep it on localhost behind Nginx.
• Overly aggressive intervals: checking everything every 10 seconds sounds “pro,” but it creates noise and bloats history quickly.
• Broken notifications: test alert delivery after any mail/DNS changes. Alerts that never arrive are worse than no monitoring.
• Single point of failure: if Kuma runs on the same VM as the app, you’ll miss host-level outages. Split them when you can.

Where this fits in a bigger monitoring setup

Uptime Kuma is strong at “black box” monitoring. It covers HTTP status, response time, TLS availability, and basic port reachability.

It’s not a full metrics platform.

For resource graphs, per-process visibility, and alerts on CPU/RAM/disk thresholds, pair it with a host monitoring tool. This guide shows a sensible combined setup: Server monitoring setup guide with Netdata and uptime checks.

FAQ

Should I self-host Uptime Kuma on the same VPS as my website?

You can, but it’s rarely ideal. If the VPS crashes or runs out of disk, Kuma drops too and you lose external visibility.

A separate small VPS is usually worth the extra few dollars.

How many monitors can a small VPS handle?

A 1 vCPU / 1 GB RAM VPS handles dozens of monitors comfortably at 60-second intervals. If you push hundreds of monitors or very short intervals, step up to 2 vCPU / 2 GB RAM and keep an eye on disk growth.

Do I need Docker to run Uptime Kuma?

No. Docker Compose just makes upgrades and rollbacks easier.

For most operators, a single Compose file plus an Nginx reverse proxy is the lowest-friction production setup.

What’s the minimum backup I should keep?

Back up the Uptime Kuma data volume (/app/data) and store it offsite. Run at least one test restore so you know you can recover monitors and incident history.

How do I secure the dashboard?

Use HTTPS, keep the app behind Nginx, firewall the VPS to required ports only, and consider IP restrictions or a VPN for internal-only dashboards.

Use strong admin credentials and enable whatever built-in auth options you require.

Summary: a practical way to own your uptime checks

Uptime Kuma strikes a good balance. It’s simple to operate, but reliable enough to depend on.

You get uptime checks, alerting, and a status page without handing monitoring data to a third party.

Run it on a small VPS, keep it behind Nginx with TLS, back up the volume, and update on your schedule.

If you’re ready to run monitoring on infrastructure you control, deploy it on a HostMyCode VPS (or step up to dedicated servers if you’re consolidating multiple internal tools and want isolation plus headroom).