I’ve recently returned to a hobby of mine … self-hosting various software services and web applications on a server I maintain. I’ve hosted my own websites (and the websites of friends and family) for almost two decades, but that’s always been done using a server in the cloud, through a company that maintains the actual infrastructure (hardware, network, etc). Also, every now and then I would stand up a server (usually an old laptop) at home and try to run Plex or something, but I was never disciplined enough about it (backups, documentation, updates, etc), and the server would rot after a few months.
But sometime last fall, a few things coalesced and I’ve jumped back into the self-hosting game. First, my son’s old desktop was just sitting unused in my basement, and I realized it had the horsepower to make a serviceable server. Second, I’ve become more concerned about both privacy, and vendor lock-in. Services go away all the time, and when they do, what happens to your data? Speaking of “your data”, I’m not happy that my data is sold to advertisers and credit companies and any and every corporation or organization. Third, I was bored, and in thinking about what I enjoy doing, I realized I like doing “tech-y” things like writing code and administering servers.
So over Thanksgiving break I fired up the old desktop, plugged in some old drives for extra storage, and installed Ubuntu. There were some stumbling blocks along the way, like the original SSD dying after a couple of weeks. In the past, I probably would have just bailed on the hobby right then. But I scavenged another SSD from an old laptop, reinstalled Ubuntu, and realized I needed to go about this more systematically.
To that end, I wrote up some general guidelines, or guiding principles, for this project:
- Always prefer simplicity over complexity. Easier to secure, reason about, troubleshoot, maintain, uninstall, upgrade, etc.
- Always prefer directed, focused solutions (unix philosophy). E.g. dave vs nginx for webdav.
- Always prefer open source. It’s ok if they have a paid business model, but the app or service should be open source.
- Always prefer open standards for files, protocols, etc. Text-based, http, etc. Propiertary sucks and promotes lock-in.
- Always prefer default configurations. Customization doesn’t survive (hosts, upgrades, etc).
- Services that are servers should be dockerized and managed with docker-compose.
- Services that need to be built, or are multi-step installations, or have complex configuration, should be dockerized and managed with docker-compose.
- Services that are not servers, and can be installed as simple binaries or packages, should not be dockerized.
- If it can’t be recreated automatically, it needs to be backed up. But you don’t need to backup things that can be recreated automatically.
- All custom config should be versioned in source control.
- Documentation, documentation, documentation. The previous and current administrators (me) are idiots, and to understand why or how they did something, it needs to be written down.
So after a few months, I have a server, well, serving several, well, services: RSS reader, note taking app, “read later” article repository, Strava-like running tracker, and a few others. Like the guidelines say, Docker and docker compose are used to manage most services, everything is documented, all config is in a Git repository, and what needs to be backed up, is backed up.
In the past, it always seemed like a waste of time to manage all this myself when there are so many free, cloud-based services in the world. Why in the world should I install, configure and maintain my own “read later” service for web articles, when I can just sign up for something like Pocket and have them do it for me? Or why not just use Strava, or OneNote/Evernote? In the end, I realized the answer to why I self-host is … because I can, and because I enjoy it.
