Use cases
Staged rollouts that count evidence.
Define canary, test sites, early customers and fleet once. Every release walks the same path, and a ring only advances when enough units have positively confirmed they are healthy.
The problem with percentage rollouts
Server-side staged rollouts work on percentages and time. Push to five percent, wait an hour, look at a dashboard, push to twenty five. That works because the machines are reachable: if a box goes quiet, something is wrong, and you know within seconds.
Field robots invert that. Silence is the normal state. Half your fleet is legitimately offline at any moment, so a rollout that advances on a timer is advancing on an absence of bad news from machines that were never going to send any. The dashboard is green because nobody is talking.
The fix is to stop treating time as evidence. A ring advances when a stated number of units have positively confirmed that they booted the new image, passed their own checks and got back online. Anything else is unknown, and unknown never advances a ring.
How a ring gate actually resolves
| Unit state | Effect on the gate |
|---|---|
| Confirmed healthy | Counts toward min_confirmed. This is the only state that advances a rollout. |
| Self-reverted | Counts against max_self_reverts. One device saving itself is usually enough to halt the ring, because the device has already told you more than any dashboard will. |
| Dark, within baseline | Neither passes nor blocks. It stays in the denominator until stale_after, then drops out of it. A dark robot is never a pass. |
| Dark, above baseline | Halts the rollout. An unusual rise in silence relative to this ring's own history is the fingerprint of a release that broke connectivity, which is the one failure the cloud can still detect. |
That last row is the part teams tend to miss when they build this themselves. A release that kills the modem produces exactly the same cloud-side signal as a quiet afternoon, unless you are comparing against the ring's own baseline rather than against zero.
Rings and gates, in one file
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
The path is defined once and version controlled, so every release walks it the same way. max_concurrent limits how many units in a ring are in flight at a time, which matters when a ring is a customer site and you do not want their whole floor updating at once.
on_timeout: escalate is deliberate. When a ring cannot reach its gate within the window, the rollout asks a human. It never advances because it ran out of patience.
What this does not do
Worth being clear about
- It does not make an offline robot update faster. A unit with no signal for three weeks updates in three weeks. The gate just stops pretending that unit voted.
- It does not replace your test suite. A ring gate catches what escapes into the field, and the canary ring is where you find out that your bench coverage had a hole.
- It does not do percentage-of-fleet random sampling. Rings are defined by attributes you control, because in a field fleet a random ten percent spans four customers and three hardware revisions.
- It cannot gate on telemetry you do not collect. If nothing measures the thing that would break, no gate can watch it.
The device-side half of this is what makes the fleet-side half safe: see automatic rollback.
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.