In previous projects, I have described building a home server & instantiating the associated services with it. Once built & stable, I found myself regularly checking the associated services to ensure they were reachable, reaching to the quick realization that an uptime monitoring solution would be needed. Even with a local VPN for remote administration if needed there was no straightforward way to ensure all services were healthy. A bash script could be sufficient for the need, however I was looking for something a bit more elegant.
With multiple services running my hope was to find a solution that could effectively monitor multiple types of traffic in differing manners (I.E. a ping response may not necessarily be an indicator of service health). My hope was to utilize SMS as well for rapid and effective notifications. With the deprecation of email-to-text across cell carriers the last several years, this would add an additional barrier of entry as well.
Enter Uptime Kuma. A relatively recent addition to the field having been first released in 2021, this open-source solution maintained by louislam has rapidly gained popularity due to it’s flexibility, clean UI and ease of use. As a Dockerized container it provides a self-contained solution with minimal underlying configuration required to begin setting up monitoring jobs and quickly appears to be rising to prominence as the de-facto solution for Dockerized containers.
In terms of SMS notifications, Twilio provides a relatively simple, low-cost solution that comes with a free toll-free number. While this number requires a verification process in the US to be used for messaging that is not exactly straightforward, it can be accomplished for a personal site and allows for straightforward API calls for message delivery.
With both these pieces in place, the final solution for my home server ended up being two instanced of Uptime Kuma, one local and one remote being housed on an Oracle Cloud VPS. I had quickly realized that a local instance while simple and easy to setup would not provide notification of service disruption beyond a local service crashing. Remote monitoring provides full availability monitoring, with a local instance closing the loop and pointing at the remote instance to ensure it is operating as intended.
One of the primary draws for Uptime Kuma is how dynamic it can be for remote monitoring, with dozens of different monitoring types and configuration options that would out of scope for this project. For my publicly available services (Plex, web instances) using HTTP/s monitoring looking for specific keywords on the site has worked quite well. There is an additional option included providing warning for SSL cert expirations in case automated renewals ever experience a disruption.
An all-in-one container like the standard Kuma image can potentially pose security concerns. However, there are ways of mitigating this risk without relying entirely on containerization to contain any potential blast radius. In terms of networking, the local instance of Uptime Kuma has not been exposed to the local internet, with only LAN connections allowed. The cloud instance runs within it’s own dedicated VPS, segmented from the local server with a reverse-proxy implementing SSL for all traffic (thank you to letsEncrypt for recently adding support for static IPV4 addresses). Additionally, both instances require 2FA for authentication to mitigate any potential brute-force attempts.
While appropriate segmentation, traffic encryption and authentication practices will go a long way towards risk-mitigation, these will not protect against underlying vulnerabilities in the container itself if a zero-day was uncovered. There are two options to attempt mitigation. First, one could attempt to further reduce the attack service by splitting associated applications (such as MariaDB) into distinct containers on a virtual network, with only the parent Kuma container exposed. Secondly, a docker-released ‘hardened’ image could be utilized, implementing image best practices & prioritizing security over maintainability, for example removing a bash shell entirely. However, with appropriate update schedules and the existing risk mitigation in place one would find relatively low risk for personal use.
Having now utilized this implementation for several weeks, it has provided significant peace of mind in terms of ensuring uptime availability across all public-facing services. There are several improvements to be made – monitoring of the local Uptime Kuma instance and image hardening both come to mind. However, in it’s current state Uptime Kuma has provided significant value to ensure all services remain available, with rapid notification if any disruptions do occur.