Day-to-day operations
How updates work
Automatic OTA updates, release channels, forcing an update, and rolling back if something breaks.
Blazeboard devices update themselves. No cron to manage, no binaries to copy around, no approval workflow. The orchestrator polls our release service on a schedule, verifies signed component manifests, applies only the pieces that changed, and keeps the kiosk display running through normal maintenance releases.
How updates work
| Check cadence | Hourly The orchestrator checks shortly after boot and then once per hour while the device is online. |
|---|---|
| Update endpoint | https://releases.blazeboard.coServed from Cloudflare with Ed25519-signed manifests. |
| Architecture | aarch64 (ARM64) All current Blazeboard hardware is ARM64. The orchestrator identifies itself so the server never hands down a mismatched binary. |
| Network | Outbound HTTPS only No inbound connections; nothing is exposed to the internet from your store. |
If a newer release is available, the orchestrator downloads the changed component, verifies it, and applies it in place. Web app updates restart the app container; player and orchestrator updates restart only the component that changed. End-to-end, a typical update takes 1–3 minutes depending on artifact size and your internet connection.
Force a check now
If you’re in the dashboard and want to kick the tires, you can force an update check from the device admin UI.
- 1Open the System tab
Go to
Admin → System → Updateson the device. - 2Click “Check for updates”
The orchestrator reaches out to the release service immediately. If a new version is available, you’ll see it listed with an
Applybutton. - 3Confirm and wait
Applying the update triggers a download, signature verification, and container restart. Refresh the page after ~2 minutes to see the new version reported under the current version badge.
What’s verified before an update applies
Every update has to pass multiple checks before the orchestrator will touch a running system:
- SHA-256 hash of the downloaded artifact matches the hash declared in the release manifest.
- Ed25519 signature of the artifact hash matches a public key compiled into the orchestrator binary itself.
- Component targeting ensures the device only applies manifests for the orchestrator, web app, or player component it requested.
Release channels
Customer devices run the stable channel by default. Blazeboard also publishes a beta channel for internal and assisted preview testing before a release is promoted to stable.
If an update fails
- Download failed. The orchestrator retries on the next hourly cycle. If your internet is down, updates simply pause until it’s back.
- Signature check failed. Updates stop. Open a support ticket — we’ll check our release pipeline immediately.
- Container won’t start on new version. The watchdog escalates through restart paths, and support can promote or pin a known-good component release remotely.