in an effort to reduce costs recently, and a push to run more local infrastructure, I decided to end my paid service with another provider, instead opting for a self hosted solution called Uptime Kuma.
The Hosting Environment
Uptime Kuma can run in a Docker container. If you haven’t come across Docker before it’s a way we can break up and segment a server into virtual containers. It allows us to have a separate software and technology stack, greater portability and security.
Each container does share the same Kernel, however other aspects like networking are segmented.
Topology
Uptime Kuma, is the weapon of choice here, it’s free and open source software, and has some pretty dope features, that in some aspects our perform the paid alternatives.
For this project I have a virtual cloud server, running docker, which houses the software. It’s isolated from the internet and can only be accessed from our internal network.
The container can however talk to Discord, which is how such notifications are being delivered to monitor.
Pros:
- Major reduction in operating costs. From over $12 AUD a month to now just $4 AUD a month, + you could reduce costs even further by bringing the hosting in house and not relying on a cloud provider to run the service.
- no limits on the amount of hosts that can be monitored in comparison to the paid service I was using prior.
- greater visibility thanks to lower ping time thresholds. from 1 minute to 10 seconds.
- Notifications are now faster, and be sent almost anywhere thanks to Uptime Kuma using webhooks. Sending the notifications to Discord allows me to send rapid notifications to myself or anyone else who needs to monitor a service. A service going down to the admin receiving a notification could be as short as 15-20 seconds.
Cons:
- Server and security management is my responsibility. This includes updating server packages, for both the software and docker and it’s operating system, I also must protect the server, by configuring and monitoring it’s access. (good practice here, everything is blocked off by default, only allowing the server to communicate with who it must.)
- No iOS or Android apps. (although web app is fine by me, and unlikely you’ll need to make changes on mobile anyway.)
Conclusion
I managed to significantly decrease the monthly expense of uptime monitoring, whilst increasing the frequency in which services can be pinged. Limitations or caps on the amount of devices I can monitor have increased drastically and I’m not bound to limitations set by the previous software provider.