XiPlay logo
Deployment 5 min read

Self-hosted vs cloud signage CMS: what you're actually choosing

Both models schedule the same content. What differs is who holds it, who patches the server at 11pm, and what you're left with on the day you stop paying.

Self-hosted and cloud signage CMS products do the same job: they decide what plays, where and when. The choice between them isn't really about features, because the feature lists converge. It's about three things you can't change later without a migration: where your content physically lives, who decides when the software gets upgraded, and whose outage becomes your outage. Answer those three honestly and the decision usually makes itself.

One useful thing to know before you start: this choice is separate from the player choice. Playback happens on the device from cached content in either model, so the CMS you pick doesn't have to dictate the hardware behind your screens.

What the two models actually are

Self-hosted means the CMS runs on infrastructure you control: a server in your building, or an instance in your own cloud account. You install it, you back it up, you upgrade it. Cloud means a vendor runs the CMS and you use it as a service, usually on a subscription, with the server side handled for you.

Xibo® happens to exist in both shapes, which is why this comes up so often in our conversations. It's published as software you can host yourself, and Xibo Signage Ltd. also sells a hosted service. Same CMS, two operating models, and a genuine decision in the middle. It's also why "Xibo hosting" and "Xibo cloud" get used to mean two different things: running the CMS on your own infrastructure, or renting it as a service. Worth pinning down which one a colleague means before the budget conversation starts.

The four questions that decide it

  1. 1 Where is your content allowed to live? Some organisations have a policy, a regulator or a security team that answers this for you. If media and schedules can't leave your network, the decision is already made and the rest of this post is background reading.
  2. 2 Who upgrades, and when? Hosted means the vendor upgrades on their schedule, which is usually a benefit and occasionally a Tuesday you didn't plan for. Self-hosted means you upgrade on yours, which is a benefit right up until nobody does it for two years.
  3. 3 Who is on call? A self-hosted CMS is a server with a database, backups, certificates and an operating system that needs patching. That work is real whether or not anyone is assigned to it.
  4. 4 What happens if you stop paying, or the vendor stops trading? With self-hosted you still have the server, the database and the media. With hosted, ask what export looks like before you sign, not after.

Where cloud genuinely wins

We don't sell a CMS in either shape, so take this as a neutral read. Hosted is the right answer more often than engineers like to admit:

  • Nobody on your team wants to run a server, and pretending otherwise ends in an unpatched box under someone's desk.
  • The estate is small, and the admin time saved is worth more than the subscription.
  • You want one number in the budget instead of a server, a backup target and a share of someone's week.
  • You need it working this month rather than after an infrastructure request.

The common thread is capacity. Hosting is not hard; it's just continuous, and continuous is what small teams run out of first.

Where self-hosting genuinely wins

  • Content that can't leave the network: internal comms, patient-facing material, anything covered by a data policy that predates your signage project.
  • Segregated or air-gapped sites, where there is no path to a vendor's cloud by design and no roadmap will create one.
  • Integration with internal systems (a database, an intranet, a queue system) that a hosted CMS can only reach through a hole in the firewall you'd rather not open.
  • Upgrade control, so a CMS change lands when your estate is quiet rather than when the vendor ships.
  • Estates large enough that per-something pricing starts to shape decisions you'd rather make on merit.
Note: Self-hosting is not the same as being unsupported. You can host it yourself and still pay someone (the vendor, a partner, your own MSP) to keep it healthy. That middle option gets overlooked, and it's the right answer for a lot of estates.

The cost comparison people get wrong

The tempting comparison is subscription against zero, because a self-hosted open-source CMS has no licence fee. That's not the comparison. Self-hosting has costs; they just arrive as categories rather than an invoice line: the server, the storage that grows with your media library, backups you actually test, TLS certificates, OS and application updates, and the hours somebody spends on all of it.

We won't put numbers on those, because your numbers are the only ones that matter, and invented averages are how vendors win arguments they should lose. The exercise worth doing is honest and quick: list the categories, put your own figures against them, add the cost of the day it breaks and nobody knows how to fix it. Compare that total to the subscription. Sometimes self-hosting wins by a mile; sometimes it loses, and it's better to find out on a spreadsheet.

The part that isn't part of this choice

Here's the thing most comparisons skip. In a well-built signage stack, the CMS is not in the playback path. The player collects its schedule and media, caches them, and renders locally. The CMS decides what should play and supplies the files; it isn't consulted frame by frame.

If the CMS is down, an offline-first player keeps showing its last schedule. Only the refresh stops.

That has a practical consequence for this decision: CMS availability and screen availability are different numbers, as long as your player was built that way. It also means you can change your mind later about hosting without touching a single screen, because the players talk to a CMS address, not to a hosting model.

The exception is the air-gapped case, where both layers have to cooperate. A site with no internet needs a CMS on the local network and a player whose licensing never phones home. Miss either half and the site doesn't work.

How we'd decide

If a policy tells you where content must live, follow it. If not, ask who will own the server a year from now and whether that person knows it yet. A named owner with time makes self-hosting the better long-term position on control and cost. No named owner makes hosted the honest choice, because an unmaintained CMS is worse than a rented one.

Then pick your players on their own merits. That's a hardware and reliability decision, and it deserves its own argument.

More from the blog

Ready to light up your screens?

Start a 14-day free trial: every feature, no card required.