Self-Hosting Is Not Free: Accounting for Your Own Time

We love to tell ourselves a story about self-hosting: cancel the £10/month subscription, run the open-source equivalent at home, and pocket the difference. It’s a satisfying story. It’s also, in cold accounting terms, frequently nonsense — because the one cost we never put on the spreadsheet is the most expensive one we own. Our own time.

I’m not writing this to talk you out of self-hosting. I host more than is sensible, and I’d do it again tomorrow. But I’ve watched too many builders justify a setup on pure financial grounds, then quietly spend forty hours a year keeping it alive while telling themselves they “saved money”. The electricity bill is easy to reckon with — I’ve done that sum in detail in the real cost of self-hosting — but the time bill is the one nobody writes down, and it’s usually the bigger number. Let’s be honest about the ledger.

The hidden line items

When you replace a SaaS subscription with a self-hosted equivalent, here’s what actually goes on the bill that the comparison blogs never show:

• Initial setup. Reading docs, fighting reverse-proxy config, getting TLS working, the first three things that don’t work. Call it 4–12 hours for anything non-trivial.
• Updates. Every container, every month, sometimes with a breaking change that eats an evening. A handful of services is a couple of hours a month. A dozen is a part-time hobby.
• Backups. Setting them up is the easy part. Testing a restore is the part everyone skips, which means their backups are theoretical until the day they aren’t.
• Incidents. The disk that fills at 2am. The certificate that expired because the renewal cron died silently three weeks ago. The update that bricked the database. These don’t happen on a schedule; they happen when you have plans.
• Decision tax. The hours spent reading forums about which of four self-hosted photo apps to pick. This is real time, and for some of us it’s the most expensive line of all.

None of these appear in “£10/month vs £0/month”. All of them are real, and the nastiest ones are the least predictable. Setup time you can at least estimate. Incident time you cannot — it arrives unannounced, it arrives at the worst moment, and it doesn’t care that you had plans. The renewal cron that dies silently is the archetype: everything is fine for three weeks, and then the certificate expires, every service throws a security warning at once, and you’re debugging TLS at 11pm because a background job you forgot existed stopped running. That’s not a cost you scheduled. That’s a cost that scheduled you.

There’s a compounding effect, too. Each service you add is roughly linear in setup but the interactions between them are not. Two services share a reverse proxy; three share a backup job; a database upgrade breaks two apps that depended on the old version. The maintenance burden of a home lab grows faster than the number of services in it, which is why the tenth service feels far heavier than the first. This is the same trap I’ve written about as the home-lab upgrade trap: the pull to always add one more thing, when “good enough and stable” was already the winning position.

Do the actual maths

Put a number on your hour. It doesn’t have to be your billed rate — use whatever your leisure time is honestly worth to you. Say £20. Now reconsider that £10/month service you replaced. You “save” £120 a year. If standing it up and maintaining it costs you eight hours, you’ve spent £160 of your time to save £120 of money. You are, in pure financial terms, down £40 and you’ve acquired a pager.

It’s worth doing this sum explicitly rather than in your head, because the numbers are rarely as flattering as the vibe. Here it is as a back-of-envelope script — run it against a service you’re considering and see whether the answer surprises you:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

# What a self-hosted service actually costs vs its subscription
hourly_value = 20      # what an hour of your leisure time is worth, in £
setup_hours  = 8       # docs, config, TLS, the first three things that break
monthly_upkeep_hours = 1.5   # updates, the occasional 2am incident, amortised

annual_time_cost = (setup_hours + monthly_upkeep_hours * 12) * hourly_value
saas_annual = 10 * 12  # the subscription you cancelled

print(f"time cost:  £{annual_time_cost:.0f}/yr")   # £520/yr
print(f"saas saved: £{saas_annual:.0f}/yr")        # £120/yr
print(f"net:        £{saas_annual - annual_time_cost:.0f}/yr")  # -£400/yr

Four hundred pounds in the hole, in year one, purely on money. If that number horrifies you, self-hosting for savings was the wrong reason. If it doesn’t — if the control and the learning are obviously worth £400 to you — then you’ve just discovered the real reason you’re doing it, which is the healthy place to be.

This isn’t an argument against self-hosting. It’s an argument against a bad reason for it. The maths above is damning only if money was your sole motive. The moment you value the other things you got — control, privacy, learning, the absence of a vendor who can change terms or vanish — the ledger looks completely different. The mistake is pretending those are bonuses on top of a financial win, when usually they are the win.

What’s actually worth self-hosting

After enough years I’ve sorted my services into rough buckets, and the sorting principle isn’t cost — it’s how much the time investment pays back in something other than money:

Email is the perennial flashpoint, and I speak from experience. Builders self-host it to “save money” and then spend a weekend a year fighting deliverability, blocklists, SPF/DKIM/DMARC records and reputation services, all to avoid a £3/month mailbox — and the failure mode isn’t a hobby annoyance, it’s a job offer that lands in someone’s spam folder. I dug into the full picture in Stalwart: self-hosting your own email server, and the honest conclusion there is the same as here: if you do it because running your own mail server is a thing you find genuinely interesting, brilliant. If you do it to save £36 a year, you have catastrophically mispriced your weekend.

The “worth it if you enjoy it” bucket is the one that gets miscategorised most. A media server or a home-automation stack is genuinely rewarding to run if tinkering is the point, but people file it under “saving money” and then resent the upkeep when it turns out to be a hobby, not a savings account. The tell is how you feel when it breaks on a Sunday. If fixing it is mildly satisfying, it’s in the right bucket. If it fills you with dread, you’ve mispriced it and you should think about paying someone else to run it.

Buying the hours back

If the time cost is the real budget, the sensible move is to spend engineering effort reducing it — treating your own hours as the scarce resource they are. A few things have paid for themselves many times over in my setup:

• Automate updates you trust, review the ones you don’t. For low-risk services, an automated updater that pulls new images on a schedule removes a monthly chore. For anything stateful or important — databases, your reverse proxy, anything family-facing — keep updates manual and deliberate. The mistake is treating both categories the same.
• Make restores boring. The single highest-leverage hour you can spend is scripting and actually running a restore, so that recovery is a known, rehearsed procedure rather than a panicked improvisation during an outage. Untested backups aren’t backups; they’re hope.
• Monitor so incidents find you early. A dead renewal cron that alerts you the day it fails costs ten minutes. The same failure discovered three weeks later, after the certificate has expired, costs an evening. Cheap monitoring converts expensive surprises into cheap chores.
• Standardise the boring layer. One reverse-proxy pattern, one backup pattern, one way of laying out a Compose stack. The second service you deploy the same way as the first takes a fraction of the time, because you’re not re-solving TLS and routing from scratch each time.

None of this makes self-hosting free. It makes it cheaper per service, which is the only lever you actually control once you’ve decided the hobby is worth having at all.

The honest reframe

The healthiest framing I’ve found is to stop calling it “saving money” and start calling it what it is: buying control with time. Once you say it that way, the decisions get clearer. Is this a thing where control actually matters to me? Then the time is well spent, even if the spreadsheet disagrees. Is it a thing I’m hosting out of reflex or thrift? Then maybe the £10/month is the bargain, and my evenings are better spent elsewhere.

The corollary is that maintenance time is the real budget, not the money. The right question before adding a service isn’t “can I run this for free” — you almost always can. It’s “do I have the hours this will demand, and do I want to spend them here”. A home lab isn’t constrained by money or by rack space. It’s constrained by how many things you can keep alive before the whole thing becomes a chore that resents you.

The verdict

Self-hosting is one of the most rewarding hobbies I have, and I’m not stopping. But it is not free, and the people who insist it is are the ones who haven’t priced their own time — usually right up until the 2am disk-full alert teaches them the lesson at the worst possible hour. Host the things where control, privacy, or sheer enjoyment justify the hours, and be ruthless about the rest. Pay the subscription for the services that are cheap, boring, and someone else’s problem to keep running, and feel no guilt whatsoever about it. A £3 mailbox that just works is not a failure of self-reliance; it’s a sensible allocation of a finite evening.

The goal was never to spend nothing — that was always a story we told to justify a hobby we’d have kept anyway. The goal was to spend deliberately: to know what each service costs you in hours as well as pounds, to add things because they earn their keep in control or curiosity, and to say no to the ones that would only ever be a chore that resents you. Price your time honestly, and the home lab stops being a guilt-tinged money-saving fiction and becomes what it actually is — a hobby worth paying for, in the currency that matters most.