Every other page in this documentation assumes these terms. Each one has a short definition here and a link to where it is covered in depth.
Organization
An organization is the billing and access boundary. It owns apps, members, API keys, and one subscription. Usage limits are counted per organization, not per app.
Members hold one of four roles: owner, admin, developer, or viewer. The owner is the only role that can change the subscription or delete the organization. See Plans and pricing.
A user account can belong to several organizations. The CLI works against one at a time — dya orgs switch changes it, and single-organization accounts are selected automatically.
App
An app is one product you ship updates to. It belongs to exactly one organization and carries the RSA public keys used to verify and decrypt its bundles.
An app has a platform value of ios, android, both, or electron. The first three are Capacitor apps that share one web bundle; electron is a desktop app. An app belongs to exactly one of those two families, because a channel serves a single active bundle and the two bundle types are not interchangeable — ship both and you create two apps. Creating an app also creates a channel named production and marks it as the default.
App ID
The app ID is the identifier your client sends on every update check, for example com.example.app. It must start with a letter and may contain letters, numbers, dots, hyphens, and underscores.
App IDs are globally unique across the whole platform, not just within your organization. Devices route their update checks by app ID alone, so two organizations can never share one. An app ID stays reserved for six months after its organization is deleted.
The app ID in your DeployYourApp configuration must match the one registered in the dashboard. It does not have to match your native bundle identifier, but keeping them the same avoids confusion.
Channel
A channel is a named update stream inside an app — production, beta, and staging are typical. Channel names are unique per app and must start with a letter.
A channel points at one active bundle. A client asks for a channel by name in its configuration; if that channel does not exist, the app's default channel is used instead. Channels count against your plan's channel limit org-wide, across all apps.
Channels carry their own delivery rules:
| Setting | Effect |
|---|---|
isDefault |
Used when a device requests no channel, or a channel that does not exist |
isPublic |
When false, only devices already subscribed to the channel receive updates from it |
disableAutoUpdateToMajor |
Suppresses updates that change the major version |
disableAutoUpdateToMinor |
Suppresses updates that change the minor version |
allowDowngrade |
When false, a bundle with a lower version than the device's current one is not served |
Bundle
A bundle is one ZIP of your built web assets, plus the metadata the platform needs to serve it: a version string, a SHA-256 checksum, an RSA signature, a file size, and a target platform of either capacitor or electron.
Versions are unique per app. dya deploy generates one from the current timestamp when you do not pass --version.
A bundle is uploaded once and can then be deployed to any number of channels. Bundles are never deleted automatically — every one you upload counts against your storage limit until you delete it. See Usage and limits.
Bundles can also declare a compatible native version range. A bundle outside a device's range is not served to it, which is how you stop new web code from reaching an older native build that cannot run it.
Deployment
A deployment is the act of pointing a channel at a bundle. It is a record, not a state — the deployment history for a channel is the list of every bundle that has been live on it, with who deployed it and when.
Creating a deployment sets the channel's active bundle immediately. A deployment carries:
| Field | Type | Default | Description |
|---|---|---|---|
rolloutPercentage |
integer 0-100 | 100 |
Share of devices eligible for this bundle |
applyMode |
whenIdle / immediate / onLaunch / background |
whenIdle |
When the client activates the bundle after downloading it |
scheduleAt |
timestamp | none | The bundle is not served before this time |
delayHours |
integer 0-720 | none | Tells the client to hold the bundle for this many hours |
"Release" and "deployment" mean the same thing in this documentation.
Rollout percentage
A rollout percentage limits a deployment to a share of devices. The server hashes the device ID together with the deployment ID and compares the result against the percentage, so:
- The same device always gets the same answer for the same deployment. A device does not gain and lose the update between checks.
- Different deployments select different devices. Being in one 10% rollout does not put a device in the next one.
- Raising the percentage on a new deployment only ever adds devices.
Devices outside the rollout receive an empty response and stay on their current bundle.
Rollback
Rollback happens at two levels, and they are unrelated.
Server-side rollback is you deciding a release was bad. dya rollback --channel production (or the dashboard) creates a new deployment that points the channel back at the previous bundle at 100% rollout. Pass --bundle <bundleId> to target a specific earlier bundle instead of the immediately previous one. The original bundle is not deleted, so you can roll forward again.
Client-side rollback is the device protecting itself. After activating a bundle the client waits for notifyAppReady(). If that call does not arrive within appReadyTimeout (10000 ms by default), the client reverts to the previous bundle on its own. The Electron updater additionally reverts after three consecutive launches without a ready signal.
Device
A device is one install of your app. On first run the client generates a random UUID v4 and stores it locally; that value is the device ID. It is not a hardware identifier and is not derived from one.
Device IDs are globally unique — one record per install, ever. The server records the platform, native app version, SDK version, architecture, first-seen and last-seen timestamps, and which channels the install follows. See SDK data collection for the full list of fields.
You can attach your own identifier with setCustomId(), and an administrator can pin a device to a specific channel for testing.
MAU
MAU stands for monthly active users. It counts unique devices that sent analytics events during the calendar month, per organization.
Both clients emit an update_check analytics event on every update check while analyticsEnabled is true (the default), so in practice any device that checks for updates counts once for that month. A device running with analyticsEnabled: false sends no events and is not counted.
The count resets on the 1st of each month. Exceeding it never blocks an update from being served. See Usage and limits for how the count is produced and where to see it.