# Rollback — Bundle Drop Docs

> Stop offering a bad OTA release. Compatible replacements follow your app’s update policy; learn how dashboard rollback differs from startup recovery.

Canonical: https://bundledrop.app/docs/rollback

## What Rollback Is

Dashboard rollback stops a problematic OTA bundle from being offered on a channel. Devices discover the change on their next update check and can receive another eligible bundle compatible with their native runtime.

You do not need to build and publish a special reverse update. The replacement is selected from the channel's eligible releases; it is not necessarily the immediately preceding version.

This read-only walkthrough rolls back a sample release in `production`, then shows three apps following their configured update policies. The example has a compatible v41 replacement available; its timing is illustrative.

## Where to Do It in the Dashboard

1. Open your project.
2. Open the channel you want to manage.
3. Go to that channel's **Bundles** page.
4. Choose the bundle you want to roll back and confirm the action.

Rollback is channel-scoped. Rolling back a bundle on one channel does not revoke it on every other channel in the project.

## How Rollback Works

After a device checks for updates, an eligible compatible replacement follows your app's selected [update policy](/docs/update-policies):

| Policy | When the replacement becomes active |
| --- | --- |
| `manual` | Your app controls the download and calls `applyUpdate()` when it is ready. |
| `on-next-launch` | Bundle Drop downloads and stages the replacement for the next app launch. |
| `immediate` | Bundle Drop downloads and applies the replacement as soon as possible. |

A dashboard action does not push an immediate restart to every device. A device that is offline or has not checked yet may still be running the rolled-back release.

If the current bundle is revoked and no safe compatible OTA replacement is available, Bundle Drop can recover to the embedded bundle that shipped with the app. This safety recovery is separate from normal replacement updates and can occur even with `manual` or a check-only startup flow. Update policy does not disable native integrity or compatibility protection.

## When Teams Use It

- Stop distributing a release with crashes or broken behavior.
- Move affected devices toward an eligible stable release.
- Contain an issue while preparing a fix-forward update.

Use your monitoring tools to check the impact, and test the replacement against the affected native runtime. Rollback cannot add native capabilities that were absent from the installed app binary.

## Automatic Crash Protection

Bundle Drop also protects startup on the device. If an OTA bundle repeatedly fails to become healthy, native recovery restores a verified, previously healthy compatible OTA bundle, or the embedded bundle when no eligible previous OTA is available. This happens on a later cold launch and works offline.

This is separate from dashboard rollback and does not wait for your normal update policy. See [Automatic Recovery](/docs/automatic-recovery) for defaults, limits, and health configuration.

## Manual Health Reporting

Manual health reporting lets your app mark startup healthy with `BundleDrop.reportHealthy()`. It is independent of the `manual` update policy. See the [manual health reporting example](/docs/automatic-recovery#manual-health-reporting).

## Related Docs

- For on-device startup protection, see [Automatic Recovery](/docs/automatic-recovery).
- For activation timing, see [Update Policies](/docs/update-policies).
- For release tracks, see [Channels](/docs/channels).
- For gradual release control, see [Staged Rollouts](/docs/staged-rollouts).
- For publishing a fix, see [Uploading](/docs/uploading).