When Self-Hosting Is Worth It

Self-hosting is a trade: you gain control and potentially lower marginal cost, and you accept operational responsibility. It is worth it when those responsibilities are already funded and the benefits are concrete.

The failure mode is predictable. A team deploys a Compose file over a weekend, the service works, and everyone moves on. Six months later the instance is three major versions behind, the backups have never been restore-tested, TLS renewal broke silently, and the person who set it up has left. The software was never the problem—the missing operational commitment was, and it was missing from day one.

This framework separates the cases where self-hosting genuinely wins from the ones where SaaS remains the responsible choice. The honest starting question is not “can we run this?”—almost any team can start it. It is “who keeps this healthy in month eighteen?” If you cannot name the on-call owner, restore RTO/RPO, and upgrade cadence, you are not ready—even when the Docker Compose file looks easy.

Self-hosting tends to win when…

• Data residency, air-gapped networks, or strict audit trails are mandatory.
• You already run reliable compute, backups, and on-call coverage.
• Usage would make SaaS seat or event pricing painful.
• You need deep customization or offline operation SaaS cannot provide.
• Exit flexibility matters more than managed convenience.

SaaS tends to win when…

• The service is not differentiating for your business.
• You lack patching, monitoring, or restore drills.
• Uptime requirements exceed what your team can staff.
• Time-to-value for a small team beats infrastructure work.

Hidden costs to budget

• Upgrades and breaking changes across major versions—the cost you pay most often, and the one Compose files hide best.
• TLS renewal, secrets rotation, identity provider integration, and log retention—each small, each capable of silent failure.
• Backup verification—not just backup jobs. An unrestored backup is a hypothesis, not a safety net.
• Security response when a CVE lands on Friday, including someone empowered to patch outside business hours.
• Monitoring and alerting for the service itself, not just the host it runs on.
• Documentation drift for the “how we run this here” runbook, especially after the original deployer changes teams.

A worked example: the math on a team tool

Make the comparison concrete. Suppose a 20-person team pays a SaaS €10 per seat per month—€2,400 a year. The self-hosted equivalent needs a small VM (€25–50 a month) plus operator time: realistically two to four hours a month for updates, backup checks, and the occasional broken integration, and a few unplanned hours per year for a major upgrade or incident. At a loaded engineering cost of €75 an hour, that is roughly €2,000–4,000 a year in people time before counting the VM. The seat-priced SaaS and the self-hosted deployment land in the same range—which means for this team, the decision should be made on control, residency, and exit rights, not on cost.

Now change one variable: usage-based pricing. An analytics product billing per million events can run to tens of thousands a year at moderate scale, while the self-hosted version runs on the same VM and the same handful of operator hours. There the cost argument is real and decisive. This is the general shape of the answer: self-hosting rarely beats seat-priced SaaS for small teams on cost alone, and frequently crushes usage-priced SaaS at scale. Run your own numbers before believing either side's marketing.

Failure modes to design against

• The orphaned service: the deployer leaves, nobody inherits the runbook, and the instance quietly ages until an outage forces archaeology. Prevention: named owner with a backup, and the runbook reviewed at every handover.
• The untested backup: nightly jobs ran for a year, but the first real restore fails on a schema mismatch or missing volume. Prevention: schedule restore drills—quarterly at minimum—and treat a failed drill as an incident.
• The frozen version: upgrades feel risky, so they stop; three majors later the upgrade path requires intermediate versions nobody documented. Prevention: a fixed upgrade cadence, patch-level within weeks and major versions within a quarter.
• The silent expiry: TLS certificates, API tokens, or OAuth app credentials expire without alerting, breaking logins on a weekend. Prevention: monitor expiry dates as first-class alerts, not as a thing someone remembers.
• The Friday CVE: a serious vulnerability lands outside business hours and nobody is empowered to patch production. Prevention: decide in advance who may patch without a meeting, and what qualifies.

A simple go/no-go test

Name the owner who gets paged, the restore RTO/RPO, and the upgrade cadence. If any of those are undefined, you are not ready to self-host that system—even if the Docker Compose file looks easy. The test is deliberately cheap: it takes ten minutes, requires no procurement, and predicts month-eighteen outcomes better than any feature comparison. Teams that can answer all three questions in writing almost always run their services well; teams that answer “we'll figure it out” are describing the orphaned-service failure mode in advance.

Hybrid patterns that work

• Self-host systems of record where control matters; keep commodity SaaS for email, status pages, and anything customer-facing at 3 a.m.
• Start on managed hosting of an open-source product, then pull in-house later—the open license keeps that door open, which is the point.
• Use self-host for staging/parity and SaaS for production only when policies allow.
• Sequence adoption: prove your team can operate one self-hosted service for six months before migrating the next one.

Conclusion

Self-hosting is worth it when control or cost advantages outweigh operator load you can actually staff—and the go/no-go test makes that concrete: a named owner, a restore RTO/RPO, and an upgrade cadence, written down before the first deployment. Teams that pass it tend to succeed regardless of which software they pick; teams that skip it accumulate quiet risk until an outage collects the debt. If the test fails today, that is not a defeat—a well-run hosted open-source service keeps your exit rights intact while your ops maturity catches up, and that may be the more responsible “open” choice.