Design deployment groups by splitting the target devices into a handful of ordered groups, starting with a small, varied cohort and growing each step. Let the install result of one group decide whether the next one starts. That way a bad release harms hundreds of devices, not the whole fleet.
What a group is
A deployment group is a slice of the devices selected for one rollout. The open source update server Eclipse hawkBit describes rollouts as taking a target filter, a chosen set of software, and automatically splitting the target list into a defined number of groups. Groups then start in a cascade based on the installation status of the previous group. You can use the same idea with any update system, even if you build the logic yourself.
How to choose the cohorts
Random slices are fine, but mixed slices are better. A first group that is all one hardware model proves little about the others.
| Group | Suggested contents | Purpose |
|---|---|---|
| 1 | Internal and test devices | Catch obvious breakage |
| 2 | A few percent of the fleet, mixed models | Catch model specific faults |
| 3 | A larger slice across regions | Catch network and carrier effects |
| 4 | Everything left | Finish |
The percentages are yours to set. Fleet size, device value, and how hard a field recovery is should drive them.
Steps
- Define the target filter: hardware model, current release, region, and health.
- Exclude devices that are low on storage, low on battery, or recently failed an update.
- Choose the number of groups and their sizes, smallest first.
- Decide the success condition for each group, for example a percentage of devices reporting the new release and healthy.
- Decide what happens on success: start the next group automatically, or pause for a manual check.
- Decide what happens on failure: stop the whole rollout.
Where the pause matters
hawkBit documents two success actions. The default starts the next group automatically. The other pauses after a group succeeds, so someone can run extra checks before the rollout resumes. Use the pause on the first jump in size, and on any release that touches the bootloader or the connectivity stack.
Keep a record
Save the group definitions, the thresholds, and the timing with the release record. If something goes wrong in the field months later, you can say who got the release when.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch how monitoring reports change over time. A staged rollout depends on exactly that kind of continuous signal between groups.
Safeguard helps on the dependency side of this: scanning the SBOM of the release before it enters group 1, so known issues are caught before any device is touched. The free scan is at gold.safeguard.sh/scan.
Quick check
How many groups should a rollout have?
Enough that the first group is small and each step grows. Three to five is common, but the right number depends on fleet size and the cost of a bad update.
Do I need a dedicated update server for staged rollouts?
No. You need device targeting, group ordering, and a result feed. Some teams build this; others use an open source server.
Sources
Last reviewed: 19 October 2026.
