Device fleets & firmware

Update control for fleets that don't call home.

Routers, firmware, kiosks and agents behind a management plane don't poll for updates. your orchestrator pushes to them. Relayer's push mode keeps the decisions (cohorts, policy, rollback, audit) while your system keeps the transport.

Homegrown wave planning

Rollout logic scattered across orchestrator scripts: percentage math in one repo, version comparison in another, and nobody is sure which cohort a device landed in last wave.

Split-brain fleet visibility

Fleet state lives in your orchestrator's database, release state lives in CI, and the two meet in a spreadsheet during incidents.

No audit trail

When an update bricks a site, "who approved this, when, and to which devices" needs an answer from an append-only log, not from Slack archaeology.

How it works

  1. 1

    Report fleet state

    POST /api/v1/fleet/report with each device's observed version, platform and your labels. Devices appear in the dashboard exactly as if they'd checked in themselves.

  2. 2

    Plan the wave in one call

    POST /api/v1/fleet/decisions with the fleet's current state. Relayer answers with one manifest-or-null per device, honoring staged percentages, channel policy and rollbacks.

  3. 3

    Push, confirm, observe

    Your orchestrator delivers artifacts over its own channel, then reports the new versions back. Adoption curves, stale devices and the audit log update in real time.

plan an update wave
curl -X POST https://your-relayer/api/v1/fleet/decisions \
  -H "Authorization: Bearer rl_YOUR_KEY" \
  -d '{
    "app": "APP_REF",
    "channel": "stable",
    "devices": [
      { "deviceId": "router-0042", "version": "1.4.0",
        "platform": "linux", "arch": "aarch64" }
    ]
  }'

Each decision is a full update manifest or null. Your orchestrator pushes the artifact, then reports back. dryRun: true previews a wave without touching telemetry.

Batch decisions

One POST plans an entire wave: up to 500 devices per call, one rate-limit hit. The same rollout engine as the pull endpoint, so staged percentages, sticky cohorts and fall-through behave identically.

Opaque device labels

Attach customerRef, siteRef, routerName, anything. Relayer stores and echoes labels but never interprets them, so your tenant hierarchy stays yours and Relayer stays generic.

Audited by construction

Every release, rollout change and rollback is recorded with its actor: human, API key or webhook. When a customer asks why a router updated at 3am, the answer is one filter away.

Point one device at one URL.

Report your fleet once and the dashboard lights up. Plan your first staged wave the same afternoon.

Start free