Updates
Every screen keeps its own software up to date, pulling new releases straight from your hosted cloud. There is nothing to set up per unit, no USB sticks, and no site visits — and a bad update can never strand a screen, because it rolls back on its own.
Served from the cloud
Updates are delivered by the YBeeM cloud, not by each unit reaching out to the wider internet. A unit downloads new packages over your private network, authenticating with the cloud key that already licenses its swarm. The cloud holds the release once and serves the cached copy to your fleet, so your units never touch a git host or any upstream registry directly.
That means every screen updates through the same credential it uses for everything else. Revoke a key and its swarm stops pulling updates the moment access ends — see security for how a cloud key confines a swarm to its own resources.
Because the cloud caches each release, a large rollout does not hammer any outside service: the file is fetched once and streamed to as many units as you run.
Managed from your dashboard
Updates are driven centrally. From your dashboard you manage which releases your fleet moves to, and each unit checks the cloud for the latest published version and installs it — no logging in to individual screens.
A unit can also report where it stands: its current version, the latest available version, and whether an update is waiting. So you can see at a glance which screens are current and which are mid-rollout, all from the cloud dashboard.
Only active swarms update
Automatic updates are part of the hosted tier. A unit receives new packages only while its swarm is on an active subscription; if a swarm falls unpaid, the cloud simply withholds new package pulls for it.
Holding back updates never disturbs the live fleet: screens that are already running keep running exactly as they are. Only fetching a new package is paused, and it resumes the moment the subscription is active again.
A/B updates on the device
On each unit, the operating system lives in two slots — an A slot and a B slot. Exactly one is running at any time; the other is the spare. An update is always written to the inactive slot, so the software currently on screen is never touched while the new version is being laid down.
The flow on the device is deliberately conservative:
Download to the spare slot
The unit pulls the new packages from the cloud and writes them into the slot it is not running from.
Verify before trusting
Every downloaded package is checksum-verified against the release. If the bytes do not match, the update is discarded and the running slot is left alone.
Trial-boot once
The unit reboots into the freshly written slot a single time and checks that the kiosk software actually comes up.
Commit or revert
If the trial boot is healthy, that slot becomes the permanent default. If it is not, the unit returns to the known-good slot.
Power-cut safe, with automatic rollback
The trial boot is one-shot: the unit only makes the new slot permanent after it has proven itself. Until then, the boot selector still points at the slot that was already working. A power cut in the middle of an update, or a release that will not start, can therefore only fail to apply — it can never break the screen that is running.
If an update is interrupted or a trial boot fails, the unit rolls back to the previous version on its own on the next power-on. There is no half-installed state to clean up and no reason to visit the site — the worst case is a screen that stays on the version it already had.
Files are written durably throughout, so a screen that loses power mid-update comes back up on its old, intact software rather than a partially written one.
Nothing to set up per unit
Because updates ride on the cloud key, there is no per-device update configuration to manage. Flash the YBeeM image, join the unit to a swarm, and it is already wired to receive releases from your dashboard. From then on your subscription tracks the units you have active and updates flow to them automatically.
You can inspect a single unit's update state from its on-device web UI as well — useful when staging a screen. For everything else a unit can do on its own, see units; to go live from a fresh unit to a running wall, see getting started.