For 4 screens growing to just under 10, the no-subscription route that works is a browser kiosk on each screen with a 15-minute reload, provided your board tolerates the refresh schedule of your data tier. Self-host a CMS only if you already run servers, and keep any subscription only where the data must be younger than scheduled refresh can deliver.
You have 4 screens now and a plan that ends somewhere under 10. You want the dashboards live on them, and you want the per-screen subscription gone. That is doable, and the choice of route comes down to one number: how old the data on screen is allowed to be. If a board up to 3 hours old is fine, a browser kiosk on each screen with a 15-minute reload does the whole job with no server and no service. If the board must be younger than your data tier can deliver, the fix lives in the data connection, not at the screen. This page compares the four routes, works a plant example with the arithmetic shown, and gives the decision for a fleet of 4 to just under 10 screens.
What decides it: the age of the data on screen
The screen shows what the report's data connection delivers, and nothing installed at the screen changes that. Power BI's published service limits give the standard per-seat tier up to 8 scheduled dataset refreshes a day, one every 3 hours, and capacity-based tiers up to 48 a day, one every 30 minutes. The plant-floor ask is often a 5-minute board; scheduled refresh on the standard tier cannot deliver one, and the documented way around the schedule is a direct connection to the source, such as DirectQuery, which is a data-project decision.
The screen adds its own delay. A kiosk browser that reloads the report every 15 minutes shows data up to 15 minutes past the last refresh. Worst case on the standard tier is 3 hours from the refresh schedule plus 15 minutes from the reload, about 3 hours 15 minutes. On a capacity tier it is 30 minutes plus 15, about 45 minutes.
So write down the oldest data each board may show before you pick software. A shift-review wall read at every shift change lives with 3 hours. An andon board that drives line calls does not, and no signage choice fixes that. The same arithmetic for a web OEE board on a factory TV is worked through in showing a web OEE dashboard on a factory TV screen.
The four routes
Browser kiosk. A browser on the screen, or on a small player box behind it, opens the report URL full screen in kiosk mode with a reload timer. Set the timer to 15 minutes as a working default and tighten it only after a day of watching one screen. There is no server, no account and no service. The mechanics of getting a live dashboard onto a screen, start to finish, are in display a live dashboard on a signage screen.
Self-hosted open-source CMS. A signage CMS runs on a server you own; you build playlists that mix the dashboard page with notice slides, and each screen points at the server. Count the ongoing work, not just the install: OS patching, backups, and, when the server is reachable from the internet, a TLS certificate that expires every 90 days under the usual automated issuers and must renew itself or the screens go dark. A small x86 mini PC carries it; a Docker walkthrough for a self-hosted dashboard on a small x86 mini PC shows a complete build.
Snapshot slides. A script exports the report pages as images on a schedule, say every 10 minutes, publishes them to your own web server or a memory card, and a slide player cycles them. Data age is the export interval plus the playlist cycle. This is the route for a slide-based player, which plays images and video from a card or pulls a playlist from your own web server on a timer; a live web page is not its format. The no-login version of that setup is in offline dashboard signage for screens without logins.
Per-screen subscription. The vendor hosts the page, keeps the session alive and bills per screen. What you buy is less the picture than the removal of the server, the patching and the session management.
Side by side
| Route | Runs where | Data age on screen | You maintain | Wins when |
|---|---|---|---|---|
| Browser kiosk | Browser in kiosk mode at the screen, one URL | Dataset refresh gap + reload interval (3 h 15 min worst case in the example) | The reload timer, set once | Glance boards on 1 to 10 screens, no server wanted |
| Self-hosted open-source CMS | Your server, screens point at it | Dataset refresh gap + the CMS page reload schedule | OS patches, backups, 90-day certificate renewal | You already run servers; notices mix with dashboards |
| Snapshot slides | Images exported on a schedule to a server or card | Export interval + playlist cycle | The export job | Slide-player screens; web traffic blocked at the screen |
| Per-screen subscription | Vendor cloud, browser at the screen | Dataset refresh gap; page and session handled for you | Nothing beyond the screens | No one owns a server; boards need direct connections |
Scenario: four plant screens now, nine next year
A plant runs four 43-inch-class TVs at 1920 x 1080, one per line, viewing line 12 ft, read at shift change every 8 hours. The reports sit on the standard per-seat tier, 8 refreshes a day.
Data age. Refresh gap up to 3 hours, reload timer 15 minutes: worst case 3 hours 15 minutes on screen. The need is half a shift, 4 hours, and 3 hours 15 minutes is inside it, so the kiosk route carries this board. The andon screen over packaging needs data younger than 5 minutes and fails the same test, so it goes to the direct-connection project, not to a different wall player.
Legibility. The FHWA planning figure is 30 ft of viewing distance per inch of capital height, and 20 ft per inch for fast reading. At 12 ft, capitals need 12 ÷ 30 = 0.4 in. The panel has 2203 pixels on the diagonal (1920² + 1080² = 4,852,800, whose square root is 2203), so 2203 ÷ 43 in ≈ 51 px per inch, and 0.4 in is about 21 px. KPI figures at 96 px are 96 ÷ 51 ≈ 1.88 in and read to about 56 ft. Keep line spacing at 1.7 times capital height and the board reads from the line.
Decision for this plant: kiosks on all four screens now, a 15-minute reload on each, dataset refresh scheduled in even 3-hour steps, snapshots for the two notice screens in the canteen, and the ninth screen joins the same recipe when the line lands.
Where each route wins
- Browser kiosk wins for glance boards on 1 to 10 screens when the staleness arithmetic clears. Nothing to patch, nothing to renew, one launcher to set per screen.
- Self-hosted open-source CMS wins when servers, backups and patching are already routine where you work, when notice slides must share the screen with dashboards, and when the data must stay on your own network. At 4 screens the maintenance is the entire cost of the choice; the same question at 50 screens flips the arithmetic and is worked through in self-hosted signage CMS or per-screen subscription at 50 screens.
- Snapshot slides win when the screen is a slide player, when the plant network blocks web traffic at the screen, or when you want a separate notice or status screen alongside the dashboards, which is the job our own displays are built for.
- The per-screen subscription wins when nobody owns a server, when boards need direct data connections kept alive by someone else, or when the fleet will grow well past 10 screens and you would prefer not to own the uptime.
Before the first screen goes up
Whatever the kiosk shows, everyone who walks past reads it, including visitors and contractors. Show a copy of the report with sensitive tiles removed, and limit what the screen's network position can reach. The secure setup for private Power BI dashboards on a signage display covers that side of the job.
The decision
Recommendation: with 4 screens going to just under 10, put a browser kiosk on each screen: one report URL per screen, a 15-minute reload timer, dataset refresh scheduled as evenly as the tier allows. Take the self-hosted open-source CMS only if a server you already patch can host it and notices must mix with dashboards. Keep snapshots for slide players and notice screens. Keep the subscription only for boards that need data younger than the refresh schedule, and fix those in the data connection, not at the screen. For the full hours-and-hardware picture before you decide, what no-subscription signage really costs lists what to gather first.
Questions
Can a screen with no computer behind it show a live dashboard?
Not as a live page. A screen with no browser can show snapshots: a script exports the report pages as images on a schedule, they go to your web server or a memory card, and a slide player cycles them. The data is as old as the export schedule. For a live page the screen needs a browser in kiosk mode, which means a small player box behind the screen or the TV's own browser.
Does the 15-minute kiosk reload log the screen out of the dashboard?
A reload reopens the same URL, so a report that stays signed in through a share link or a persistent session comes back without anyone typing a password. A report behind an interactive login sits at a login mask after every reload. Publish the board through a link that asks no credentials, or use the snapshot route, and watch one screen through a full day before you roll out to all four.
What happens when a scheduled refresh fails overnight?
The screen keeps showing yesterday's numbers with no sign of trouble. Put a last-refresh timestamp tile in a corner of the report so anyone walking past can spot a stale board, and put the shift leader on the service's refresh-failure notification list. At 8 refreshes a day, one failed overnight run costs you the whole morning shift if nobody notices.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.