Use case Blog · 18 October 2026 · 6 min read

Info kiosks that stay on: managing touch screens in lobbies, museums and stations

An information kiosk looks simple: a screen in a lobby showing a map, a timetable, a museum guide or a check-in form. Behind it is usually a Raspberry Pi or a mini PC running a full-screen browser. The trouble starts with the tenth kiosk, or the first one in another city. Content changes every week, the screens are behind locked panels, and the worst thing a kiosk can do is show a desktop, an error dialog or a frozen page to a visitor.

A kiosk is a web app plus a locked browser

The cleanest setup keeps the two apart. Your content is a web app that runs on the device itself, so it keeps working when the network does not. The browser that shows it is part of the device setup, not your app:

{"services": {
  "guide": {"command": "./guide/run.sh", "cwd": "volume",
            "port": 8080, "healthPath": "/health", "expose": true}}}

Then turn on the kiosk for the fleet. Every device starts a locked full-screen browser at boot, pointed at the service marked expose. There is no desktop to escape to, the cursor is hidden for touch screens, right-click and text selection are blocked, and all of these can be changed per fleet or per device.

No blank screens, no boot text

On a Raspberry Pi the boot messages are replaced by a splash image, so the kiosk goes from logo to content. While the guide app starts, the screen shows the device name and the state of its services rather than an empty page, and it moves to the app as soon as the app answers. If the app stops answering later, the kiosk falls back to that status view instead of a browser error, which also tells a technician on site what is wrong.

See what visitors see

Open a device in the hub and ask for a screenshot of its screen. It is the fastest way to check that the new timetable is really showing in the station on the other side of the country, or that a museum screen has not been left on the wrong page. Different panels are handled with resolution and zoom settings: set them for the fleet, and let the one odd 1024x600 screen override them.

Content updates without a site visit

Push a new version of the guide and every kiosk installs it next to the running one, switches over only after the new version passes its health check, and goes back by itself if it does not. Large media that rarely changes, like videos or floor plans, can ship as a separate base folder that devices download only when it changes:

tuna push museum-guide --base ./media --notes "autumn exhibition" --percent 20

Start with the kiosk in your own office, then one venue, then everyone.

Different places, one fleet

A kiosk in the north entrance shows a different "you are here" than the one by the lifts. Give each device its own values (location, language, opening hours feed) on top of the fleet defaults, and build one app that reads them. A kiosk that loses power or network shows up as silent and can notify you, and the app can report its own numbers, such as touches per hour or the screen temperature, to a dashboard with the device's own key.

Kiosks in public places

Services run as an unprivileged user, releases are signed and checked before they run, and the remote terminal is off by default, asks for consent each time and records the session. A kiosk connects out to the hub, so nothing on the venue's network has to be opened.

Try it with your own devices.
The first 10 devices are free, no card needed.
Get started