Ship firmware to robots you can't SSH into.
Temper is staged, health-gated OTA deployment for robot fleets in the field: drones, rovers, sensors, and every board in between. A bad push should never end in a truck roll.
mission success ≥ 95%
obstacle response < 200 ms
48 h soak · zero safe-stops
18 confirmed · 0 self-reverts
13 dark, within normal range
rollback plan: pinned fw-2.3
atomic A/B switch armed
Verification happens on the robot, not in the cloud. Each unit boots the new image on trial and has to prove itself healthy, including getting back online, or the bootloader reverts it without anyone needing to reach it.
The problem
DevOps tooling assumes your machines live in a datacenter. Yours live in a paddock.
Every robotics company past twenty units builds the same fragile stack: Ansible playbooks, shell scripts over flaky LTE, and a spreadsheet of which robot runs which firmware. It works, until it doesn't.
Silence is ambiguous
Field robots are offline more than they're online, so silence is normal. Cloud tooling can't tell a bricked unit from one parked under a shed, and the unit that broke its own connectivity is the one you can no longer reach.
No safe failure mode
A bad push to a server is a redeploy. A bad push to a robot is a bricked unit three hours from the nearest engineer, and an SLA breach.
Fleet drift
Mixed hardware revisions, customers stuck on old firmware, hotfixes applied by hand. Soon no two robots run the same stack, and every bug report starts with archaeology.
How it works
Rollouts that treat the field as a first-class citizen.
01Rings, not blast radius
Define canary → test sites → early customers → fleet once; every release walks the same path. Offline units queue and resume on next uplink, so no unit is ever left half-updated.
02Devices that verify themselves
The new image boots on trial and must prove itself against real checks: service health, mission latency, and a successful call home. Clearing the boot counter takes a positive result, so failure is the default and nothing depends on the network staying up.
03Recovery that needs no network
The most dangerous release is the one that kills connectivity, because it takes out the channel you'd fix it over. Every unit keeps a pinned known-good slot plus an immutable recovery image the update path can't touch, so reverting never depends on reaching the robot.
04An audit trail customers trust
What ran on which unit, when, deployed by whom, verified by what. One query answers the compliance review, the post-mortem, and the "is that customer on 2.4.1 yet?" question.
# Define the path once. Every release walks it. release: nav-controller@2.4.1 rollback_to: 2.3.0 # pinned known-good slot verify: # runs ON the device, offline trial_boot: 3 attempts confirm_within: 15m checks: - service: nav-core healthy - metric: obstacle_response_ms < 200 - reachable: control-plane # killed the modem? revert on_failure: revert_and_report rings: - name: canary match: { fleet: internal } soak: 6h - name: test-sites match: { site_type: controlled } soak: 48h - name: early-customers match: { tier: design_partner } max_concurrent: 8 - name: fleet match: { all: true } requires_approval: true ring_gate: # gates on evidence, never on silence min_confirmed: 20 units # or 60% of ring, whichever is lower max_self_reverts: 0 # one device saving itself halts the ring checkin_regression: 1.5x # vs this ring's 14d dark-rate baseline stale_after: 72h # drops out of the denominator, not a pass on_timeout: escalate # ask a human; never auto-advance on_gate_failure: halt_and_rollback
On the robot
A small, boring agent
Single static binary, no ROS dependency. Pulls when it has signal, checks the signature, stages to the inactive slot, then boots it on trial and runs its own health suite. Survives power loss mid-write, and reverts itself if the suite doesn't pass.
Control plane
The rollout state machine
Holds ring membership and release state. Gates advance on positive evidence, so a dark robot neither passes nor blocks. Anomalous silence still counts: if a ring goes quieter than its own baseline, that's the fingerprint of a release killing connectivity, and the rollout halts.
Your data
Read-only, where it already lives
Fleet-wide gates query the telemetry you already collect: Iceberg, ClickHouse, Grafana, or a webhook. Useful for the big picture, never required for a robot to save itself.
Why us
We built this the hard way once already.
1,000s
of controllers, sensor boards and single-board computers deployed to live sites
10+ yrs
building hardware products with the software that runs them
0
tools on the market that actually fit the job
At Pooled Energy I ran fleet management for thousands of connected controllers, sensor boards and single-board computers sitting in customer backyards, with intermittent connectivity, no physical access, and no tolerance for a bad update.
We built it on Ansible, because that's what existed. It was never designed for machines that are offline half the day, and every rollout became a manual, nervous, all-hands afternoon. We wrote more tooling to paper over the gaps. It never got good.
Every robotics team we've spoken to since has built a version of the same thing, and hated it just as much. Temper is the tool we needed and couldn't buy.
Nicholas
Founder · Sydney
Built to complement, not replace
Your observability stack finds the bug. Temper ships the fix.
Temper reads health signals from the data platforms you already use (open Iceberg catalogs, ClickHouse, Grafana) and closes the loop they can't: detect → diagnose → deploy → verify. Device-level verification runs on the robot, so a unit that loses connectivity still recovers itself.
Your data platform
Detect
Telemetry shows obstacle response regressed after v2.4.
→Your data platform
Diagnose
Root cause isolated. The fix ships as v2.4.1.
→Temper
Deploy
Staged rollout of v2.4.1, gated ring by ring.
→Temper
Verify
Each unit confirms itself locally first. Your telemetry then proves the fix landed fleet-wide.
Early access
Running robots in the field?
We're building Temper with a small group of design partners across agriculture, inspection, drones, and logistics. If firmware rollouts are your least favourite day of the month, we should talk.
Design partners get white-glove onboarding and a permanent founding-customer rate.