How OneAdvanced’s UK-sovereign AWS move sets the scene
On 12 August 2026, OneAdvanced announced it had deployed over 50 AI agents on UK-sovereign AWS. The headline is a clear signal: organisations that once accepted offshore data centres now demand tighter control. Digital signage is no different. When screens carry emergency alerts, visitor briefings or shift rotas, the data residency rules are the same as for any other workplace system. Self-hosted signage puts the customer in charge of where the data lives, how it is backed up, and who can access it. Cloud services still have a place, but the trade-offs are now visible on the balance sheet and the risk register.
Data residency: where the bits actually land
A cloud signage platform sends every image, video and alert to a server the customer does not own. If that server is outside the UK, the Information Commissioner’s Office (ICO) expects a transfer risk assessment under UK GDPR. Self-hosted signage keeps the data on the customer’s own infrastructure. There is no third-party data centre, no cross-border transfer, and no need to re-assess when the provider changes its hosting partner.
| Requirement | Cloud signage | Self-hosted signage |
|---|---|---|
| Data location | Provider’s choice | Customer’s choice |
| ICO transfer risk assessment | Usually required | Not required |
| Backup location | Provider’s choice | Customer’s choice |
| Access logs | Held by provider | Held by customer |
The trade-off is operational: the customer becomes responsible for uptime, backups and patching. For organisations that already run internal web servers, this is a known cost. For those that do not, it is an extra line on the IT budget.
Licensing: per-site versus per-screen
Cloud signage typically charges per screen. A 200-screen estate at £5 per screen per month costs £12,000 a year. Self-hosted signage is licensed per site. The same 200 screens cost the same £12,000 as a one-off licence, or less if the site count is lower. The maths favours self-hosted once the screen count exceeds the number of physical locations.
There is a catch: self-hosted licences are not transferable between legal entities. If a company spins off a division, it needs a new licence. Cloud providers often allow reallocation, which can be simpler for fast-changing portfolios.
Offline behaviour: what happens when the network drops
Cloud signage relies on a continuous connection. If the link fails, screens either freeze or show a cached version that may be hours old. Self-hosted signage caches content on the device by checksum. When the network drops, playback continues with the last known good files. The server is only contacted when a file changes, so a brief outage is invisible to viewers.
The difference matters most in emergency alerts. Cloud systems must send the alert in real time, which means they need a persistent WebSocket or server-sent events connection. If the connection drops, the alert may not reach the screen. Self-hosted systems poll the server at intervals the customer sets. If the network is down, the alert is queued and sent when the link returns. The trade-off is latency: polling adds a delay of seconds to minutes, depending on the interval.
Server requirements: what you need to run it yourself
Self-hosted digital signage runs on ordinary shared hosting or a virtual machine. The server needs:
- PHP 8.1 or later
- MySQL 8.0 or later
- 1 GB RAM per 100 concurrent devices
- 10 GB storage per 1,000 media files
There is no need for WebSocket support, persistent workers or root access. The software pushes nothing; devices poll the server, so the load is predictable. Backups are the customer’s responsibility. A daily snapshot of the database and media folder is enough to restore service within an hour.
Device management: what changes on the screens
Both cloud and self-hosted signage use an Android app. The difference is in how the app is installed and updated.
Cloud signage usually distributes the app through the Play Store. Updates are automatic, but the customer cannot control the timing. Self-hosted signage is installed from an APK. The customer can test each update before rolling it out, and can keep a known-good version if a new release has issues.
On televisions, the app needs the "Display over other apps" permission. This is granted once at setup, either by hand or by one ADB command during provisioning. There is no need for root, a custom ROM or a signed system image.
Failure modes: what can go wrong and who fixes it
| Failure | Cloud signage | Self-hosted signage |
|---|---|---|
| Server down | Provider’s responsibility | Customer’s responsibility |
| Network outage | Screens freeze or show stale content | Screens continue with cached content |
| App crash | Provider’s responsibility | Customer’s responsibility |
| Media corruption | Provider’s responsibility | Customer’s responsibility |
Self-hosted signage shifts the burden of troubleshooting to the customer. The upside is that the customer also controls the timeline. A cloud outage can last hours before the provider acknowledges it; a self-hosted outage can be diagnosed and fixed in minutes if the right logs are kept.
What to do next
- List every screen that will show emergency alerts or regulated content. Note where the data must reside under UK GDPR.
- Count the number of physical sites. Compare the per-screen cost of cloud signage with the per-site cost of self-hosted.
- Check the network. If it drops for more than a few minutes a month, self-hosted signage’s offline behaviour may be worth the extra setup.
- Talk to IT. If the team already runs internal web servers, self-hosted signage is a small addition. If not, budget for server costs and backup routines.
- Request a demo. Self-hosted signage has no open demo, so arrange a call to see how the polling, caching and alerting work in practice.
