Uptime Kuma Self-Hosting Guide on DigitalOcean 2026

A practical, command-by-command guide to self-hosting Uptime Kuma on a DigitalOcean Droplet with Docker, from first deployment through alerting and public status pages.

Uptime Kuma is a popular open-source monitoring tool for self-hosting instead of paying for SaaS services like UptimeRobot, because you control the data entirely and can run unlimited monitors. This guide walks you through choosing the right Droplet size, installing with Docker, configuring your first monitor, setting up alerting, and creating a public status page for production use.

What is Uptime Kuma and How Does It Differ from DigitalOcean Monitoring

Uptime Kuma is a self-hosted monitoring software written in Node.js and Vue.js, open-source for anyone to run on their own servers for free. Its main job is to continuously check the status of websites, APIs, or other services at set intervals and alert when problems occur. The standout feature is supporting many monitor types in one application: HTTP(s), TCP Port, Ping, DNS Record, Docker Container, gRPC, Push (for cron jobs with dead man's switch), and Keyword/JSON Query to check if specific content appears in a web page or API response exactly as expected. Since it runs on your own server, there's no limit on the number of monitors aside from your Droplet's resources. Meanwhile, DigitalOcean itself offers built-in Monitoring features for free, covering metrics collection for your Droplet like CPU, memory, disk, and disk I/O, with alert policies included. It also gives 1 free Uptime Check per account to verify that an endpoint (like your main website) is still responding. The advantage is no extra setup or server management needed, but the limitation is only 1 free check. If you need to monitor multiple endpoints simultaneously, want your own branded status page, or need more diverse alerting channels, self-hosting Uptime Kuma is more suitable, though it comes with the burden of maintaining and securing your own Droplet. In short, they don't directly compete but complement each other well. For example, you can use DO's free Uptime Check to monitor the Uptime Kuma instance itself, preventing the "who watches the watcher" problem when the Droplet crashes along with the services it's monitoring.

• Uptime Kuma: self-hosted, unlimited monitors within Droplet resource limits
• DO Monitoring: free built-in, no setup needed, but only 1 free Uptime Check per account
• Uptime Kuma supports multiple monitor types: HTTP(s), TCP, Ping, DNS, Docker, gRPC, Push, Keyword/JSON Query
• Can use together: leverage DO's free Uptime Check to monitor the Droplet running Uptime Kuma itself, preventing single point of failure

Deployment with Docker

First you need a Droplet to run Uptime Kuma on. For beginners with just a few dozen monitors, the Basic Shared CPU package at 1 GiB RAM / 1 vCPU / 25 GB SSD / 1,000 GiB transfer for $6/month is more than comfortable, since Uptime Kuma doesn't consume much RAM and uses SQLite as its built-in database. If you want to save even more, the 512 MiB package at $4/month can run it, but it'll be tight with many monitors open simultaneously. For users in Thailand, we recommend the sgp1 (Singapore) region as it has the lowest latency, with blr1 (Bangalore) as the fallback. After creating the Droplet, SSH into it and install Docker (you can either choose the "Docker on Ubuntu" Marketplace image when creating the Droplet or install it yourself later via apt), then run a single command to start Uptime Kuma: docker run -d --restart=always -p 3001:3001 -v uptime-kuma:/app/data --name uptime-kuma louislam/uptime-kuma:1 This command creates a container named uptime-kuma, exposes port 3001, and importantly attaches a named volume uptime-kuma:/app/data to persist the SQLite database separately from the container so data doesn't disappear when you delete and recreate the container. If you prefer managing it more easily with docker compose, create a docker-compose.yml file with this single service, then run it with docker compose up -d. Once the container is running, configure DigitalOcean's Cloud Firewall (free to use, no extra charges) to open only port 22 (SSH), 80/443 (for reverse proxy), and block port 3001 from the outside internet. Then set up Nginx as a reverse proxy pointing to 127.0.0.1:3001 and use Certbot to issue a free SSL certificate for your domain pointing to the Droplet, so you access the dashboard via HTTPS only, never sending passwords as plain text over port 3001 directly.

• Recommended $6/month Droplet (1 GiB RAM, 1 vCPU, 25 GB SSD, 1,000 GiB transfer) for typical use
• Region sgp1 (Singapore) has lowest latency for Thai users, followed by blr1 (Bangalore)
• Main command: docker run -d --restart=always -p 3001:3001 -v uptime-kuma:/app/data --name uptime-kuma louislam/uptime-kuma:1

Configure Website/API Monitoring

On first access to the dashboard through your configured domain, the system will ask you to create an admin account first (set a strong password since this controls all alerting). Then click "Add New Monitor" to start adding items you want to monitor. The most commonly used monitor type is HTTP(s) to check if a website or API endpoint responds with the correct status. Enter the target URL, set the Heartbeat Interval (how often to check, like every 60 seconds), Retries (number of failures to allow before treating it as truly down to prevent false alerts from brief network hiccups), and Resend Notification for how often to re-alert when still down continuously. For APIs that need deeper content checking beyond just the status code, use the Keyword type to search for specific text in the response, or use JSON Query (available in newer versions) to validate JSON response fields, for example checking if the status field equals ok instead of just checking HTTP 200. For TCP Port, monitor whether a database or backend service port is accepting connections. Docker Container monitoring lets you watch other containers on the same machine directly through the Docker socket. If you have many monitors, organize them using the Group feature or Tags to make management easier as numbers grow, like separating Production and Staging or by team responsibility. You can also enable Upside Down Mode to flip the alert logic for special cases, like watching a maintenance mode to ensure it doesn't stay on too long.

• Main Monitor Types: HTTP(s), TCP Port, Ping, DNS, Docker Container, Keyword, JSON Query, Push
• Set Heartbeat Interval and Retries appropriately to reduce false alerts from brief network hiccups
• Use Keyword/JSON Query to check actual response content, not just HTTP status code

Alerting via Telegram/Email/Line Notify

Go to Settings > Notifications to set up alert channels, which can be bound to each monitor independently. For Telegram, create a new bot through BotFather in the Telegram app, type /newbot, give it a name, and you'll receive a Bot Token. Then find the Chat ID of the group or account you want alerts to go to (via Telegram API or helper bots like @userinfobot), then take the Bot Token and Chat ID and enter them in the Add Notification page, select Telegram type, click Test to confirm the message arrives before saving. For Email, use SMTP type and enter the host, port, username, password from your email provider (like Gmail App Password or your domain provider's SMTP relay), then set the sender and recipient addresses. It's good for non-urgent alerts or summaries. As for LINE Notify that many people know, it's important to clarify that LINE announced shutting down LINE Notify on March 31, 2025, so this option no longer works in 2026. The alternative is to use LINE Messaging API through your own LINE Official Account by setting up a Webhook and having Uptime Kuma send alerts via Webhook type, or use Apprise (which Uptime Kuma natively supports), which can integrate with LINE Messaging API and dozens of other notification services including custom integrations. You should set up at least two channels working together, like Telegram as primary and Email as backup, so you don't miss alerts if one channel has problems.

1. Telegram: create bot via BotFather to get Bot Token, pair with Chat ID, then click Test before saving
2. Email: use SMTP type and enter host/port/username/password from your email provider
3. LINE Notify service shut down on March 31, 2025, no longer available
4. Alternative to LINE Notify: LINE Messaging API via Webhook or use Apprise, which Kuma supports natively
5. Set up at least 2 channels together to avoid missing alerts if one has issues

Create a Public Status Page

Uptime Kuma has built-in Status Page feature to create a public-facing webpage showing service status without needing a separate service. Go to Status Pages menu and click "New Status Page", set a name, set a slug for the URL (like /status/production), then drag the monitors you want to display and organize them by category like "Website", "API", "Database". The Status Page shows current status, uptime percentage historically, and heartbeat history as a bar chart for quick overview. Customize the appearance including theme, logo, description, and toggle to show/hide response time numbers as needed. If you want incident history, add announcements with progress updates from the same page. For credibility, we recommend using a subdomain instead of a path, like status.example.com by setting a DNS A or CNAME record pointing to your Droplet IP, then adding a new server block in Nginx specifically for this domain to proxy to your Status Page path, and issuing a separate SSL certificate via Certbot. A Status Page on its own subdomain has the advantage that it stays accessible even if the main dashboard is restricted to specific IPs via Cloud Firewall, because you can configure Nginx to open only the Status Page path publicly while keeping the management dashboard restricted to your team's IPs.

• Create via Status Pages > New Status Page, set slug, drag monitors to organize by category
• Display historical uptime percentage, heartbeat history, and customize theme/logo
• Add Incidents to announce events and update users on progress

When to Use This Feature (Real Use Cases)

Uptime Kuma suits situations where DO's 1 free Uptime Check isn't enough, like teams managing multiple services simultaneously—main website, API, database, worker queue, or multiple microservices—that need separate monitoring per point rather than just knowing "website is down" as one overview. Another case is teams serving customers who want their own branded Status Page for transparency instead of customers reaching out during incidents. A public status page significantly reduces support burden and demonstrates professionalism. It also fits those needing more diverse alert channels than DO Monitoring supports, like wanting alerts in Telegram team groups, Discord, Slack, or webhooks into your internal systems, which DO Monitoring wasn't designed for. Cost-wise it's worthwhile compared to commercial monitoring SaaS that charges per monitor, because a single $6/month Droplet handles dozens to hundreds of monitors with fixed costs. Conversely, if you only have one website or endpoint to watch and don't want server management overhead, the existing DO Monitoring and free Uptime Check are sufficient. Weigh the flexibility you gain against the added maintenance burden before deciding.

• Multiple services/endpoints to monitor separately, beyond DO's 1 free check
• Want your own branded Status Page for customers, reduces support burden
• Need diverse alert channels like Telegram, Discord, Slack, Webhooks
• $6/month fixed cost beats SaaS charged per monitor when dealing with many monitors
• If only 1 endpoint and no server management appetite, DO Monitoring free option suffices

Common Errors and How to Fix Them

A point users often miss: the most common mistake is exposing port 3001 directly to the internet without reverse proxy and SSL, so login passwords are sent as plain text over the network. Fix: close port 3001 at Cloud Firewall then access only via HTTPS through Nginx as described in the deployment section. Another frequent problem is forgetting to attach a volume when running the container, so when you update or delete/recreate the container, all monitor and notification data vanishes. Prevention: always include -v uptime-kuma:/app/data in every docker run command and periodically backup this folder with something like docker run --rm -v uptime-kuma:/app/data -v $(pwd):/backup busybox tar czf /backup/kuma-backup.tar.gz /app/data. Next issue is setting Heartbeat Interval too frequently without need, like every 10 seconds for an already-stable website, wasting Droplet resources and unnecessarily increasing load on the monitored endpoint. Set it based on service criticality: critical APIs might be 30-60 seconds, while secondary services could be 5 minutes. Another often-overlooked point is nobody monitoring Uptime Kuma itself, running on the same Droplet as services it monitors, so if the Droplet crashes, no alert gets sent. Fix: use DO's free Uptime Check to monitor the Uptime Kuma URL itself as an extra layer. Finally, leaving image tag stuck at :1 without ever updating misses important security patches. Set up regular checks and update with docker compose pull && docker compose up -d.

1. Port 3001 exposed directly without SSL: close at Cloud Firewall then use reverse proxy + HTTPS
2. Forgot to attach volume: data vanishes when recreating container, always include -v uptime-kuma:/app/data
3. Heartbeat Interval too frequent: wastes resources and loads endpoints unnecessarily
4. Nobody monitoring Uptime Kuma itself: use DO free Uptime Check as extra layer
5. Image tag stuck without updates: misses security patches, pull updates regularly

Best Practices

Start with dashboard security: enable Two-Factor Authentication (2FA) immediately in Settings > Security after creating the admin account since this controls all alerting and monitor data. Pair it with restricting dashboard access to team IPs only via Nginx allow/deny or DO's free Cloud Firewall. For backups, set up cron jobs to regularly backup the /app/data folder, potentially sending backups outside the Droplet to protect against total Droplet failure, or add another layer with DO Droplet Snapshots to capture full machine state periodically. For versioning, we recommend pinning the image tag explicitly like louislam/uptime-kuma:1.23.16 instead of just :1 so you control when to update, test on a staging Droplet first before production to prevent breaking changes. For organization, set meaningful names and Tags from the start because when monitor count reaches dozens or hundreds, good grouping saves troubleshooting time during emergencies. For cron jobs or background tasks within your system, use Push monitor type instead of regular HTTP, since it's a dead man's switch where the job itself must send a heartbeat to say "still running"; missing heartbeats immediately signal problems, suitable for jobs without external endpoints. Finally, when monitor count and users grow to the point your Droplet gets tight on resources, consider upgrading to the $12/month package (2 GiB RAM, 1 vCPU, 50 GB SSD, 2,000 GiB transfer) which handles higher loads while staying cost-effective.

1. Enable 2FA immediately after creating admin account and restrict dashboard access to team IPs via Cloud Firewall (free)
2. Regularly backup /app/data folder and use Droplet Snapshots to capture full machine state
3. Pin image tag explicitly like louislam/uptime-kuma:1.23.16 instead of just :1
4. Use Push monitor type for cron/background jobs as a dead man's switch
5. When monitors grow and resources get tight, upgrade to $12/month Droplet (2 GiB RAM, 1 vCPU, 50 GB SSD)

Get $200 Free Credit →