Ramblings of an aging IT geek
← Ramblings of an aging IT geek
homelab

bringing it all back home, one service at a time

A creeping cloud bill and a rack in the garage prompted me to move the low-stakes services back home, and to be honest about which ones should stay put.

A small server rack with cabling in a home setup

The trigger was a bill, as it usually is. Not a dramatic one, just a slow creep, a tenner here for object storage I'd forgotten I was using, a few quid there for a managed database serving exactly one personal project. Individually trivial. Collectively, a steady drip of money leaving my account every month to run things that have no business living in someone else's datacentre.

So over the past couple of weekends I've been moving the low-stakes stuff back home, onto a small rack that's been quietly humming in the garage. The goal was never "self-host everything", because that way lies madness and a pager that goes off when your broadband does. The goal was to be honest about which services actually benefit from the cloud and which ones I was just renting out of habit.

Cabling and labelled drives in a home rack

what came home

The easy wins were the things with no real availability requirement and data I already had backed up. A handful of personal web apps. A Git mirror. The photo library, which was costing me storage fees to hold pictures I look at twice a year. These run on a single mini PC under Docker Compose, behind a reverse proxy, and if they fall over for an afternoon while I'm out, the consequences are precisely nil.

The pattern that made it painless was treating each service as a self-contained unit: a compose file, a named volume, a backup job. Moving one is then just standing up the compose stack at home, restoring the volume, and flipping DNS. No big-bang migration, no maintenance window, just one service at a time on whatever evening I felt like it.

services:
  app:
    image: ghcr.io/me/app:latest
    volumes:
      - app_data:/data
    restart: unless-stopped
volumes:
  app_data:

what stayed in the cloud, and why

This is the part the "leave the cloud" posts tend to skip. Plenty of things stayed exactly where they were, and that was the right call.

Anything that needs to be reachable when my house has a power cut or my broadband sulks stayed put. That includes the off-site backup target itself, because the entire point of off-site is that it isn't in the same building as the thing it's protecting. My home rack backs up to cloud object storage, not the other way around. Putting both copies in the garage would be a fire away from total data loss, and I'm not interested in that kind of authenticity.

Email stayed managed, because I value my deliverability and my sanity more than I value the principle of the thing. Anything with a genuine uptime expectation, where someone other than me is inconvenienced by an outage, stayed on infrastructure that someone other than me is paid to keep alive at 3am.

what it actually saved

The bill dropped by a bit over half. Not nothing, but honestly the money was never the main return. The main return was understanding my own setup again. Pulling these services home forced me to write down what each one was, what data it held, and how to restore it, which is a thing I'd been comfortably ignoring while a provider abstracted it away.

The garage rack draws about 40 watts at idle, which at current electricity prices is its own small ongoing cost, so this isn't free, it's a trade. I've swapped a predictable monthly invoice for a bit of power, a bit of noise, and the responsibility of being my own ops team for the unimportant things. For the unimportant things, that's a trade I'm happy with. The important things can stay rented. Knowing the difference is the whole skill.