Rollout model
A rollout turns a single signed artifact into a fleet-wide change. It binds four things together: the artifact to deliver, the devices to deliver it to, the health probe that decides whether each device kept the update, and the strategy that controls how fast the change widens. Every rollout is scoped to your fleet, and every transition it makes is recorded as an audit event.
What a rollout binds together
| Part | What it is |
|---|---|
| Artifact | A published, signed artifact identified by name and version. Kinds are model, container and config; operating-system bundles arrive through the OS update path. |
| Target group | A static group of devices, created from device names. Names that don't resolve are reported back rather than silently dropped. |
| Health probe | The check each device runs after applying the update to decide whether it is healthy. |
| Strategy | The wave plan and the failure tolerance that governs progression. See Waves & canary. |
The artifact must already exist and be signed before a rollout can reference it. There is no unsigned path: the device verifies signed metadata and bytes against its pinned trust anchor before anything is written. See How it works and The Update Framework.
The health probe
Each rollout carries one probe definition that every targeted device runs after it applies the update. A probe has a type and a target, plus timing controls:
exec— run a binary on the device. The device only runs binaries on its own allowlist; there is no shell.http— request a local endpoint and check the response.file— check for a file the workload writes when it is healthy.
A probe declares a timeout (1–300 s), a number of attempts (1–10) and an optional initial delay. If the probe passes, the device reports healthy and keeps the new artifact. If it fails, the agent rolls back to the previous artifact automatically — the device, not the server, performs the swap and the recovery.
Device states
As a rollout runs, each device reports its progress. The non-terminal states are
downloading, verifying and applying. The terminal states are:
healthy— applied and passed its probe.rolled_back— the probe failed and the device restored the previous artifact.failed— the update could not be applied or recovered.
A rollout finishes when every live device reaches a terminal state. It succeeds only if all of them are healthy; otherwise it finishes failed. A device that has been decommissioned is no longer a live target and is excluded from this accounting, so a retired device never hangs a rollout.
Evidence by construction
Creating a rollout, every device report, each wave transition, a halt, a resume and an abort are all written as append-only audit events for your fleet. This is how the platform produces an update history per device and per product without bolting logging on afterwards — and it only ever records metadata, never the contents of your payload.