Staged rollouts that pause themselves
Start small, widen on a schedule you set, and stop the moment failures rise, with one command back.
From the team behind Capawesome, trusted by 1,000+ teams
Small first, wider on its own
Set the steps once. The release widens while the devices stay healthy and holds the moment they do not.
A staged rollout in HotCodePush sends an over-the-air (OTA) update to a share of devices first, then widens on its own. Without one, an update reaches every device at once, and the first sign of trouble is the support inbox. A device is placed once and never flips. The release widens on your schedule once each step has had enough time and enough devices. The same watcher pauses it the moment failures rise and tells you; one command rolls back.
A console card titled Rollout: a step chart rising in three plateaus from a small share of devices to a wide one, a dashed marker where a pause holds the line, and a log beneath reading widened, widened, paused as failures rose.
Pauses itself, then tells you
The watcher that widens a release also stops it. The moment failures rise, the rollout holds and your team hears why.
Holds the moment failures rise
Counters and top reasons in the notice
Email, webhook event and audit log
A notification card for a paused release with its applied and failed counts and the top failure reasons, noting the webhook event and the audit log entry.
One command back, before anyone notices
A rollback is a new release of an earlier bundle, so it rolls out like any other and the log keeps every step.
One command, or one click on the release page
Devices return to the earlier release at their next start
An update that fails to start rolls back itself
A release list card with the current release marked rolled back and the earlier release live again, and beneath it the one command line that did it.
Every device placed once
A device keeps its place in a rollout, so it never flips between releases. Widening adds devices and never removes one.
A stable place per device and release
The same answer on every check
Widening never removes a device
A strip of rollout buckets from 0 to 99 with one device pinned to its bucket and the reached range widening from 10 to 50 percent around it.
A staged release in three commands
Create at ten percent, watch it widen on its own, and roll back with one command when you have to.
zsh — my-app
What holds during every rollout
The rules a release follows from the first device to the last.
- for every change to apply
- ~1 min
- once a device has it
- Kept
- to roll back on device
- Seconds
- includes auto-pause
- Every plan
Figures as of November 1, 2026.
How the field does it
How the field widens a release, what stops a bad one and how it goes back, from the vendors' own pages.
| Feature | HotCodePush | Capgo |
|---|---|---|
| Staged rollouts | A share of devices that widens on a schedule you set | A percentage raised by hand, step by step |
| A failing release | On for every channel from creation; the release pauses itself | A failure threshold per release; auto-pause off by default |
| Which devices are in | Placed once, for good; narrowing takes back only the last devices added | Sticky while the cache lasts; narrowing returns a random subset |
Last verified 2026-10-26.
| Feature | HotCodePush | Capawesome Cloud |
|---|---|---|
| Staged rollouts | A share of devices that widens on a schedule you set | A percentage, raised or lowered by hand |
| A failing release | Pauses itself; the console and a mail tell you | Not in the Capawesome Cloud documentation as of 2026-10-26 |
| A bad update on a device | Rolls back to the last good bundle when the update fails to start, on by default | Opt-in readiness check; a miss reverts to the built-in bundle |
Last verified 2026-10-26.
| Feature | HotCodePush | EAS Update |
|---|---|---|
| Staged rollouts | A share of devices that widens on a schedule you set | A percentage per update, raised and finished by hand |
| A failing release | Pauses itself; the console and a mail tell you | Not in Expo's rollout guide as of 2026-10-28 |
| A bad update on a device | Rolls back to the last good bundle when the update fails to start, on by default | Error recovery within 10 seconds of first render, documented as not to be relied upon |
Last verified 2026-10-28.
Three more things every release gets
Each feature has its own page: the mechanism, the specifics, the field compared and the questions teams ask.
Analytics
Adoption per release, every failed and skipped update with its reason, and monthly active devices that match the invoice, read in the console, the CLI or the API.
See the featureAttribute targeting
Labels your app sets choose which devices a release reaches, every condition is checked on the device, and the audience preview counts the reach before you publish.
See the featureSafety
Code signing with a key only you hold, verification on the device before anything is applied, and delivery with no server of ours on the path.
See the feature
Rollout questions
Your next bad update reaches a few devices, not all of them.
Free for 1,000 MAU. No credit card.
Questions? Join our Discord or contact us.