Use cases

Configuration and drift, tracked on purpose.

Mixed hardware revisions, customers held on older builds, and hotfixes applied by hand. Temper versions configuration the same way it versions firmware, so being behind is a state with a reason and an expiry.

Drift is not the enemy, undocumented drift is

The instinct is to make every unit identical. In a field fleet that is neither achievable nor desirable: one customer validated a build and will not move until their peak is over, one site has narrow aisles and different speed limits, and two hardware revisions genuinely need different parameters.

What goes wrong is not that the fleet differs. It is that nobody can say how. Firmware is versioned, configuration lives in whatever was on the unit when it shipped plus whatever a field engineer changed at three in the morning, and every bug report starts with archaeology.

Treating configuration as a versioned artifact with the same rollout path as firmware makes the difference explicit. A pin is a decision with a reason attached, not a gap in the spreadsheet.

Base, overlays, pins

01A versioned base

One set of defaults, version controlled and rolled out through the same rings and gates as an image. A config change that breaks a fleet is exactly as dangerous as a firmware change that does.

02Overlays that match attributes

Per-customer, per-site or per-hardware-revision differences are expressed as overlays matching attributes you already maintain, rather than as a hand-edited file on each unit.

03Pins with an expiry

A customer held back carries a reason and a date. The fleet view separates units that are behind on purpose from units that are behind because a rollout quietly stalled two months ago.

04Drift detected, not discovered

When a unit reports configuration that does not match what it should have, that is surfaced at check-in and reconciled in the next window, never silently mid-shift.

Configuration in the same file

rollout.yamlexcerpt
config:
  base: nav-defaults@4          # versioned, like firmware
  overlays:
    - match: { customer: northgate }
      set: { max_speed_ms: 1.2, dock_timeout_s: 90 }
    - match: { site: dc3, aisle_width: narrow }
      set: { turn_radius_m: 0.8 }

pins:
  - { customer: northgate, version: 2.3.0, until: peak_end, reason: peak_freeze }

drift:
  detect: on_checkin
  report: always
  reconcile: on_next_window     # never mid-shift, never silently

The reconcile: on_next_window setting matters more than it looks. Automatically correcting a drifted unit sounds obviously right until it happens to a robot halfway through a shift, at which point you have caused an incident in the name of tidiness. Detection is immediate; correction waits for a window.

What this does not do

Worth being clear about

  • It is not a secrets manager. Credentials are delivered, not stored here, and the source of truth should stay wherever your security team already put it.
  • It does not manage runtime application state. Live parameter tuning during a mission belongs in your stack, not in a rollout system.
  • It does not resolve conflicting overlays for you. Two overlays that both match a unit and disagree is a configuration error, and it is reported rather than silently ordered.
  • It will not tell you what the right value is. It will tell you, precisely, what value each unit has and when it got it.

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.