I spent most of a decade at a UK hosting provider being paged about other people’s deployments. A recurring type of call went roughly like this: an organisation had moved to a self-hosted platform to escape a licence bill, and had been running it successfully for about fourteen months, and something had now happened that nobody on the team knew how to handle.
Fourteen months is not a coincidence. It is roughly how long a well-built system runs before it needs something from you.
What you are actually taking on
When you take the software for free, you take on the operating work that the subscription was quietly paying for. There are six pieces of it, and only the first is obvious.
Patching. Upstream publishes security advisories. Someone has to read them, decide whether each applies to your deployment, test the patch and apply it. Not all of them will apply. Working out which do is the job, and it does not go away between incidents.
Backups you have actually restored. Nearly everyone takes backups. Far fewer restore one on a schedule to prove it works. We inherited a client whose nightly backup had been writing zero bytes for seven months and completing successfully every night. The monitoring was watching the job, not the output.
Monitoring that produces action. Not a dashboard. An alert that reaches somebody who knows what to do, at three in the morning, on a bank holiday.
Capacity. Databases grow. Disks fill. The instance that was correctly sized in year one is undersized in year three, and the first symptom is usually a mysterious slowdown that gets blamed on the application.
Upgrades before end-of-life. This is the one that bites hardest. Every upstream version has a support horizon, and the further past it you drift, the more expensive the eventual jump. Three major versions behind is not a maintenance task any more; it is a project.
Somebody who knows how it fits together. Not a runbook — a person. Runbooks cover what you anticipated.
Three viable answers
There are exactly three honest positions, and the failures I have seen almost always come from organisations that believed they were in one and were actually in another.
You operate it. Viable if you have a platform or infrastructure team with genuine Linux and database capability and the headroom to absorb the work. In practice that means at least two people who could handle it, because one person is a holiday away from being a single point of failure. If your entire infrastructure capability is one talented generalist who is already fully committed, you do not have this option, however much it looks like you do.
Someone else operates it. Managed hosting. You keep the ownership benefits — your data, your infrastructure, your exit position — and buy the operating capability. This is what most of our clients do, and it is not an admission of weakness. Running platforms is a specialism, and it is not usually the one your organisation is trying to be good at.
You do not self-host. Sometimes the right answer. If there is no data-residency constraint, no regulatory driver, and no meaningful licence pressure at your scale, a hosted SaaS product may genuinely serve you better. We have said this to prospects and lost the work, and would say it again — a client who self-hosted against our advice becomes an unhappy client eighteen months later, and everybody loses.
The half-answer that fails
The failure mode is the fourth position, which nobody chooses deliberately: self-hosting on the assumption that the operating work will be absorbed somewhere.
It looks fine at first, because a freshly deployed platform genuinely needs very little. The problems start when something needs attention and the person who deployed it has moved on, changed role, or is simply busy with the thing they were actually hired to do.
The symptoms are consistent:
- The version is two or three majors behind and nobody has scheduled the upgrade
- There is a restore procedure, and nobody has run it
- Monitoring exists and alerts route to a mailbox nobody reads
- One person knows how it fits together, and everyone knows who
- Changes have accumulated outside version control
None of these is a crisis on its own. Together they mean the eventual incident is far more expensive than it needed to be, and the organisation concludes that open source was a mistake. It was not. The operating model was.
How to tell which position you are in
Four questions, answered honestly:
- Who applies a critical security patch on a Friday afternoon? If the answer is a name rather than a role, and there is no second name, you have a resourcing problem.
- When did you last restore from backup? Not “take” — restore. If the answer is “we have never needed to”, you do not know whether you can.
- What upstream version are you on, and when does it reach end-of-life? If nobody can answer without looking it up, nobody is tracking it.
- If your most knowledgeable person left tomorrow, what breaks first? Everyone knows the answer to this. It is worth saying it out loud.
Why we are direct about this
We sell managed hosting, so there is an obvious reading of this article as a sales pitch. Fair enough. But the position we take is stricter than a sales pitch would be: we will tell you not to self-host at all when that is right, and hosting revenue is the thing we lose by saying it.
There is also a policy behind it that costs us renewals. We do not support platform versions past upstream end-of-life. Not as an upsell — because an unpatchable system on our infrastructure is a risk we are not willing to carry, and telling a client it is fine when it is not would be worse than losing them. Owen, who owns that policy, has enforced it twice this year against clients who wanted to defer.
Ownership without an operating model is not ownership. It is just an unpatched server with your name on it. Decide which of the three positions you are in, resource it accordingly, and open source will serve you for a decade. Skip that decision and the software will not be what let you down.