Self hosted signage CMS or per screen subscription at 50 screens

What you are choosing between

Three arrangements cover nearly every network:

• A CMS built into the display. Some commercial displays ship with one. It is normally tied to that maker's screens, lighter on scheduling and reporting, and several makers switch on a recurring fee once you start using the remote features. It also locks the whole network to one hardware line.
• A hosted platform billed per screen. The vendor runs the servers. You get a web dashboard, a player app for each screen, support and backups, for a fee that repeats for every screen, every month.
• A self-hosted CMS. You install the CMS on one server you control, on site or in a data centre. The players check in over the network and pull their playlists. You own the updates, the backups and the security. Several open-source projects in this category are free to license; the real cost is the server and the hours.

We sell Android all-in-one screens with a free player and no subscription. That player is designed to pull a playlist from your own web server over HTTPS on a timer, which is the self-hosted path with no per-screen fee, and a customer may install their own cloud CMS app on the unit instead. If the CMS you want insists on an x86 player box, these Android units are not that; buy the player box and hang any screen that suits the wall.

The fee side for small networks is covered on its own in No subscription: what it really costs you. This page compares the two structures at 50 screens and up.

Side by side at 50 screens

Both choices run the same screens on the wall. The difference is who runs the server side, and how the bill grows when screen 51 arrives.

Where a per-screen subscription wins

Under about 10 screens, take the hosted plan. One site, no server skills in the building, and a fee smaller than the hours it replaces: that is its home ground. A single restaurant running menu boards that change with the seasons fits it exactly. If you sell time on the screens to advertisers, you need proof-of-play reports; hosted platforms normally ship them, so ask any self-hosted candidate for the same reporting before you pick it.

Where a self-hosted CMS wins

From about 10 screens up, the repeating fees outgrow the hours and self-hosting wins on running cost. Three situations push the same way:

• A network that keeps growing. Screen 51 arrives and the server does not care; the 51st fee does.
• Sites with no internet link. On a plant, one server on the local network feeding the shop-floor notice boards keeps content current with nothing leaving the site.
• Data you want in house. The schedules, the media and the playback logs sit on your machine.

Whether that server needs an internet connection, and what for, is its own question: Does an on-premise signage CMS server need internet answers it. Remote management from home is a network path question under any software; Plan a remote signage content workflow walks through the layout.

The hours a self-hosted server really takes

The server is a small appliance with a job list: security patches on a monthly rhythm, backups verified with a scheduled test restore, player app updates, and a check that every screen still checks in. The two faults that fill that time are a player that keeps losing its CMS connection and media downloads that fail behind a reverse proxy. Budget half a day a month for one server and give it one named owner. One box is one point of failure, so keep a restore image you have tested, and add a second machine or a service contract if a day of dark screens would stop the business. The screens are the forgiving part: a player that pulls its playlists keeps the last copy, and ours is designed to start again within seconds and go back to playing if the app stops.

Worked example: 50 screens, one update a week

Inputs. 50 screens, the case this page works. One content update every week, an illustrative planning number; real networks land anywhere from weekly to a few times a year. One media pack of 50 MB per screen per update, also illustrative; a handful of JPG slides plus one short MP4 lands near that size. A small-office uplink of 20 Mbit/s. Hosted platforms bill per screen every month, which is the standard structure. The self-hosted side is one server.

Rule. A per-screen bill multiplies the monthly rate by the screen count. The server's delivery load is screens × pack size, once per update, and it does not change the size of the server.

Arithmetic.

• Bill: 50 screens × the one-screen rate = 50 fees a month. At 100 screens it is 100 fees; the bill doubles again while the server side stays one machine.
• Load: 50 screens × 50 MB = 2,500 MB = 2.5 GB pulled from the server per update. One update a week: 2.5 GB × 4 weeks = 10 GB a month served.
• Pipe check: 2.5 GB = 20,000 Mbit. 20,000 Mbit ÷ 20 Mbit/s = 1,000 s, about 17 minutes of uplink time. Stagger the players' pull timers overnight and the line never feels it; if all 50 pull at once, each gets 20 ÷ 50 = 0.4 Mbit/s and still finishes in the same 17 minutes.
• Hours: half a day is about 4 hours, so 4 h × 12 months = 48 hours a year, about 6 working days of care.

Result and decision. At 50 screens, self-hosting trades 50 monthly fees for one server and about 6 working days a year. Above about 10 screens those avoided fees outgrow the hours; below that they do not.

The decision

Recommendation: take the hosted per-screen plan below about 10 screens, and self-host from about 10 screens up if one named person will own the server for patches, backups and restores. If nobody will own it, stay hosted until you can assign someone, because an unpatched server is a worse bet than any fee. On plant sites with no internet, self-host on the local network whatever the screen count. Past a few hundred screens the choice stops being close: the common setup at that count is a dedicated local server on the site feeding the whole estate, sized once, with the per-screen fees gone entirely.

Questions