Rollouts

Orchestrate firmware and application updates across device fleets using rolling, canary, or blue-green strategies.

Overview

A Rollout is a managed update campaign that:

1. Targets a Device Group
2. Carries a Target Version (a shadow key/value map or app version)
3. Uses a configurable Strategy to update devices in controlled batches
4. Tracks per-device success/failure and halts on threshold breaches

Rollouts can be created manually (for firmware/shadow updates) or automatically (when you deploy an application version from the Apps page).

Rollout List

Navigate to Rollouts to see all rollouts in your tenant.

Columns: Name, Target Group, Strategy, Progress, Status, Created date.

Filter by: Status, Group, Type (deploy/undeploy/manual), Strategy.

Creating a Rollout

1. Click + New Rollout.

2. Fill in:

   • Rollout Name — human-readable label
   • Target Group — device group to update
   • Strategy — Rolling / Canary / Blue-Green
   • Artifact URL — (optional) firmware download URL
   • Version Label — label displayed in device detail and history
   • Batch Size — number of devices per batch
   • Failure Threshold (%) — abort if this percentage of a batch fails
   • Batch Delay (s) — seconds to wait between batches
   • Target Version — JSON map written to device shadow (e.g. {"firmware": "v2.1.0"})
   • Rollout Policy — Additional rules (pause-on-failure, auto-resume, etc.)

3. Click Create. The rollout is created in Pending state.

4. Click Execute to start the campaign.

Strategies

Rolling

Devices are updated in sequential batches. Each batch must reach the success threshold before the next batch starts.

Batch 1: devices 1-10 → wait for success → Batch 2: devices 11-20 → ...

Best for: zero-downtime updates where gradual rollout is preferred.

Canary

A small initial batch (canary) is updated first. After manual validation, the rollout proceeds to the remaining devices.

Canary batch (e.g. 5%) → manual approval → full rollout

Best for: high-risk changes where you want to validate on a small subset before committing.

Blue-Green

Two parallel fleets (blue = current, green = new). The new version is deployed to the green group, then traffic/shadow switches atomically.

Best for: instant rollback capability with zero downtime.

Rollout Actions

Action	When Available	Description
Execute	Pending	Start the rollout campaign
Re-run	Completed	Reset all batches and run again
Pause	Running	Suspend after current batch completes
Resume	Paused	Continue from where it left off
Cancel	Running / Paused	Abort the rollout; already-updated devices keep new version

Rollout Detail

Click a rollout row to see:

• Summary — status, progress bar, target group, strategy, policy
• Dates — created, started, completed timestamps
• Batch Progress — succeeded / failed / pending device counts

Rollout States

State	Meaning
pending	Created but not yet started
running	Actively updating devices
paused	Suspended between batches
completed	All batches finished successfully
failed	Failure threshold exceeded
cancelled	Manually cancelled

Failure Handling

If a batch exceeds the Failure Threshold, the rollout halts with failed state. Devices that successfully updated keep the new version. Failed devices remain on the old version.

Use Re-run to retry from scratch (including already-succeeded devices) or investigate device events to diagnose failures.