HotCodePush and Capgo, compared honestly
Both ship a Capacitor app's web layer without store review. HotCodePush, the over-the-air (OTA) update service for React Native, Expo, Capacitor and Cordova, puts no backend on the check path.
Where HotCodePush and Capgo differ
Verified on 2026-10-21; Capgo facts from the Capgo documentation, its FAQ and the Cap-go GitHub repository.
| Feature | HotCodePush | Capgo |
|---|---|---|
| At the usage limit | Devices counted this month keep receiving updates; devices beyond the cap keep what they have. Uploads and releases keep working | Updates are blocked for every device until the billing cycle ends; the app keeps running |
| Frameworks | React Native, Expo, Capacitor, Cordova | Capacitor on Android, iOS and Electron |
| Rollouts that pause themselves | Widen or narrow; progression on a schedule; auto-pause on | Widen or narrow by hand; auto-pause off by default |
| Fingerprint compatibility | A hash of the native contract, by default | A semver or minimum-version rule per channel |
| Preview channel per pull request | An expiring channel per pull request, with a QR code | A temporary channel per pull request from CI |
| Audience preview | A dry run counts the devices a release would reach | Not in the Capgo documentation as of 2026-10-26 |
| Self-hosted backend | Yes, AGPL-3.0 |
Last verified 2026-10-21.
Based on Capgo's public documentation and GitHub repository; names are trademarks of their owners.
No backend on the check path
Capgo's backend answers every update check. A HotCodePush device reads a static index from the CDN and decides for itself.
Every Capgo update check is a request its backend answers; Capgo's FAQ says the app keeps running as normal while the server is unreachable, so nothing new arrives until it is back. A HotCodePush device reads one static index per app, channel and platform from the CDN, checks each release against its binary's fingerprint and its rollout bucket, and downloads the pack it needs. While our control plane is down, your users keep receiving the updates you already published.
Diagram: the Capgo backend answering an update check beside a HotCodePush device reading the static index from the CDN.
Switch in four steps
1 · Install the SDK
Add the HotCodePush SDK for your framework, React Native, Expo, Capacitor or Cordova, and remove the previous update client. The SDK is MIT-licensed and replaces the update layer alone; your native code, your plugins and your store listing stay as they are.
2 · Create your channels
Create one channel per audience you ship to today, production first, then staging or beta. A preview channel lets you test the new path on your own devices before anyone else; whoever holds its link follows it, and nobody else reaches it.
3 · Ship one store release
Ship one store release with the new SDK inside. The binaries before it keep taking their old updates until their users move, so nothing breaks in the field, and devices on the new binary use HotCodePush from their first start.
4 · Run the release step
In your pipeline, replace the old release command with hotcodepush release create. It packages the bundle, signs it, works out what changed and releases to the channel you name, so every merge to main reaches devices without a store review.
Switching from Capgo
A package swap, not a rewrite.
Swap the package in your next store release.
Questions? Join our Discord or contact us.