Bundles & compatibility
A heterogeneous fleet is the normal case: different system-on-chips, accelerators, runtime versions, and operating-system lineages, all in service at once. The platform is built so that an update targets a device's capabilities, not a single golden image - and so that a payload which does not fit a device is caught before it is sent, not after.
Compatibility metadata
The compatibility story starts on the artifact. A model artifact's manifest declares the hardware profile it is built for - for example a specific Jetson class
- alongside its framework and input specification. That metadata is what lets the platform reason about fit: a model compiled for one accelerator profile has no business landing on a device that cannot run it.
Because devices report their hardware profile when they enrol, fit is a comparison between what the artifact declares and what the device actually is. See Artifact kinds for what each manifest carries and Enroll a device for how a device's profile is established.
Targeting by capability
Rollouts are aimed at a target - a device group - and shipped with a health probe and a strategy. The design intent throughout is capability-based targeting: you describe the class of device an update is for, and the platform resolves that to the matching devices. This is what keeps a single rollout safe across mixed hardware instead of forcing one image per device type.
What a bundle is
A bundle is the unit you test and roll out: a versioned set of artifacts that belong together, with the compatibility constraints that say how they fit - for example, a model that requires a given runtime version and a particular hardware profile. Grouping artifacts this way is what makes pre-flight testing meaningful: you validate the set as a whole, then ship the set as a whole.
Signed multi-component releases
The signed release manifest is the bundle definition. It fixes every component, its digest and TUF target, compatible device profiles, activation order, health policy and release-wide recovery boundary. Before exposing work to a device, the control plane resolves every component and checks the signed target policy against the selected group.
For a multi-component Linux release, the agent waits for the complete assignment set, verifies and stages every member, then activates the signed order groups. If activation or health fails, it restores every attempted member in reverse order. A local recovery journal makes an interrupted transaction recoverable after the agent restarts.
Supported transaction members are containers, models, placed configurations and systemd service binaries. RAUC operating-system bundles use a standalone release because reboot crosses the transaction boundary. Compose stacks and package-manager transactions are not accepted as transaction members.