Update Model

There are two operator paths for a device you've already installed and registered. OTA from the dashboard is the normal path. Manual SSH exists only for the rare case where the dashboard cannot reach the device or OTA itself is unavailable.

The fleet is in transition: legacy git-v1 devices still update through Git references, while bridge releases and artifact-v2 capable devices move toward the artifact-v2 target path: ByteGate-managed provisioning, release-channel assignment, and immutable release artifacts. Do not treat appliance-side GitHub access or pulling a branch tip as the future default.

Bytekey QR sync follows the same software-update path, but its access feature is enabled separately. Ship the edge release with bytekey_qr_sync disabled, then use Bytekey QR Sync readiness before enabling QR-specific cohorts.

OTA (over-the-air) — the default. An operator triggers an approved release or staged rollout from the Cloud Dashboard. The device applies the assigned release, restarts itself, and reports the new edge_version on its next heartbeat. No SSH session, no physical access to the Pi — this is how every routine update should happen.

Manual SSH — break-glass only. For a device that's offline from the dashboard's point of view, or when OTA itself is unavailable, you can SSH into the Pi and run the update directly. This is a fallback path, not a parallel everyday workflow — see the Manual SSH fallback page for when and how.