Uptime Kuma v2 resource usage and setup guide for self-hosters

A recent technical evaluation of Uptime Kuma version 2 provides concrete resource metrics and configuration advice for developers running their own infrastructure. Published on October 7, 2026, the guide details a fresh installation process, highlighting that the tool remains lightweight enough for minimal hardware while introducing new database options in its second major release.

What happened

The author deployed Uptime Kuma v2 using Docker Compose to measure its actual footprint on a modern workstation. The initial image pull required 574 MB of disk space, but runtime memory usage proved significantly lower. With zero active monitors, the container consumed 143 MB of RAM. When configured with three active monitors checking every 60 seconds, memory usage fluctuated between 133 MB and 147 MB, while CPU load remained under 1% of a single core. These figures suggest the application can run comfortably on devices with as little as 256 MB of free RAM, such as a Raspberry Pi or an entry-level virtual private server.

A notable change in version 2 is the introduction of a database selection step during initial setup. Users can choose between SQLite and an embedded MariaDB instance. The evaluation recommends SQLite for installations with fewer than 50 monitors, citing simpler management and lower resource overhead. In a two-month test with three monitors, the SQLite data volume grew to less than 2 MB. This contrasts with MariaDB, which is better suited for large-scale deployments involving hundreds of monitors but requires more complex maintenance.

The guide also documents common configuration errors encountered during testing. Attempting to monitor a private GitHub repository via standard HTTP checks resulted in 404 errors because the monitor lacked authentication tokens. Similarly, checking a Supabase REST endpoint without an API key returned 401 unauthorized responses, falsely indicating downtime. The author advises using TCP port monitors for databases and services requiring authentication, rather than relying on basic HTTP status checks.

Key details

• Image size: The Docker image is 574 MB, requiring a few minutes to pull on standard broadband connections.
• Memory usage: Idle usage is 143 MB; with three active monitors, it stays between 133 MB and 147 MB.
• Database choice: SQLite is recommended for under 50 monitors due to simplicity and small backup size (under 2 MB in testing).
• Restart speed: The container restarts in 1.6 seconds and serves traffic again in under 10 seconds.
• Common pitfalls: HTTP monitors fail on authenticated endpoints; use TCP monitors for databases or keyword/API monitors with tokens for private repos.
• Backup method: Data resides in a single named volume, allowing easy backups via tar commands.

Background

Uptime Kuma is an open-source alternative to commercial uptime monitoring services like UptimeRobot or Pingdom. It allows users to host their own status page and monitoring dashboard, eliminating per-monitor fees and interval restrictions. The tool supports various monitor types, including HTTP, TCP, and ping checks, and can send alerts via multiple channels when services become unavailable.

Self-hosting monitoring tools shifts the responsibility for availability from a third-party provider to the user’s own infrastructure. This approach offers greater control over data privacy and customization but introduces a single point of failure: if the machine hosting the monitor goes offline, it cannot detect outages in other services. Therefore, the reliability of the host machine is critical to the effectiveness of the monitoring setup.

Why it matters

For teams managing small to mid-sized infrastructure, understanding the true resource cost of monitoring tools is essential for capacity planning. The confirmation that Uptime Kuma v2 runs efficiently on minimal hardware means it can be deployed on existing low-power devices or cheap cloud instances without impacting other workloads. This lowers the barrier to entry for comprehensive monitoring, allowing even small projects to track service health without significant budget allocation.

The distinction between HTTP and TCP monitoring is a practical lesson for DevOps engineers. Misconfiguring monitors for authenticated services leads to false positives, which can desensitize teams to alerts or waste time investigating non-issues. By choosing the correct monitor type, teams ensure that alerts reflect genuine service availability rather than permission errors. This accuracy is vital for maintaining trust in internal monitoring systems.

Additionally, the shift to SQLite for smaller installations simplifies operations. Managing a separate database server adds complexity to backups, updates, and security patching. Using an embedded database reduces this operational burden, making it easier for small teams to maintain their monitoring stack without dedicated database administration skills. This simplicity aligns with the goals of many self-hosters who prioritize ease of maintenance alongside functionality.

What you can do

• Deploy with Docker Compose: Use the provided compose file with a named volume to ensure data persistence across container recreations.
• Choose SQLite for small setups: If you have fewer than 50 monitors, select SQLite during setup to minimize RAM usage and simplify backups.
• Use TCP monitors for databases: Avoid HTTP checks for services requiring authentication; instead, monitor the specific port (e.g., 5432 for Postgres) to verify connectivity.
• Secure your admin account: Use a strong, unique password generated by a password manager, as the dashboard contains sensitive information about your infrastructure.
• Schedule regular backups: Automate weekly snapshots of the data volume and store them on a separate disk or location to prevent data loss.
• Ensure host availability: Run Uptime Kuma on a machine that is always on, such as a dedicated VPS or a reliable home server, to guarantee continuous monitoring.