Concepts
Apps, channels, releases, rollouts and devices: the Relayer data model.
App
One piece of software you ship. An app has a display name (rename any time) and an immutable 16-character ref used in every URL and API call - so renaming never breaks shipped devices.
Channel
A distribution track: stable and beta exist by default; add more
(internal, canary, …) freely. Devices ask for updates on exactly one
channel. Each channel can carry a policy: a minimum supported version
and an update mode - devices below the minimum receive updates flagged
required.
Release
An immutable version published to a channel: version string, markdown release notes, and a list of artifacts (platform, arch, URL, sha512, size, optional code-signing signature). Relayer never stores your binaries - artifact URLs point at your existing storage.
A release has a status:
published- servable.paused- temporarily not served; resume any time.rolled_back- permanently withdrawn (cannot be resumed; publish a new version instead). Devices fall back to the newest remaining release.
Rollout percentage
Every release has a rollout percentage (default 100). At 25%, only a
quarter of devices are offered that version. Bucketing is deterministic -
sha256(deviceId:releaseId) % 100 - so a device's answer never flaps
between checks. Devices outside the cohort fall through to the newest
fully-rolled-out release; they are never left without an answer.
Device
An installation of your app, identified by an anonymous UUID that your app
generates and stores locally, sent in the X-Relayer-Device header. No
accounts, no PII. Every update check records version, platform, arch and
timestamp - that's the fleet dataset behind the dashboard.
Devices don't have to check in themselves: an orchestrator can report
state and plan update waves on their behalf via the
push-mode fleet API, optionally attaching labels -
opaque key/values (customerRef, siteRef, …) that Relayer stores and
echoes but never interprets.
Organization
The workspace everything lives in: apps, keys, devices and the audit log are organization-scoped, and teammates hold roles (owner / admin / member) within it. See Organizations & roles.
Audit log
Append-only record of every mutation - publishes, rollout changes, key mints, webhook deliveries - with actor, IP and timestamp. Mutations that cannot be audited do not happen.