A purpose-built kiosk Linux distribution boots one locked, read-only image that resets at every restart, starts a single application or a locked browser, and can take that image from a network boot server. Image from USB while the fleet sits on one site under about 25 machines; past that, or at a second address, serve the fleet from one server.
Run a purpose-built kiosk Linux distribution: a read-only image that resets at every restart, boots into one locked application, and serves a whole fleet. Boot it from USB while the fleet sits on one site and stays under about 25 machines with quarterly image changes; take the image from one network boot server past that, or at a second address. The worked example below puts hand-imaging 30 kiosks across 12 sites at 136 hours a year against about 9 hours in the first year from the boot server.
A kiosk or signage screen the public can reach needs an operating system built for the job: one application at startup, keyboard input blocked, and a fresh state at every restart. This page compares the four workable bases, lists the lockdown details worth demanding, and works the fleet arithmetic that decides when a USB stick stops scaling and one network boot server should take over the image.
The short answer
Run a purpose-built kiosk Linux distribution. It boots a read-only image straight into one locked application, usually a browser pointed at your web address, and every restart opens that image fresh, so nothing the public does on the machine survives a reboot. One image serves every machine in the fleet. Boot it from a USB stick while everything sits on one site and the fleet is small; take it from a network boot server past that point, or the moment a second address goes live. Keep Windows kiosk mode for machines that must run Windows-only software, and buy a dedicated signage player for screens nobody touches.
What decides the operating system
Four things decide it, in this order.
What your CMS runs as. If the content platform serves web pages, a locked browser pointed at its address covers the whole job and any kiosk Linux image will do it. If the content application ships only as a Windows program, the operating system is decided for you and the lockdown work happens inside Windows kiosk mode.
Reset behaviour. The public will change settings, open things and leave junk on any machine it can touch. An image that resets at every restart clears all of it with no visit. On Windows, changes persist until someone removes them, unless you switch on a write filter where your edition includes one.
Fleet size and spread. Imaging minutes per machine are cheap; site visits are not. The worked example below puts numbers on the point where a boot server pays for itself.
Lockdown depth. Demand startup into one application, keyboard input blocked in the public session, a staff breakout key sequence you set yourself, and boot straight past the desktop. A general desktop Linux can be shaped to do all of this, but you then own every piece of it for the life of the fleet.
The four options compared
| Option | Reset at restart | Lockdown | Imaging | Pick it when |
|---|---|---|---|---|
| Purpose-built kiosk Linux distribution | Yes: the image is read-only, so every restart opens it fresh | Locked browser or one application, keyboard blocked, your own breakout sequence | USB stick, or network boot from one server | The CMS is a web address and you want the tightest lockdown with the least per-machine work |
| Windows kiosk mode on IoT and Enterprise editions | Only with a write filter switched on, where the edition allows one | One locked application; two browser lockdown experiences | Install and re-image machine by machine | Machines must run Windows-only software |
| General desktop Linux with a locked autostart session | Only if you build the image read-only yourself | You build and maintain the whole lockdown | Manual or scripted machine by machine | You already run Linux staff and need a non-browser application fullscreen |
| Dedicated signage player | The player is designed to restart into its playlist | Handled by the player; no desktop exposed | Content updates from the CMS, no operating system imaging | The screen only plays content and nobody touches it |
Where Windows kiosk mode fits
Windows IoT and Enterprise editions include a kiosk mode that runs one chosen application for a single locked account. The bundled browser adds two lockdown experiences of its own: one that shows a single full-screen page, built for signage, and one that gives a restricted public browser. Microsoft's Windows kiosk configuration documentation sets out both.
Two things keep it from scaling a fleet. Local changes persist across restarts unless a write filter is on, so a machine that collects junk stays junky until someone cleans it or you re-image it. And imaging stays machine by machine; there is no supported path to serve one Windows image to fifteen machines from a boot server the way a kiosk Linux distribution offers.
One trap bites early: a packaged signage application can be absent from the kiosk application list entirely. Our article on why a signage player is missing from Windows 10 kiosk mode walks through that case and its fix.
The lockdown details to demand
Put these on the requirement list before the first machine is built.
- Startup into one application, set on the image. The application and its address belong in the image file, so every machine takes them from the same place. On a general desktop Linux this is an autostart job; our walkthrough of chromium kiosk autostart on a Linux panel shows the working pattern.
- A staff breakout key sequence you set yourself. The public session blocks most keyboard input; staff still need a way out to clear a jam or swap content. Set your own sequence and change it from anything published.
- Boot straight past the desktop. No desktop, no file manager, and no visible boot text on machines the public faces. Embedded boards print early boot messages; our article on a splash screen on an embedded Linux kiosk boot shows how to cover them.
- Power on after a cut. Set the machine's firmware to switch on when mains power returns; the option sits in the firmware's power settings. The locked image then brings the screen back on its own, with no visit.
One safety note: the breakout sequence and the staff functions behind it are the part of the system the public must never reach. Treat the sequence as a secret and rotate it when a team that knew it leaves the job.
Worked example: 30 kiosks at 12 sites, four image revisions a year
The case: 30 kiosk machines spread over 12 sites in one state, content served by the CMS the company already runs, and an image revision four times a year for browser updates and lockdown changes.
Inputs
- 30 machines at 12 sites: the scenario, a typical statewide roll-out.
- 5 minutes per machine to boot a kiosk Linux image from USB: scenario assumption, based on how long an ordinary x86 PC takes to boot a locked full-screen browser image from a prepared stick.
- 20 minutes per machine to re-image a hand-built Windows kiosk: scenario assumption, roughly half copying the image and half walking the lockdown settings and reboots.
- 2 hours per site visit: scenario assumption, covering the drive, finding the machine, imaging it and confirming it.
- 8 hours to build the network boot server, once: scenario assumption, one working day.
- 15 minutes to publish a new image revision to the server: scenario assumption.
- 4 image revisions a year: scenario assumption. Content changes flow through the CMS, so only the lockdown stack forces a new image.
Rule
Any machine-by-machine path takes imaging minutes per machine plus a visit to every site at every revision. The boot server takes one 8-hour build, then 15 minutes per revision and no visits at all. The server pays for itself when the hours it saves each year cover the build.
Arithmetic
Hand-imaged Windows: 30 machines x 20 minutes x 4 revisions = 2,400 minutes = 40 hours a year, plus 12 sites x 2 hours x 4 revisions = 96 hours of visits. Total 136 hours a year.
Kiosk Linux from USB: 30 x 5 x 4 = 600 minutes = 10 hours a year, plus the same 96 hours of visits. Total 106 hours a year.
Kiosk Linux from the boot server: 8 hours to build once, then 4 revisions x 15 minutes = 1 hour a year, and no visits. About 9 hours in the first year and 1 hour in every year after.
Result
Against the USB path the server saves 106 hours minus 9, or 97 hours a year, so the 8-hour build pays for itself in about a month. Against hand-imaged Windows it saves 127 hours a year. At a single site the visits disappear and the race narrows to imaging minutes: USB takes 5 minutes x 4 revisions = 20 minutes per machine per year, so 30 machines take 600 minutes against the server's 480-minute build plus 60 minutes a year, which breaks even at 540 / 20 = 27 machines. Monthly image revisions pull that threshold to about 11 machines.
Decision
One site with quarterly image changes: a USB stick is honest work to about 25 machines. Monthly revisions, or a second site: build the server, because visit hours swamp imaging minutes at any fleet size.
Recommendation: Build the fleet on a purpose-built kiosk Linux distribution. Boot the image from USB while everything sits on one site and the fleet stays under about 25 machines with quarterly image changes. Serve the same image from one network boot server the moment a second site goes live, or when revisions reach monthly and the break-even drops below a dozen machines. Keep Windows kiosk mode only where a Windows-only application forces it, and buy dedicated players for screens nobody touches.
When to pick something else
If the screen only plays content and nobody touches it, skip the operating system project. A dedicated signage player boots its own locked playback stack, takes content updates from the CMS and never shows a desktop; our comparison of a streaming stick and a dedicated digital signage player shows where the cheap stick stops working. A consumer TV's built-in app platform rarely offers either the lockdown or the fresh-image reset, which our piece on Android TV for digital signage covers in detail.
For pure signage on a handful of screens, our own Android panel-mount units are built for the job: the free player set up as the home app brings the show up full screen at power-on with no launcher and no keyboard, plays images and MP4 from microSD or USB with no network, and you can install your own cloud CMS app on it instead. See our signage player and the walkthrough of Android signage app startup for a single-purpose display. It is a sign player, not a kiosk platform: there is no locked public browser on it, so interactive wayfinding stays on the kiosk Linux path.
What to ask for before you commit
Get answers to five questions before the first machine ships.
- PXE on the hardware. Network boot needs network cards whose firmware includes PXE and a wired link at each machine; check the spec sheet of the exact PC model before you standardize on it.
- Cached boots. Ask the kiosk distribution's documentation whether a machine still boots its last image when the boot server is down, and what it does when it cannot reach the network at all.
- Edition and licence. On Windows, kiosk mode and the write filter depend on the edition; on Linux, check which lockdown options sit behind paid tiers of the distribution, if any.
- The update path. How a new image revision reaches the server, and how machines take it: at their next restart is the answer you want.
- The panel side. The operating system is half the stack; what the digital signage spec sheet tells you covers the other half: brightness against the room's light, the mounting, and the ports behind the screen.
Send the vendor the PC model, the machine count, the site list and the address of the CMS. Those four decide the operating system for you.
Questions
Does the image reset wipe the content on the screen?
No. The content lives on your CMS or web server, and the screen pulls it again after it boots. The reset clears only changes made on the machine itself, such as a stray download or a changed setting. Day-to-day content updates never touch the operating system image, which is why an image changes only a few times a year.
Can one boot server serve kiosks at every site over the internet?
PXE fetches the boot image using DHCP and TFTP on the machine's own network, so a machine boots from a server on its local segment. Across sites, put a small boot server or a DHCP helper address at each site, or carry the image to site on a USB stick and keep one master copy updated centrally.
What happens to a kiosk after a power cut?
Mains returns, the firmware brings the machine up, and it boots straight into the locked image; set the firmware to switch on when AC power returns, and nobody needs to visit the site. Because the machine pulls its content from the CMS after boot, the show is current, not the version from before the cut.
Do kiosk machines need special hardware?
No. A purpose-built kiosk image runs on ordinary x86 PCs. The network boot path adds two requirements: network cards whose firmware includes PXE, which most business-class machines have, and a wired network link at each machine. Check the exact PC model's spec sheet for PXE support before you standardize the fleet on it.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.