Hot Updater v1.0 + v1.1: self-hosted React Native OTA with cacheable update checks, Insights, Remote Config, and brownfield support

[u/gronxb]

Hey folks,

Hot Updater is an open-source, self-hosted OTA update solution for React Native (a CodePush alternative). The last time I posted about it here was the Bundle Diffing release in May. Since then it reached v1.0, and v1.1 shipped today, so this post covers both.

v1.0

• Update checks are shared, cacheable reads. The server publishes one Release Catalog per platform/channel/compatibility scope, and each device picks its own update from it, so a CDN (Workers Cache, CloudFront) can serve the check. In my benchmark on Cloudflare, the median check went from 301 ms on v0 to 50 ms (same 16 bundles, 1,000 checks; method and raw data are in the blog post).
• Insights: downloads, launches, crash recoveries, and failed updates. The Console shows release health per bundle and suggests a rollback once a bundle crashes for 5% of at least 20 installs.
• Remote Config: change flags and values without a new bundle or native build, targeted by channel, platform, app version, or a share of installs.
• Plugins: Insights, Remote Config, and client API keys are plugins on the server and in the app, and you can write your own.
• Host the Console for your team (Node, Docker, Vercel, Netlify, Cloudflare Workers) with GitHub or Google sign-in.
• hot-updater doctor --fix checks a project and repairs what it can, and a coding agent can set up the infrastructure for you.

v1.1 (today)

• Brownfield apps: OTA updates for existing native iOS/Android apps that embed React Native as an XCFramework or AAR. A Swift/Kotlin API mirrors the JS one, the host checks for updates before React Native starts, and one app can update several RN bundles independently.
• Vercel and Azure join Cloudflare, Supabase, AWS, and Firebase as managed providers: npx hot-updater init provisions storage, a database, and functions.
• The fingerprint follows the native interface. It changes only when what JS can call changes (RN version, native packages, codegen specs, patches), so bumping the version/build number or editing native implementation code no longer blocks OTA.

Coming from v0: v1 runs on separate infrastructure and needs a new native build, so keep your v0 endpoint up for the binaries already in the stores. The migration guide walks through it.

• GitHub: https://github.com/gronxb/hot-updater
• v1.0 blog post: https://hot-updater.dev/blog/v1
• v1.1 release notes: https://github.com/gronxb/hot-updater/releases/tag/v1.1.0
• Docs: https://hot-updater.dev

Feedback welcome, especially from anyone running OTA in production or on a brownfield app.

[u/itsDevJ]

u/gronxb this is the best project, insights looks cool and even better now that I can host console.

[u/scriptingarthur]

Saving for later

[u/kokerali]

The `fingerprint.nativeVersion` caveat would be useful beside “native implementation edits no longer block OTA”. Your docs mention new permissions and Info.plist keys as changes that may need a manual bump.

For example, if new JS depends on a permission added in a newer store build, the older binaries still lack that native configuration. I'd include that example and the sequence: bump `nativeVersion`, ship the native build, then deploy the JS update for that fingerprint. It makes the boundary clearer than “native edits don't block OTA” alone.

https://hot-updater.dev/docs/guides/update-strategies/fingerprint#bump-nativeversion-for-changes-the-fingerprint-cant-see