Deployment Rings in Hexnode UEM: Phased App and Patch Rollouts

TL;DR: A Deployment Ring is a staged deployment plan, built within Hexnode’s Automation, made up of multiple rings that run one after another – each ring pointing to existing targets (devices, users, device groups, user groups, or domains) rather than containing them directly. A ring’s membership is determined from those targets only at execution time, so nothing about your existing groups changes. Deployment Rings let you release patches, apps, and policies to your fleet in controlled, layered waves instead of all at once. Progression from one ring to the next is gated by a configured success rate, and an active deployment can be paused at any ring before it reaches the rest of the fleet.

Executive Summary

Deployment Rings, in Hexnode’s Automation engine, enable phased rollouts without changing your existing organizational setup. Instead of deploying everywhere simultaneously, admins build an ordered deployment plan by assigning existing targets (devices, users, device groups, user groups, or domains) to sequential rings. Progression from ring to ring is then governed by configured success criteria.

Key points:

• Rings are a layer, not a replacement. Rings use your existing devices, users, device groups, user groups, or domains you don’t rebuild your group structure to use them.
• Layered composition, not a fixed sequence. Rings aren’t limited to a flat test → pilot → production chain; rings can compose multiple groups, overlap handling is deterministic, and deployment rings can differ per deployment type.
• Success rate controls promotion. Each ring boundary carries criteria (success rate) that must pass before the next ring receives the deployment.
• Pause and rollback are built in. A deployment can be paused at any ring, without affecting rings that haven’t started.
• Pause. A deployment can be paused at any ring, without affecting rings that haven’t started.

What are Deployment Rings?

A Deployment Plan consists of an ordered sequence of individual rings attached to a deployment (a patch policy, app deployment, or configuration change). Each ring defines:

1. Membership — The target entities assigned to the ring—selected from existing devices, users, device groups, user groups, or domains. Hexnode resolves into a final list of devices only when the ring executes.
2. Success rate criteria — The exit criteria that must pass before the deployment promotes to the next ring.
3. Promotion behaviour — automatic promotion when the success rate passes, or manual approval required.

Deployment executes ring by ring in a strict sequential order. Admins define each ring within a deployment ring by selecting existing target entities (devices, users, device groups, user groups, or domains), setting a success rate threshold. During execution, Hexnode issues commands only to the targets assigned to the active ring. Devices in subsequent rings remain completely untouched—receiving no software, patches, or configuration changes—until every preceding ring successfully meets its required success rate.

The ring object model

Rings reference targets (devices, users, device groups, user groups, or domains)—they don’t replace them

A ring does not contain devices directly. A device or user belongs to a ring by being a member of (or matching) one of the groups or targets the ring references – existing devices, users, device groups (static or dynamic), user groups, or domains – and its effective membership is resolved from those groups at execution time, not stored on the ring itself.

This layering has two practical consequences:

• Dynamic groups stay dynamic. If a ring references a dynamic group, devices that newly match the group’s criteria mid-rollout join the ring’s membership. Whether they immediately receive the deployment depends on the ring’s state (see In-flight membership changes below).
• Overlap resolution is earliest-ring-wins. If a device belongs to multiple target groups assigned to different rings within the same deployment plan—for example, if a device is part of both the IT Support group targeted in Ring 1 and the London Office group targeted in Ring 2—Hexnode resolves the conflict using an earliest-ring-wins rule. When the deployment executes, Hexnode detects that the device matches criteria across multiple stages, locks it strictly into the earliest stage (Ring 1), and automatically strips it from all subsequent rings (Ring 2 and beyond). As a result, the device receives the payload only once during the earliest rollout phase, ensuring it is never updated twice or double-counted in Later success rate metrics.

Layered, not flat

Deployment rings are not restricted to a linear test pilot → production sequence:

• A single ring can compose several groups (e.g., Ring 1=IT lab devices + designated pilot users across all departments).
• Different deployment types can carry different deployment rings—your OS patch plan and your line-of-business app plan don’t need the same shape.
• The number of rings is configurable per deployment plan based on risk: use fewer rings (e.g., two) for low-risk configuration changes and more rings (e.g., five) for high-impact updates like major OS patches.

In-flight membership changes

• A device that joins a ring whose deployment has already completed receives the deployment on its next sync.
• A device that joins a ring that hasn’t started yet simply waits with the rest of that ring.
• A device that leaves a group mid-rollout is removed from gate calculations for rings that haven’t completed.

Success rate

Every ring boundary has a success rate criteria. Promotion to the next ring occurs only when the criteria passes.

Success rate criteria you can set per boundary:

Promotion modes:

• Automatic — The deployment automatically advances to the next ring as soon as the success rate threshold is met.
• Manual Approval: If a ring fails to meet its required success rate threshold, the deployment halts. An admin must review the issue and manually approve the deployment to proceed to the next ring.

If a success rate requirement fails, the deployment holds at the current ring, and the deployment ring surfaces the failing criterion.

Pause and rollback

Pause stops the deployment wherever it is:

• Devices that already received the deployment are unaffected.
• In-progress installs on devices in the active ring complete, but no new devices in that ring begin.
• No promotion occurs while paused.
• Resuming continues from the same point.

Troubleshooting

Deployment is stuck at a ring and won’t promote.

Check the success rate panel for the failing criterion. The most common cause is reporting coverage devices that are offline or haven’t synced don’t count toward success rate, so a ring full of powered-off devices will hold the success rate criteria even with zero failures. Either wait for check-ins, lower the coverage requirement, or force-promote if you’ve verified health another way.

New devices in a dynamic group aren’t getting the completed ring’s deployment.

Confirm the devices have synced since joining the group, and that the deployment ring is still active. Devices joining a completed ring receive the deployment on next sync; a deployment ring that has been archived after full completion no longer executes.