Xibo alternative
cloud SaaS without server

Read that list and the realistic estimate falls out of it: an afternoon for a single venue, a couple of split days for a small estate. Almost none of that time is spent on files. It is spent rebuilding decisions that were made once and never written down.

Which suggests the one thing worth doing before you touch anything: screenshot your schedule. Not the layouts — those you will rebuild anyway and probably improve. The schedule is the part nobody remembers and nobody can reconstruct from the screen itself.

There is an upside to layouts not transferring, and it is not a consolation prize. Most Xibo layouts that have been running for two years carry two years of patches. Rebuilding from the actual content rather than copying the old structure takes the same afternoon and tends to produce something better.

Three cases where running it yourself is the better choice, not the cheaper one:

• There is already an IT function and enough screens. Once someone is paid to maintain servers regardless, the marginal cost of one more is small — and at scale the licence side stops being marginal.
• The data genuinely cannot leave. Not as a preference: as a documented requirement. In that case hosting is not a cost comparison, it is a constraint, and the constraint decides.
• Something has to be built that does not exist. An integration with an internal system, an unusual layout, a device nobody supports. If the roadmap will never contain it, the only route is the one where you can write it yourself.

What these three share is worth stating plainly: none of them is about price. The cost comparison is usually close enough that it does not decide anything on its own, and treating it as the deciding factor is how people end up maintaining infrastructure they did not want in exchange for a saving they cannot find afterwards.

The corollary is equally useful in the other direction: if none of the three applies, the comparison is not really about hosting. It is about who will do the work, and that question has the same answer regardless of which system is chosen.

Check whether any of those three describes your situation before opening a feature table. If none does, the table will not change your answer — and if one does, it already has.

Applying a security update is the easy half. It takes twenty minutes and almost always goes fine. The expensive part comes before: knowing that it exists. There is no invoice to remind you, no renewal email, nobody who rings. The only way to find out is to be subscribed to wherever it gets published and to read it on the day, and that has to be kept up for years — including the months when business is bad and you have other things on your mind.

And the flaw does not tell you it is being used. A compromised server does not go down: it keeps serving your screens exactly as before while doing something else underneath. That is why this risk is unlike every other one in the comparison — the others show themselves the day they happen, and this one can run for months without anything you look at changing.

Which is why the honest question is not whether you can install it. It is who is going to look at this next March, and what happens if that person is busy that month. If that question has an answer with a name and a slot in a calendar, self-hosting is an excellent option and it is cheaper. If it does not, what you are choosing is not a server: it is a countdown that starts on installation day.

Straight with you: this is not an argument against open source, which we use and live off. It is that the licence and the hosting are two separate decisions, and only the second one commits you to watching.