How UniKiosk works

Most signage products are three things: a cloud CMS, a player app, and a link between them. UniKiosk removes the first and the third.

What is actually running

Two things, both on the device:

1. The player. A layout engine that composes widgets onto a grid and draws the result full-screen, with the lockdown holding the system out of the way.
2. A small HTTP server. It serves the admin console on port 8080 and the API the console talks to.

That is the entire architecture. There is no third component, which is why there is no per-screen fee: the marginal cost of your fiftieth screen to us is zero, because we never see it.

Where your content lives

On the panel. Layouts are stored as JSON in the app's data; media sits in the app's cache directory. Nothing is uploaded anywhere, which is the answer to "where is our data" and also the reason there is no proof-of-play reporting — we could not collect it if we wanted to.

What still uses the network

• Reaching the console from your laptop (local network only).
• Widgets that fetch: RSS, weather, calendar feeds, web frames, tables reading a remote CSV or JSON.
• SSDP discovery announcements, which are local broadcast.
• Syncing a network media folder, if you configured one.

Everything else is local. See how offline works for what each widget does when a fetch fails.

The publish model

Editing does not affect the wall. Changes accumulate in a draft; the screen keeps rendering the published version until you publish. The last twenty published versions are retained, so revert is one press rather than a rebuild.

What this shape is bad at

Being honest about the trade: with no central component, there is nothing to manage a fleet from, nothing to schedule across sites, and nothing to report playback to. A hundred panels are a hundred consoles today. If that is your situation, read the comparisons — a cloud product may genuinely be the right answer for you.