The home server I finally stopped turning off
How Raspberry Pi experiments became persistent infrastructure—and why reliability sometimes meant doing less.
For years, my test for a home server was apparently whether I could install things on it. The more useful test turned out to be whether I would leave it running.
Around the start of 2020, I got a Raspberry Pi and repeatedly installed Raspbian or Debian. I would add Sonarr, Radarr, maybe Prowlarr, a torrent client and Plex. Sometimes I ran Pi-hole too.
It was a good environment for playing with software, but it never stuck, right? There was no reverse proxy, I was not putting my own domains behind it, and eventually I would turn it off. I had a computer that could run server software, not infrastructure I depended on.
Persistence changed the architecture
In summer 2024, I decided to build something that would stay running. An old i5 desktop was already sitting around, I knew it worked, and attaching drives was easy. Why the hell not?
I installed OpenMediaVault from the start. Over the next two or three months, I added the pieces the Raspberry Pi experiments had never acquired: Docker-managed services, Traefik as a reverse proxy, Tailscale, proper DNS and network sharing.
The important part was the relationship between those pieces. A new service could sit behind HTTPS, with a deliberate choice between public and private access. Two Pi-hole instances provided two DNS servers. Storage belonged to the OpenMediaVault machine, while other work could happen elsewhere.
The setup became genuinely useful because it offered a repeatable way to add and reach services. I stopped treating it as a collection of installations.
The 4 GB transcoding helper
The clearest example was a separate OptiPlex with 4 GB of RAM running Debian. Its main job was Plex Pass transcoding.
Plex read media across the network from drives attached to the OpenMediaVault server. The OptiPlex did not need to become another complete copy of the system; it was a small helper with a specific job. It also gave me another place to run DNS.
Making that work meant understanding the network share, deployment across two Linux machines and the traffic around them. These were not especially advanced systems problems, but they crossed boundaries that application-focused development often hides. Docker, Linux, DNS, storage and reverse proxies stopped being separate topics because one useful service depended on all of them.
Reliability can mean doing less
I also discovered that not every available layer should become part of the home lab.
That summer I tried using an old laptop as a router with OpenWrt. It kept dropping out. I was trying to build the server while repeatedly taking down my own internet.
Eventually I bought a router.
You need to know when to just not do it yourself. I reached the point where I thought: “I just want something that works. I’m going to stop trying to overcomplicate it. I’m just going to make it work.”
Buying the router was not giving up on learning. It narrowed the system to the parts I actually wanted to operate.
Useful does not mean free
A home server uses energy. Plex Pass costs money, as can a VPN or another service. It can also be down at exactly the moment you want to watch a film. Self-hosting will cause a fucking headache.
I still think it is worth it. The server gives me real problems that matter to me, and that makes the learning stick in a way the earlier experiments did not.
By 2026, I had a different desktop sitting unused because my MacBook had become my everyday computer. Moving the server onto that machine and rebuilding it around Proxmox was the next step, but that deserves its own article.
Want to talk about something I’ve written or built? Get in touch.
This Hashnode edition was adapted from the original article on billiem.uk, which remains the canonical and most complete version.