For three months the argument about self-hosted collaboration has been settled by events rather than by principle. Organisations running their own messaging and file platforms went to full remote working without renegotiating a licence, without a procurement cycle and without asking anyone's permission. Organisations that had planned to migrate to a hosted suite this year found themselves doing it in nine days. Both groups learned something uncomfortable. The self-hosted stack proved that it could carry the whole company. It also proved that the cost of running it was never the licence.
Three workloads, three completely different problems
The phrase self-hosted collaboration hides the fact that it means three technically unrelated things, and they are not equally hard. Messaging is easy. A self-hosted chat server for a few thousand users is a modest machine, a database and a reverse proxy. Load is predictable, the traffic is small, and the failure modes are boring. Teams running this configuration barely noticed March, beyond a jump in message volume and a scramble for mobile client configuration. Files and synchronisation are moderate. The server is simple; the clients are not. Every remote worker synchronising a large shared folder over a domestic connection generates far more traffic and far more conflict resolution than the same person did on an office network, storage grows faster than anyone forecast, and external sharing, which was rare when everyone was in the building, suddenly becomes the primary way documents reach clients and auditors. The problems here are capacity planning and sharing governance, not software. Real-time video is hard. Media does not behave like messages. Concurrency drives everything, bandwidth costs are real, and running a media server that holds up for a forty-person all-hands is a different discipline from running a web application. The projects have improved substantially this spring, and the honest position in June is that self-hosted video is entirely workable for small and medium meetings and still demanding at scale. The practical conclusion most organisations are reaching is a split: host the messaging and the files, where the data sensitivity and the retention obligations sit, and be pragmatic about large video events.
| Workload | Operating concern | What to test |
|---|---|---|
| Messaging | Access and service continuity | Identity, mobile notifications and recovery |
| Files and synchronisation | Storage growth, sync conflicts and sharing | Remote connections, external access and restore |
| Real-time video | Concurrency and network capacity | Representative meetings and a fallback path |
Qualitative summary of this article's source text, not a measured outcome or performance estimate.
What March actually exposed
The self-hosted stacks that struggled did not struggle because the software was inadequate. They struggled because they had been sized and operated for a world where most users were on the office network. Gateways and reverse proxies designed for a few dozen concurrent external connections met the entire workforce at once. Authentication systems that had never been exposed to the internet were exposed in a weekend. Mobile clients, which in many organisations had been a nice-to-have, became the primary interface for half the workforce and turned out to be configured badly or not at all. And backup windows that comfortably fitted a quiet evening no longer fitted, because there is no longer a quiet evening. There is a sovereignty detail worth knowing here, because it surprises people who chose self-hosting for exactly that reason: mobile push notifications for self-hosted collaboration apps typically route through a notification proxy operated by the software vendor and, beyond it, through the platform vendors' push services. The message content can be kept minimal, and the dependency does not disappear. If your reason for self-hosting is a strict data-location requirement, document what the push path carries and decide explicitly whether it is acceptable, rather than discovering it in an assessment.
The operating model is the decision
The real comparison is not software cost against subscription cost. It is this: are you willing to own an operations function? Owning it means a named administrator with a named deputy, a patching cadence measured in days for internet-facing components, backups that are restored and verified on a schedule rather than merely configured, capacity headroom planned for the next surge rather than the last one, an upgrade path that is exercised at least twice a year, and a support contract with a vendor who will answer at the wrong hour. Budget realistically for infrastructure, a support subscription and somewhere between half and one full-time person, and compare that with the subscription cost at your actual headcount. At two hundred users, that comparison usually favours the hosted service unless you have a requirement that forbids it. At two thousand, with a real compliance driver, it usually favours self-hosting. The mistake is not choosing either one; it is choosing self-hosting for the licence saving and then not funding the operations.
Practical Guidance for Self-Hosted Stack Deployment
- Decide workload by workload, not as a philosophy. Messaging and files self-hosted, large video pragmatically external, is a legitimate and common architecture. Purity is not a requirement.
- Size for a fully remote workforce, permanently. Gateway concurrency, bandwidth, storage growth and backup windows all change when nobody is on the office network, and that is now the baseline rather than the exception.
- Name an owner and a deputy, in writing, with rostered cover. A stack that only one person understands is a single point of failure with a passport and a holiday entitlement.
- Buy the support subscription. Open source is not free support, and the moment you need help is the moment you are least able to research it.
- Patch internet-facing components on a days cadence and subscribe to the security advisories. Your collaboration server is now an internet-exposed application holding everything the company writes down.
- Restore from backup on a schedule and record the result. Untested backups on a self-hosted stack are the single most common cause of the disaster that ends the self-hosting experiment.
- Govern external sharing deliberately. Expiring links, password protection, an owner for every external share and a quarterly review. Remote working has turned sharing from an occasional action into the default one.
- Document the residual external dependencies. Push notification proxies, app store distribution, any hosted component in the stack. If sovereignty is the reason you are doing this, the exceptions belong on the record.
The Regional Angle
Four considerations are specific to running this kind of stack from the Gulf. Start with where the server physically is, because latency behaves differently for each of the three workloads. Regional internet paths frequently transit Europe, and a collaboration server hosted in Frankfurt or Amsterdam is perfectly comfortable for chat, tolerable for file synchronisation and noticeably poor for video with participants in Riyadh and Muscat. Local and in-country hosting options have expanded considerably over the past two years and are now a realistic answer. Measure the round trip from your actual user locations before you choose a region, and if you keep the server in Europe for legal reasons, put the video somewhere closer. Second, check what your support contract means in local time. Most open-source vendors sell support against European business hours, which covers Monday to Friday. The regional working week starts on Sunday, and a Sunday morning outage in Dubai is Saturday night in Europe. Add to that the local holiday calendar, where Eid can remove several working days at short notice, and the support you are paying for may not be available on the days you most need it. Either buy the premium tier with genuine round-the-clock response, or accept that your first line is your own team and staff accordingly. Third, test Arabic properly before you commit. Right-to-left rendering in clients, mixed-direction text in messages and file names, Arabic file names surviving synchronisation across operating systems, and full-text search that actually indexes Arabic content: all of these vary by product and by version, and none of them are exercised by a pilot conducted in English by the IT team. Run the evaluation with the people who write Arabic every day, including on mobile, and record what does not work as a known limitation rather than discovering it after the migration. Fourth, be precise about what self-hosting does and does not achieve for organisations that chose it on sovereignty grounds. It puts the message store and the documents in a location you control, which is the substantial part. It does not remove the mobile push path, the app store distribution channel, the update servers, or the foreign support engineer who may be given screen access during an incident. Write those down as accepted exceptions with a named approver, because an unwritten exception is the one that appears in an audit finding.
The objection worth taking seriously
The strongest objection to everything above is that this spring was actually a good advertisement for hosted services. When demand tripled in a fortnight, the large platforms absorbed it by adding capacity that nobody in the customer organisation had to think about, and they did it while their own engineers were also working from bedrooms. Self-hosted stacks scaled when somebody logged in at two in the morning and made them scale. That asymmetry is real, and it is the honest case against self-hosting for any organisation without a compelling requirement. The second objection is about security posture, and it deserves more respect than self-hosting advocates usually give it. A well-run hosted platform has a security team, continuous patching and detection capability. A self-hosted server maintained by a stretched infrastructure team, exposed to the internet in March because there was no alternative, three versions behind, is not a more sovereign system. It is a more exposed one, and the sovereignty argument does not survive a compromise. The defensible position is narrow and worth stating plainly. Self-host where there is a requirement that a hosted service cannot meet, where the scale makes the economics work, and where you are prepared to fund the operations properly. Otherwise, use the hosted service and spend the effort on the things that actually differentiate: retention, sharing governance, access control and the discipline of knowing where your information lives. The stack is a means. Several organisations this spring have discovered the hard way that they bought the means and never funded the end.
Common Questions
Is self-hosted video ready for company-wide meetings?
For small and medium meetings, yes, and the improvement over the past year has been substantial. For large all-hands events, plan carefully, test at realistic concurrency, and have a fallback.
What does it actually cost to run?
Infrastructure, a support subscription and roughly half to one full-time administrator, plus the upgrade effort. Anyone quoting only the infrastructure is quoting the smallest line.
Can we migrate later if we change our mind?
More easily than from most hosted platforms, since you hold the data and the export paths are documented. Migration effort still lands mostly in history, permissions and integrations rather than in content.
What should we expect over the next twelve months?
Expect the open-source collaboration projects to keep pushing hard on video, where the gap is, and to ship better packaging and managed options so that self-hosting stops meaning hand-built. Expect European public-sector procurement to accelerate interest and funding, which benefits everyone downstream. Expect at least one significant breach of an unpatched, internet-exposed self-hosted collaboration server to be reported, and expect it to be used unfairly as an argument against the whole model. And expect more organisations to land on the split architecture: their own messaging and documents, someone else's large-scale video.
Self-Hosted Stack Deployment — we size it for a fully remote workforce, fund the operations honestly, and write down the dependencies that self-hosting does not remove.