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.

Compared

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 No Yes, AGPL-3.0

Last verified 2026-10-21.

Based on Capgo's public documentation and GitHub repository; names are trademarks of their owners.

Architecture

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.

How an update reaches a device

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.

Full migration guide

Switching from Capgo

Yes, in both directions. A device keeps the release its bucket gave it, a rollout can be widened or narrowed, and auto-pause halts a release on its own when failures cross the bound. Staged rollouts
No. HotCodePush signs every bundle with your key and verifies it on the device; the bundle itself is not encrypted at launch. Capgo offers end-to-end encryption, and its documentation describes it. Signing and verification
Yes. The switch ships inside a store release; binaries before it keep taking their old updates until their users move. A preview channel lets you test the new path on your own devices first. Preview channels
Nothing native. HotCodePush updates the JavaScript, markup, styles and assets your app already ships; the native layer, the plugins and the store listing stay as they are, and the fingerprint keeps an update off a binary it was not built for. Compatibility
Yes. Every framework gets deltas, built by our delta service when you release, so a device downloads only the files it lacks. React Native and Expo also get a small patch of the main JavaScript bundle inside the pack. How an update reaches a device
Your data is yours. The API lists everything, so a full export is a script, and the usage and audit log pages download CSV. The SDKs are MIT-licensed and the update format stays backward compatible, so an app on an old SDK keeps updating. API reference

A package swap, not a rewrite.

Swap the package in your next store release.