blazeboard.co
Skip to content

Day-to-day operations

How updates work

Automatic OTA updates, release channels, forcing an update, and rolling back if something breaks.

5 min read· Updated 2026-04-22

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.co
Served 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.

  1. 1
    Open the System tab

    Go to Admin → System → Updates on the device.

  2. 2
    Click “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 Apply button.

  3. 3
    Confirm 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.