A deployment puts one bundle on one channel at a chosen rollout percentage. Until a bundle is deployed, no device is offered it.
The deployments screen
Open an app and select Deployments. The table lists every deployment for the app, across all of its channels, newest first, 25 to a page. The page size selector offers 10, 25, 50, and 100, and paging fetches from the server, so the whole history is reachable. The order is fixed at newest-first and columns are not sortable.
| Column | Contents |
|---|---|
| Bundle Version | The version of the deployed bundle |
| Channel | The channel it was released to |
| Rollout | A progress bar and the rollout percentage |
| Status | The deployment's status chip |
| Deployed By | The member who created it |
| Date | When it was created |
A deployment is created with the status active, and creating it retires whatever was live on that channel. Exactly one deployment per channel is active at any time:
| Status | Meaning |
|---|---|
active |
Live on its channel. One per channel |
superseded |
Replaced by a later deployment to the same channel |
rolled_back |
Was live when a rollback moved the channel off it |
A rollback is recorded as a new active deployment rather than a change to the old one.
Creating a deployment
Select New Deployment. The form is a five-step wizard.
1. Select bundle
Every bundle uploaded for this app is listed, labelled with its version and target platform, with its size and upload date underneath. If the list is empty, upload a bundle first with dya deploy — there is no upload path in the dashboard. See CLI commands.
2. Select channel
Pick the target channel. Bundles belong to the app, so any bundle can go to any of the app's channels.
3. Rollout percentage
A slider from 1 to 100, with shortcut buttons for 10%, 25%, 50%, 75%, and 100%. The default is 100%.
4. Update behavior
| Field | Default | Effect |
|---|---|---|
| Apply Mode | When Idle | Tells the device when to activate the downloaded bundle. Sent to the plugin with the update response and overrides the app's local setting for this update |
| Schedule Deployment | empty | An optional date and time. Before it passes, devices checking the channel are told there is no update |
| Delay (hours) | empty | Devices download the update now but hold it until the given number of hours has passed. Maximum 720 hours (30 days) |
Apply Mode offers When Idle (whenIdle), Immediate (immediate), On Launch (onLaunch), and Background (background). What each one does on the device is described in Plugin configuration.
Leave both Schedule Deployment and Delay empty to release immediately.
5. Review and deploy
The final step lists the bundle, channel, rollout percentage, apply mode, any schedule or delay, and the bundle's release notes. Deploy Now commits it.
Creating a deployment sets the channel's active bundle to the deployed bundle, writes an audit entry, and sends an in-app notification and an email to the other members of the organization.
How percentage rollouts work
Each device is placed in or out of a rollout by hashing its device ID together with the deployment ID. The result is stable: a device that is included stays included for that deployment however often it checks, and a device that is excluded keeps being told there is no update.
Because the deployment ID is part of the hash, a new deployment reshuffles the buckets. Deploying the same bundle again at a higher percentage does not necessarily keep the same devices in the group — it selects a fresh set of that size.
At 100% the check is skipped and every eligible device is offered the update.
A device also has to pass the channel's own rules before the rollout is even considered — platform match, version blocking, and the downgrade policy. Those are described in Managing apps and channels.
Promoting a bundle between channels
There is no promote button. To move a release from beta to production, create a new deployment, select the same bundle in step 1, and select production in step 2. The bundle's history on the earlier channel is unaffected, and both channels keep their own active bundle and rollout percentage.
Rolling back
The Rollback action appears only on active rows — one per channel — because a rollback moves a channel off whatever is currently live on it. Confirming it reverts the channel to the bundle from the deployment before that one, marks the deployment you left as rolled_back, and records a new deployment at 100% rollout marked as a rollback.
Two things to know:
- The request names the row you selected, and the server checks it is still that channel's live deployment. If someone else deployed to the channel while your table was open, the rollback is refused with "That deployment is no longer the active one for this channel" and the table reloads, rather than rolling back a deployment you never saw.
- If the channel has only ever had one deployment, rollback is refused with "No previous deployment to roll back to".
Only owners and admins can roll back. Developers can create deployments but not roll them back — see the permission matrix.
The CLI has an equivalent command, dya rollback.
Reading the results
Devices
The Devices screen lists the devices that have checked in for the app: device ID, custom ID, platform, OS version, app version, plugin version, the channels the device is subscribed to, and when it was last seen. You can filter by platform and search by device ID or custom ID.
The screen loads the 100 most recently active devices. If the app has more, a notice above the table says so and gives the true total — the platform filter and the search box apply to the loaded rows only. Export CSV downloads the full device list (up to 10,000 rows), which is the way to work with the complete set.
Analytics
The Analytics screen has a date range with 24h, 7d, 30d, and 90d presets, and covers:
- Counters — events in the selected range, events in the last 30 days, total devices, and devices active in the last 7 days.
- Event Types — a breakdown of the event types reported in the last 30 days.
- Channel Adoption — how the app's devices are distributed across channels.
- Deployment State — which bundle version every active device is actually running, as percentages, with a chip per channel showing its released version and current rollout percentage. Devices still on the version shipped in the store show as
builtin. - Top Errors — errors grouped by message, with unique devices affected, that figure as a percentage of the active install base, total occurrences, fatal count, the bundle versions involved, and when each was last seen. A warning appears if the range contained more error events than a single query scans.
- Recent Events — the raw event stream with device, bundle version, and event details.
Export CSV downloads the underlying event stream for the selected range.
Analytics reflect what devices report: the update lifecycle events emitted by the plugin, plus any custom events your app sends. See Update lifecycle.
Update logs
A per-app update log records the individual lifecycle events a device went through — check, available, download_start, download_complete, download_fail, verify_pass, verify_fail, apply_start, apply_complete, app_ready, and rollback — with filters by event type, device, and time range, and a metadata viewer per row.
This screen is not currently linked from the navigation. Reach it at /dashboard/apps/<app>/update-logs.