Use cases

Five jobs, one rollout file.

Rings and gates, on-device verification, transfer that survives a dropped link, versioned configuration, and the record all of it produces. They are separate pages because teams arrive with one of these problems, not all five.

What are you trying to fix

Use case Staged rollouts Canary to fleet, with soak windows, concurrency limits and gates that advance on confirmed units rather than elapsed time. Use case Automatic rollback Trial boot, boot counters, atomic A/B switching and an immutable recovery image, so a unit reverts itself. Use case Offline updates Resumable delta transfer, depot bundles, and gates that measure darkness against each ring's own baseline. Use case Fleet configuration Versioned configuration with per-site overlays, pins that expire, and drift detected at check-in. Use case Audit and compliance What ran on which unit, when, applied by whom, verified against what, exportable as a signed manifest.

Where these sit

Temper is not an observability platform and does not want to become another place robot data has to live. Your telemetry stack finds the bug. These five pages are about what happens next: getting the fix onto machines you cannot reach, and knowing it landed.

Fleet-wide gates read the health signals you already collect, from open Iceberg catalogs, ClickHouse, Grafana or a webhook. That is useful for the big picture and never required for a robot to save itself, because a unit with no network still has to be able to judge its own update.

Early access

Running robots in the field?

We are taking on a handful of fleets this year, in agriculture, inspection, drones and logistics. Few enough that you get direct engineering time rather than a support queue.

Founding customers get direct engineering time and a permanent founding rate.