Channels & rollouts

Channels#

A channel is a named release stream — production, staging, beta. Each app build follows one channel (via channelOverride in init()), and each publish targets a channel. A device only ever sees bundles on the channel it follows.

ScaleBun.init({  // …  ota: { enabled: true, channelOverride: __DEV__ ? 'staging' : 'production' },});

# publish to each stream independentlyscalebun ota publish --channel staging   --platform androidscalebun ota publish --channel production --platform android

Manage channels from the CLI or the dashboard:

scalebun ota channels          # listscalebun ota channels create beta

Staged rollouts#

You rarely want a new bundle on 100% of devices at once. Publish at a small percentage, watch health, then widen — no re-publish needed.

scalebun ota publish --channel production --platform android --rollout 10scalebun ota rollout --percent 50    # widenscalebun ota rollout --percent 100   # everyone

The dashboard's fleet adoption shows how the rollout is landing: how many devices are on the newest bundle, on an older OTA, on the embedded binary, or pending activation.

Targeting#

Beyond the rollout percentage, you can scope who is eligible:

Native-version targeting is important: a JS bundle that expects a native module from app 1.2.0 must not reach a device still on 1.1.0.

Pause, resume, rollback#

Something looks wrong? You have immediate, no-publish controls:

scalebun ota pause      # stop new devices receiving the current releasescalebun ota resume     # continue where you pausedscalebun ota rollback   # revert every device to the previous release

The same controls exist on the dashboard's Alerts & delivery controls, including "pause all rollouts" and "let assigned downloads finish".

Guardrails: the high-risk approval gate#

An app can require a human to approve high-risk releases before they promote. When enabled, a promote is blocked with requires_approval if it is:

• unsigned (bundle_unsigned), or

• a wide initial rollout — greater than 25% (wide_initial_rollout).

Automatic crash-rollback (the boot guard)#

The strongest safety net needs no configuration. When a new bundle is applied, the SDK's boot guard watches it become healthy on startup. If the new bundle crashes before it's confirmed healthy, the SDK automatically reverts to the last good bundle on the next launch — a broken release cannot brick the app.

W ScaleBunOta: Bundle failed to become healthy in 2 launch(es) — auto-revertingI ScaleBunOta: Reverted to previous bundle… downloads the next (fixed) bundle …I ScaleBunOta: Boot marker cleared — bundle marked healthy

A device that self-reverts reports back, so a bad release shows up as ROLLED_BACK in SyncResult and in the fleet's recovery view — you see it happening rather than guessing.

Next#

• Signing — required to clear the bundle_unsigned guardrail cleanly.

• Publishing — the publish + rollout flags in full.