When people compare an open-source tool against the SaaS it replaces, the headline is almost always the same: the license is free. And it is. The part that gets quietly dropped from the comparison is that a license fee is usually the smallest number in the whole equation. What you take on instead is a set of recurring obligations that don’t show up on any invoice, because the currency isn’t dollars — it’s somebody’s attention, on a schedule that doesn’t ask permission.
I run a directory of open-source alternatives, so it would be easy for me to just cheerlead. I’d rather be honest about the trade, because the honest version is more useful and, frankly, more interesting.
The line items nobody quotes you
Here’s where the real cost lives once “install” is behind you.
Backups — and the test you keep postponing. Snapshotting a database is the easy half. The half that costs you is verifying that a snapshot actually restores into a working system. A backup you’ve never restored is a hypothesis, not a safety net. Doing a real restore drill takes deliberate time, and the teams that skip it tend to discover the gap on the worst possible day. Budget this as a recurring task, not a one-time setup.
Version upgrades and breaking changes. Managed SaaS upgrades itself under you, usually invisibly. Self-hosted does not. Every minor release is a small reading-the-changelog tax; every major release can be a project of its own — config migrations, deprecated flags, a schema that moved. The cost here is irregular and lumpy, which makes it easy to underestimate: it’s nearly zero for months, then it’s a weekend.
Security patches and CVEs. This one isn’t optional and isn’t on your schedule. When a CVE lands in something you expose to the internet, the clock starts whether or not it’s convenient. SaaS absorbs this for you as part of the price. Self-hosting means you are the one who has to notice, assess, and patch — which in turn means you need a way to find out at all. That’s its own small standing commitment.
Monitoring and the alerts you have to answer. You can stand up observability cheaply with open-source tooling — that’s not the hard part. The hard part is that monitoring only matters if someone acts on it, and an alert at 2 a.m. lands on a human, not a dashboard. The cost of monitoring isn’t the software; it’s the on-call attention behind it.
First response when it’s down. With SaaS, downtime is someone else’s pager and someone else’s status page. Self-hosted, you are the first responder, and the meaningful number isn’t whether it breaks — everything breaks eventually — but how long it stays broken while you figure out why. That gap is paid in stress and interrupted focus, which is a real cost even though it never appears in a budget.
Auth, accounts, and permissions. Login feels solved until you self-host it. Then you own password resets, session handling, the SSO integration someone asks for, and the access reviews that quietly accumulate as people join and leave. None of it is glamorous, and all of it is ongoing.
The actual infrastructure. This is the one cost that does arrive as an invoice — compute, storage, bandwidth, and the boring-but-essential pieces like a place to keep off-site backups. It’s usually modest compared to SaaS pricing at scale, but it’s rarely zero, and it grows with you.
So what’s it really worth?
I’m deliberately not going to put a dollar figure on the human side, because any single number would be fiction. The honest framing is this: the dominant cost of self-hosting is time at irregular intervals from someone who knows the system, and the value of that time varies enormously between a side project and a business that loses money when the service is down.
What I can offer is a way to reason about it. Roughly, total cost of ownership is the infrastructure bill (predictable) plus the expected operational time (spiky), and you weigh that against the SaaS subscription you’d otherwise pay. The shape of those two curves is the whole story:
- SaaS cost scales with usage — seats, events, gigabytes. It tends to climb steadily and can get steep fast at the upper tiers, which is exactly where self-hosting starts to look attractive.
- Self-hosted operational cost scales with complexity and stakes, not usage — more or less the same handful of duties whether you have ten users or ten thousand, but heavier the more uptime actually matters to you.
That difference in what each curve responds to is the real decision axis.
When self-hosting tends to win
From watching how these trade-offs play out, a few patterns hold up:
Self-hosting tends to pay off when you already have someone whose job overlaps with operations (so the time cost is partly absorbed rather than purely added), when the SaaS bill has climbed into a tier that genuinely stings, when your tolerance for downtime is relaxed, or when data control is a hard requirement rather than a nice-to-have. Predictable infrastructure cost in exchange for owning the substrate is a fine trade — if you have the substrate skills.
SaaS tends to win when you’re small and your time is the scarcest resource you have, when downtime costs you customers or revenue directly, when nobody on the team actually wants to be on call, or when the feature you’re buying is the boring reliability you’d otherwise have to manufacture yourself.
Most of the disappointment I see comes from comparing the SaaS price against the open-source license — comparing a number against zero — and then meeting the operational bill by surprise. Put the human time on the same ledger from the start and the choice usually makes itself. Sometimes that points to self-hosting and sometimes it doesn’t, and both answers can be the right one. There’s no virtue in running your own infrastructure, and no shame in paying someone else to. There’s only the trade, made with eyes open.