Security & privacy
Where the data lives is the first question, not the last
For a lot of buyers this page decides it. So here is the whole answer, including the parts that are your responsibility rather than ours.
Nothing leaves your building
- Entirely self-hosted — the software contacts no external service at runtime
- No vendor cloud, no analytics, no telemetry, no licence check phoning home
- Works on a network with no internet connection at all
- Media is served from your server to your screens, over your network
Who can do what
- Five roles, from super administrator to read-only
- Access is gated on individual permissions rather than role names
- A content manager can publish without being able to add users or change settings
- Every publish, command and configuration change is recorded against a person
How screens authenticate
- A screen receives no content until a person approves its pairing code
- Codes last fifteen minutes and are single-use
- Each screen holds an opaque token, stored only as a hash on the server
- Revoking a screen stops its access immediately
- A screen can only ever read its own content — never another screen’s
How people authenticate
- Session-based sign-in over HTTPS, with CSRF protection throughout
- Rate limiting on sign-in, on pairing, and on every public endpoint
- Passwords hashed with bcrypt, never stored or logged in any recoverable form
- Sessions are same-origin only
Being straight about it
What is yours rather than ours
Self-hosting means the boundary sits in your building, which is the point — and it means some of the work sits there too. We would rather write that here than have it come up during a security review.
You own the server: patching it, backing it up, and putting it behind HTTPS. We give you the deployment scripts and a health page that tells you when something has stopped, but the machine is yours.
You own physical access to the screens. A player holds a token that can read that screen’s content; it cannot publish, cannot reach other screens, and cannot administer anything. But a set-top box in a public corridor is still a device on your network, and should be treated as one.
And you own the decision about who gets an account. The role model is granular enough to give someone exactly what they need, and no system can stop an administrator handing out administrator.
Under review
Things a security reviewer usually asks
Short answers. We are happy to go deeper on any of them.
Does it call out to the internet?
No. Not for licensing, updates, analytics or anything else. It will run on an air-gapped network.
Where is media stored?
On your server’s disk by default. The storage layer is an interface, so S3, Azure or MinIO is a configuration change rather than a rewrite.
Are player tokens recoverable from the database?
No. Only a SHA-256 hash is stored. A leaked database does not yield a working token.
What is logged?
Who did what, to which subject, from which address, and when. Content of announcements is stored, not audit-logged twice.
Can a screen be impersonated?
It would need that screen’s token, which is issued once over TLS and never displayed again. Re-pairing a reinstalled device replaces the old token rather than adding one.
Is there a dangerous command surface?
Deliberately not. There are no operating-system level commands — nothing in the panel can reboot, wipe or brick a device.
Send us your security questionnaire
We would rather answer it properly before you buy than discover a blocker after.
No open demo, no sign-up wall — a person reads every request.