Uptime Kuma is a ‘fancy’ self-hosted monitoring service that can be used to create your very own status page of any services you would like to monitor. Initial configuration and setting up monitors is very easy.
Setting Up Uptime Kuma
The preferred method for setting up Uptime Kuma is Docker. And to make the setup in docker even easier, I like to use Portainer:
Any readers of this blog are probably aware that I often self-host open-source services. Self-Hosting can be daunting at first, but with a little groundwork, it can be quite easy, safe, and rewarding. Recently I deployed my own instance of the handy draw.io – from start to finish it took me less than 5 minutes. The ease of deploying the service reminded me how far I have come in my journey of self-hosting. Only a couple years ago I would have been completely lost about where to begin, but now I have it boiled down to two primary steps: Deploy docker container, expose docker container using NGINXProxymanager.
There are some prerequisites that should be in place before self hosting. Some of them listed below are not required but make it much more enjoyable and rewarding. I won’t get into the weeds about why these are important, since my goal in the post is to show how easy self-hosting CAN be – not how hard it actually IS!
Your own Domain
A good internet connection (specifically upload speeds)
A router that supports advanced options (like OPNSense)
TLDR: A Nextcloud description is below, but why not just check out the demo!
Nextcloud is a Free and Open Source Software (FOSS) that provides an enterprise grade all-in-one solution for file storage, collaboration, meetings, etc. Over the past few years Nextcloud has come a long way and is now my recommended solution for anyone seriously interested in hosting their own data with privacy and security in mind. Nextcloud is made up of many, many apps that can be installed as needed. Some of the apps include:
Files (This is installed by default and aids in storing/sharing/managing your files)
Calendar (This uses WebDav and can be synced to other devices more on this in a later post)
Tasks (This also can be synced using WebDav to other devices like MacOS/iOS Reminders)
Gallery (This helps with managing your photos in a centralized location)
Maps (Directions, pinning locations, mapping where your photos were taken, etc)
Contacts (Address book that uses WebDav to sync with other devices)
Bookmarks (Bookmark storage that can be synced to your browser using Floccus)
Talk (Meeting software like Zoom or Jitsi, no Nextcloud account needed to join calls!)
Mail (A very functional Mail client application with encryption, multiple accounts, etc)
2 Factor Authentication
File Sharing policies (timeframe, encryption options, public link expiration, etc)
Why use Nextcloud? Simply put: data privacy. Nextcloud provides a private and secure vault for all your personal information. No need to worry about Google reading your emails and using your photos for machine learning purposes. No need to pay Dropbox or any other cloud storage company a monthly fee for storing your files on a server you have no control over. Nextcloud makes it easier to take responsibility for your own data so you know where it resides. If you’re still not convinced, check out Nextcloud’s reasoning.
Given my bullish stance on Nextcloud, I would also like to make clear that Nextcloud isn’t for everyone. It does require some technical experience and a use case that is worth while. Nextcloud works best and is most enjoyable when it is used for more than just a few files. Casual or non-technical Nextcloud users would be better off signing up with a Nextcloud provider rather then self-hosting it since the providers will handle the configuration and hosting of the storage (this however does reduce your visibility in where and how your data is stored). An alternative to a cloud provider is to buy a dedicated, pre-configured piece of Nextcloud hardware with some tech support.
Nextcloud can be installed in a variety of ways. My preferred method is using the per-configured virtual appliance, but other methods include docker, Ubuntu snap, web-server script, archive extraction. Detailed installation instructions can be found in the Nextcloud Docs, but a simple rundown of the installation methods are listed below:
Virtual Machine (My preferred method)
I prefer this method since it allows me to take easy snapshots/backups of the entire Nextcloud environment. This gives me peace of mind so I can be sure I can rollback to a point in time if anything goes wrong.
Download the Virtual Machine (There are also advanced-configured VMs here)
Setup a VM in your favorite Hypervisor (Proxmox, Hyper-V, VirtualBox, VMWare, etc)
Import the downloaded Virtual Machine file and start the virtual machine (check the console)
Login to the pre-configured Nextcloud instance and enjoy!
Appliance: Docker (Great for those already using Docker)
For those already using docker, this method may be appealing. I avoided this option primarily because it didn’t have a very clean docker-compose setup.
On a docker-enabled machine run `docker run -d -p 8080:80 nextcloud`
Alternatively, if you use docker-compose, start with this template:
Appliance: Ubuntu Snap (Easy for Beginners, but not recommended!)
This installation method is very easy but does have some drawbacks. From my experience, updates are slower to be released to the Nextcloud ubuntu snap distribution and often has issues with edge cases (I’ve noticed this with Collabora docs). It is also very difficult to migrate Nextcloud from a snap installation to a different installation method (I learned this the hard way!).
Setup an ubuntu machine with snap enabled.
Run `snap install nextcloud`
Follow the installation steps and enjoy.
Web Installer (Good for C-Panel style web-hosting)
Download the php script from the Nextcloud Site
Upload the php scrip to your web server
Point your browser to the php script
Walk through the installation wizard (default user: ncadmin default password: nextcloud)
Manual Archive File Installation (Most Difficult)
Download the Archive from the Nextcloud site
Extract the archive file to an accessible location on your web server
First off, I’d like to spend a minute appreciating the craftsmanship and the premium nature of the squeezebox line of products. Almost a decade before the current ‘smart’ speakers that are common today (Echo, HomePod, GoogleHome, etc), the Squeezebox sported much of the same functionality:
Premium Quality Sound
Remote Control (via a handheld remote & web interface)
Streaming radio, podcasts, music, etc
Apps for extensible functionality
Web Interface for local and remote access (most modern speakers don’t offer local control)
Local API for extensibility (I don’t know of any modern speakers that offer this!)
A community of users for great support (still exists today!)
An Orphaned Squeezebox
Recently at my workplace we upgraded the office speaker and had an orphaned Squeezebox Boom. We were ready to recycle the 12 year old speaker, but it still seemed to have so much potential. The speaker hardware worked flawlessly (although the online services have been neglected by Logitech). Naturally, since I knew the Squeezebox had a local API, my instinct was to check if Home Assistant had any support for such a device, and sure enough it has a Logitech Squeezebox integration! After browsing the integration documentation I figured it would be worth an effort to give the Squeezebox a new life.
Prerequisite for Integration: Logitech Media Server
The Home Assistant documentation indicated that I would need to have a Logitech Media Server in order to control the Squeezebox – A slight inconvenience, but a quick search on DockerHub revealed some pre-built docker containers that can provide me with a self-hosted alternative to the Internet reliant interface that Logitech could shut down at any time. Setting up the docker container was as simple as adding the following to my docker-compose file and running: docker-compose up -d. Stay tuned for future posts about Docker & docker-compose. They are great tools for quickly setting up various services!
Welcome to my first blog post! It won’t be impressive, so don’t get your hopes up. I don’t currently have a structured plan for this blog yet, but I need to start somewhere, so basically I will explain how you are able to read this post – note the terms in italics – these may be topics of future blog posts:
You entered or clicked on a link with the URL of homegrowntechie.com
Your device made a DNS query to find out that homegrowntechie.com is located at a specific IP Address
Hopefully you are not using Google DNS or your ISP’s DNS – more on this in a future post
The DNS request returns my Public IP address because I’ve used a Dynamic DNS service to update my Domain Registrar with the public IP address your machine needs to access this website.
Your machine requested this page by sending a GET request, but before you were able to read anything on this page your request was Routed through your home router (or cell tower) to your ISP’s network, and on through the Internet before finally reaching my router,
After reaching my router, my router forwarded your GET request to a Self-HostedNGINX Reverse Proxy which then forwarded your traffic to my Self-Hosted WebServer
My WebServer is running WordPress which then responded to your GET request with this webpage.
The few steps above are a simplified version of what actually happened, but a good opportunity to throw out some terms (Italicized) that may be topics of future blog posts.
Thought of the day: “Why am I still using Gmail when I care about my own privacy?“