Migrate from Hot Updater

A Hot Updater app moves to HotCodePush at its next store release and stops running its bucket, database and function for a hosted bill. Channels keep their names, the fingerprint replaces both update strategies and release create replaces deploy.

This page uses Hot Updater v1's names, where HotUpdater.init() returns the hotUpdater instance. A v0 app has the static HotUpdater.wrap and HotUpdater.checkForUpdate instead, and an older one runUpdateProcess and setChannel.

What you give up and gainCopy Anchor Link

You gain a hosted console with roles and protected channels, auto-pause on every release and progression with --progression, and built-in statistics. The bill replaces a licence with no fee: Free up to 1,000 monthly active devices, then Pay-as-you-go (Billing and MAU).

No counterpart here: your own data location, Remote Config, KMS signing, sub-percent rollout steps and cohorts edited after a release.

AI-assisted migration (recommended)Copy Anchor Link

Install the HotCodePush skills:

npx skills add hotcodepush-team/skills

Then paste the prompt into your coding agent:

Migrate this app from Hot Updater to HotCodePush: install the skills with `npx skills add hotcodepush-team/skills`, then run the hotcodepush-migrate skill, following https://hotcodepush.com/docs/migrate/hot-updater.

The agent removes Hot Updater, runs init, maps channels, the signing key and the binary ranges, and reports a checklist for the store release. It never touches your bucket, database or function, and the first release waits for the store build. Agent skills explains what the agent does.

PrerequisitesCopy Anchor Link

• You have a HotCodePush account and an organization. npx hotcodepush init creates both, as the quickstart shows.
• The app is a React Native app on the New Architecture, or an Expo app that runs in a development build. The minimum versions are on Supported versions. Hot Updater ran on older versions, so upgrade first.
• You have the private key under keys/, if the app signed with a local key. A key in a KMS cannot be exported, and init generates a new one.
• A store release lies ahead, and Node.js is on every build machine, since the build step runs the CLI from an Xcode phase and a Gradle task.

StepsCopy Anchor Link

If you already removed Hot Updater and ran init, skip to step 4.

1. Freeze a branch for the old buildsCopy Anchor Link

git branch hot-updater-fleet

A bundle built from the migrated code imports a native module the old binaries lack. Hotfixes for them come from a branch that keeps the old client, hot-updater.config.ts and the deploy job. .env.hotupdater is untracked, so move its values into that pipeline's secrets first.

2. Remove Hot UpdaterCopy Anchor Link

npm uninstall hot-updater @hot-updater/react-native

Uninstall every other @hot-updater/* package too. Delete hot-updater.config.ts, fingerprint.json and .env.hotupdater, remove the call to HotUpdater.init() in src/hotUpdater.ts, and replace every call per the SDK calls below. Then clean the native projects:

• HotUpdater.bundleURL() in the Swift bundleURL(), and import com.hotupdater.HotUpdater with the jsBundleFilePath or getJSBundleFile() override in MainApplication.kt: put both files back to the template, which init recognises (Installation).
• the HOT_UPDATER_* keys in Info.plist and build variables, the com.hotupdater.* meta-data in the manifest and a v0 app's strings.xml entries, then pod install.
• in an Expo app, the plugin and @hot-updater/expo/babel-plugin in the app config and the EXPO_PUBLIC_HOT_UPDATER_* variables. The prebuild refuses expo-updates unless updates.enabled is false.

3. Run initCopy Anchor Link

npx hotcodepush init

init signs you in, creates the app with its production channel, installs the package and wires the build step. An Expo app gets @hotcodepush/expo-ota-updates and its config plugin (Expo installation). Answer no to the signing key if you bring yours, and decline the first release.

4. Add the signing keyCopy Anchor Link

npx hotcodepush signing-key add --private-key-path keys/private-key.pem

signing-key add takes an RSA key of at least 2,048 bits and fills publicKeys in hotcodepush.json, which replaces HOT_UPDATER_PUBLIC_KEY. Skip the step if the app did not sign, or if init generated a key. The private key stays where it is, and CI holds its content as HOTCODEPUSH_SIGNING_KEY.

5. Create the channelsCopy Anchor Link

npx hotcodepush channel create --name staging --discoverable

production exists, and every other channel is created once, with --discoverable where the app switches to it by name. The channel set command becomes channel in hotcodepush.json, or HOTCODEPUSH_CHANNEL in a flavour's build environment (Set up environments and tenants).

6. Ship the store release that carries the SDKCopy Anchor Link

Build the release as before. The build step registers the build as a binary with its fingerprint. The machine needs npx hotcodepush login or HOTCODEPUSH_TOKEN. Under CI a store build without a token fails, and npx hotcodepush binary list shows the registered builds.

7. Release from your pipelineCopy Anchor Link

npx hotcodepush release create --bundle-version "$(git rev-parse --short HEAD)" --yes

This line replaces both deploy -p jobs. In CI, HOTCODEPUSH_TOKEN replaces .env.hotupdater, and HOTCODEPUSH_SIGNING_KEY the PEM secret (Ship every commit).

On a device running the new build the release applies within about a minute (How an update reaches a device). If nothing happens, see Troubleshooting.

8. Run both until the old builds are goneCopy Anchor Link

The old builds keep calling your Hot Updater server, so keep the function, the storage, the database and the client API key live. Nothing is imported from their history. The shift shows in binary list and in Insights.

Afterwards: the bucket and the databaseCopy Anchor Link

Once the old builds are below the share you will leave behind:

1. Stop the deploy job on the frozen branch and leave every bundle enabled.
2. Delete the function, the self-hosted console, the CI secrets and the API keys.
3. Export Insights if you want the history, then delete the bucket and the database last.

Before the server goes, check on an old build what it runs once nothing answers.

What maps to whatCopy Anchor Link

CLI commandsCopy Anchor Link

The CLI reference lists every command, and Compatibility has the range syntax.

SDK callsCopy Anchor Link

The React Native SDK's API page has every method, event and type.

Before and afterCopy Anchor Link

The wrap call goes: checkStrategy: auto checks at start, on resume and every 900 seconds, where wrap checked once at mount. A force update maps onto a mandatory release, which reloads at once by default:

{
  "appId": "<your app id>",
  "channel": "production",
  "mandatoryApplyStrategy": "manual"
}

With manual the app keeps the moment, as reloadOnForceUpdate: false did: updateDownloaded carries release.isMandatory, and applyUpdate() reloads (Choose an apply strategy). A launch-only check is checkStrategy: manual with one sync() at start.

What differsCopy Anchor Link

The two fingerprints also hash different things: HotCodePush reads the native packages in the lockfile. The Hermes and New Architecture flags, patches/ and local codegen specs count only under extraFingerprintPaths (Compatibility).

Next stepsCopy Anchor Link

• Choose an apply strategy decides when a downloaded update takes effect, and who restarts the app after a mandatory release.
• Roll out gradually: start small, let the release progress and let auto-pause stop a bad one.
• React Native SDK reference documents every hotcodepush.json key, method, event and type of the SDK you installed.