How to self-host Uptime Kuma on a VPS with Docker and HTTPS

Self-host Uptime Kuma on a VPS with Docker, nginx and HTTPS, alerts, status pages and backups, or install it in one click from the ZoPanel App Store.

Diagram: Uptime Kuma in Docker on a separate VPS checking websites and sending alerts

Key takeaways

  • Uptime Kuma is a free, MIT-licensed monitoring tool that runs from one Docker image with one data volume.
  • Run it on a different server from the sites it watches, or it goes down with them and cannot alert you.
  • Publish port 3001 on 127.0.0.1 only and put nginx with HTTPS and WebSocket headers in front.
  • All monitors, alerts and history live in /app/data, so back up that folder off the server.

To self-host Uptime Kuma, run the official louislam/uptime-kuma:2 Docker image with a volume for /app/data, publish port 3001 on 127.0.0.1 only, and put nginx with HTTPS (and WebSocket headers) in front of it on a subdomain such as status.example.com. A small VPS with 1 GB of RAM is enough for a typical set of monitors, and it should be a different server from the one you are watching. If that VPS runs ZoPanel, Uptime Kuma installs in one click from the App Store, with SSL and a setup lock that keeps the admin account yours.

This guide covers what Uptime Kuma is, the manual Docker install, the ZoPanel route, backups and updates, and what it costs compared with a hosted monitoring service. If you run a hosting company and want status pages for customers, read uptime monitoring and status pages for hosting providers after this one.

What is Uptime Kuma?

Uptime Kuma is an open-source, self-hosted monitoring tool released under the MIT licence. According to its README, it checks HTTP(s), TCP, HTTP(s) keyword and JSON query, WebSocket, ping, DNS records, push monitors, game servers and Docker containers, with intervals down to 20 seconds. It sends alerts through Telegram, Discord, Slack, email (SMTP) and 90+ other notification services, supports two-factor authentication and publishes multiple status pages, which can be mapped to their own domains.

At the time of writing (October 2026) the latest release is 2.5.6, published on 9 October 2026. Version 2.0 became stable in October 2025 and contains breaking changes; the last 1.x release, 1.23.17, came out the same day. Version 2 is what you should install on a new server.

One thing to know before you start: Uptime Kuma has a single admin account. It is built for one operator or a small team sharing one login, not for many users with separate permissions.

Where should Uptime Kuma run?

A monitor on the same server as the websites it watches goes down with them. When the VPS runs out of memory or the provider has an outage, nothing is left to send the alert. Put Uptime Kuma on a separate, small VPS, ideally with a different provider or in a different data centre, and let it watch your production servers from outside.

How much RAM does Uptime Kuma need?

Uptime Kuma's documentation does not state a minimum. As a reference, ZoPanel runs it with a 512 MB memory limit and 1 CPU. A 1 GB VPS leaves room for the operating system and nginx next to it. Memory and the SQLite database grow with the number of monitors, the check interval and how long history is kept, so shorten Settings → Monitor History if the database gets large. The README warns that network file systems such as NFS are not supported, so keep the data on a local disk.

Uptime Kuma vs a hosted monitoring service: cost

Uptime Kuma has no official hosted version, so the usual comparison is a SaaS monitor such as UptimeRobot. Prices below are from UptimeRobot's pricing page at the time of writing (October 2026), billed annually.

Uptime Kuma (self-hosted) UptimeRobot Free UptimeRobot Solo UptimeRobot Team
Price Free software; you pay for a small VPS $0 $9/month $35/month
Monitors Limited by your server 50 10 or 50 100
Shortest interval 20 seconds 5 minutes 60 seconds 30 seconds
Who runs it You: updates, backups, uptime of the monitor The vendor The vendor The vendor

The hosted service wins on zero maintenance and on checks from several locations. Uptime Kuma wins on short intervals, unlimited monitors and keeping the data on your own server. Check UptimeRobot's site for current plans before you decide.

Option 1: Self-host Uptime Kuma with ZoPanel (one click)

If the monitoring VPS runs ZoPanel, Uptime Kuma is in the App Store (full guide):

  1. Open App Store. If you see Docker is required, click Install Docker first.
  2. On the Uptime Kuma card, click Install.
  3. Enter the Domain (for example status.example.com, without http://). Administrators also choose the Owner, the hosting account whose package limits apply. Leave Free SSL (Let's Encrypt) on.
  4. Click Install and follow the task log until Uptime Kuma is available at http://<domain>. If it says SSL could not be issued yet, point the domain to the server and click Issue certificate on the website's SSL tab.

The setup lock. The first visitor to a new Uptime Kuma creates its only admin account, so ZoPanel shows everyone else "This app is being set up" until you finish:

  1. On the website's Docker tab, wait until the status is running.
  2. In the Setup lock is on card, click Open the app (only for me).
  3. On Create your admin account, choose the language, enter a username and password, and click Create.
  4. Back on the Docker tab, click Setup finished — open to everyone. Status pages become public; the dashboard still needs your login.

What ZoPanel sets up (from the App Store documentation): a 512 MB memory limit and 1 CPU, the port published on 127.0.0.1 only behind nginx with SSL and WebSocket support, user namespaces, and data in /var/lib/zopanel-apps/<instance>/data/ readable only by root and the container. Customers of a hosting company can install it themselves when their package allows Docker apps.

Limits to know. The container sits behind ZoPanel's container firewall, which shapes what it can check:

Target Works from ZoPanel's Uptime Kuma?
Websites and APIs on the internet (HTTP(s), keyword, DNS, TCP) Yes
Sites on the same server through their public domain Yes
This server's mail ports (25, 465, 587) Yes
This server's SSH, MariaDB, PostgreSQL, Redis or the panel No, always shown as down
Private networks and loopback No
Docker Container monitors No, no access to the Docker socket

Another honest point: ZoPanel's catalog uses the image tag 1, so it installs and updates within Uptime Kuma's 1.x line, not the current 2.x line. If you want version 2 features today, use the manual install below.

Option 2: Self-host Uptime Kuma by hand with Docker

This route is for a VPS without a control panel, on Ubuntu 24.04 or Debian 12. Install Docker Engine from Docker's official repository, as shown step by step in our n8n guide.

Step 1: Compose file

sudo mkdir -p /opt/uptime-kuma && cd /opt/uptime-kuma
sudo nano compose.yaml
services:
  uptime-kuma:
    image: louislam/uptime-kuma:2
    restart: unless-stopped
    ports:
      - "127.0.0.1:3001:3001"
    volumes:
      - ./data:/app/data

The official README publishes 3001:3001 on all interfaces and notes that you can limit it to localhost with 127.0.0.1:3001:3001. Do that: Docker's port rules bypass UFW, so a plain 3001:3001 exposes the dashboard over unencrypted HTTP. Pin a specific version (for example 2.5.6) instead of 2 if you want updates only when you choose.

sudo docker compose up -d
sudo docker compose logs -f

Step 2: nginx and HTTPS

sudo apt install nginx certbot python3-certbot-nginx
sudo nano /etc/nginx/sites-available/uptime-kuma.conf
server {
    listen 80;
    server_name status.example.com;

    location / {
        proxy_pass http://127.0.0.1:3001;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        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;
    }
}

The Upgrade and Connection headers matter: the dashboard talks to the server over WebSocket and keeps reconnecting without them.

sudo ln -s /etc/nginx/sites-available/uptime-kuma.conf /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx
sudo certbot --nginx -d status.example.com

The A record must point to the VPS first; see how to point a domain to a VPS. Then open https://status.example.com and create the admin account straight away, because the first visitor gets it.

Step 3: First settings

  • Settings → Security: turn on two-factor authentication.
  • Settings → Reverse Proxy → Trust Proxy: set to Yes, so logs show real visitor IPs.
  • Settings → Notifications: add Telegram or email (SMTP on port 587 or 465), tick Default enabled, click Test.
  • On each HTTP(s) monitor, set Retries to 1 or 2 to avoid alerts on a single slow response, and turn on the certificate expiry warning.

Backing up Uptime Kuma

Everything lives in /app/data: the SQLite file kuma.db with monitors, notifications, status pages, history and the user, plus uploaded images.

Manual install: stop the container briefly so the database is consistent, archive the folder and copy it off the server.

cd /opt/uptime-kuma
sudo docker compose stop
sudo tar czf /root/uptime-kuma-$(date +%F).tar.gz -C /opt/uptime-kuma data
sudo docker compose start

ZoPanel: the app's data is not part of account backups. Use the Backups card on the website's Docker tab: Back up now, and for administrators a daily or weekly Schedule and how many copies to Keep (default 7). The container is paused for a few seconds during the copy. Archives land in /var/backups/zopanel-apps/<instance>/; copy important ones off the server, encrypted, since they contain notification credentials. More on this in website backup strategy.

Updating Uptime Kuma

  1. Back up first.
  2. Read the release notes. Moving from 1.x to 2.x has its own migration guide, and the first start of version 2 migrates the database, which can take a while on large installs.
  3. Change the tag if you pinned one, then run sudo docker compose pull && sudo docker compose up -d.

On ZoPanel, Update to latest on the Docker tab pulls the catalog image and keeps your monitors and history. It stays within the 1.x line.

Conclusion

Self-hosting Uptime Kuma takes one container, one volume and an HTTPS proxy. The decisions that matter are where it runs (not on the server it watches), that port 3001 is never public, and that /app/data is backed up somewhere else. If you would rather not configure nginx, SSL and container isolation yourself, ZoPanel installs it in one click and the App Store is part of the Free plan, which costs nothing for up to 3 hosting accounts. See features for apps and pricing, or install on a fresh VPS with:

curl -fsSL https://get.zopanel.net | sudo bash

Frequently asked questions

Is Uptime Kuma free?

Yes. Uptime Kuma is released under the MIT licence, with no paid edition. You pay only for the server it runs on, and you are responsible for updates and backups.

Can Uptime Kuma monitor the server it runs on?

It can, but it should not be your only monitor for that server. If the server goes down, Uptime Kuma goes down too and cannot send an alert. Run it on a separate VPS, ideally with another provider.

Does Uptime Kuma support multiple users?

No. It has a single admin account. Teams usually share that login or give read-only access through public status pages.

How do I reset a forgotten Uptime Kuma password?

Open a shell in the container (docker exec -it <container> bash) and run npm run reset-password, then follow the prompts. On ZoPanel the container is named zp-app-<instance>.

Is Uptime Kuma better than UptimeRobot?

They solve the same problem differently. UptimeRobot needs no maintenance and checks from the vendor's network; Uptime Kuma gives you 20-second intervals and unlimited monitors for the price of a small VPS, but you maintain it. Many teams use both: a hosted monitor to watch the Uptime Kuma server, and Uptime Kuma for everything else.