CodePush alternatives in 2026, compared honestly
EAS Update, Stallion, RevoPush, Hot Updater, self-hosting, BetterCodePush — every option for React Native OTA updates after CodePush, including the cases where we'd tell you to pick someone else.
Every vendor in this space has a "best CodePush alternatives" post, and every one of them concludes — surprise — that the vendor writing it is the best alternative. We are obviously not neutral either. So instead of a ranking, here is the actual decision tree we walk people through, including the branches where the honest answer is "don't use us."
First, the situation
Microsoft retired App Center on March 31, 2025, and archived the react-native-code-push repository that May. The hosted service is gone and the SDK is frozen — which matters more than it sounds, because CodePush's update path doesn't work under the New Architecture, and there is nobody left to fix it. Whatever you pick next needs to be something with a future, not just a working endpoint.
If you're on managed Expo: use EAS Update
Genuinely. If your whole workflow already runs through Expo — managed config, EAS Build, no ejected native projects — then expo-updates is deeply integrated, well documented, and maintained by the company that maintains the rest of your toolchain. In SDK 55, Hermes bytecode diffing is opt-inand can make updates smaller; it is not automatic for every SDK 55 app. The main things to go in with your eyes open about are the MAU-and-bandwidth pricing as you scale (we did the math in what OTA updates actually cost) and the channels/branches/runtime-versions model, which takes a bit of learning. But the fit is right. Adopting a third-party OTA layer while staying fully managed mostly buys you friction. If your prebuild app has a concrete reason to change runtimes, use the staged EAS Update migration guide.
If you want a drop-in that speaks the old CodePush protocol
RevoPush positions itself as API-compatible with the original CodePush SDK — keep the client, point it at a new endpoint. That is the lowest-effort migration on the market, and if your app is on an older React Native version where the frozen SDK still works, it is a pragmatic bridge. The caveat is structural: you are still running an archived, unmaintained client library, so you have deferred the New Architecture problem, not solved it. Fine as a stopgap; risky as a destination. Teams already using RevoPush can follow the RevoPush migration guide without stranding binaries that still use the old service.
If you want to self-host
Two real options. Microsoft open-sourced a standalone code-push-server before shutting down — community-maintained, no support, same aging client. Hot Updater is the more modern open-source route: self-hosted on your own storage and edge infrastructure, actively developed. Self-hosting is the right call for strict data-residency or air-gapped-enterprise situations. For everyone else it is usually more expensive than it looks, because you are signing up to operate release infrastructure with on-call characteristics — the full accounting is in our self-hosting cost breakdown. If Hot Updater is your current runtime, the hosted-service migration guideexplains what maps cleanly and when self-hosting is still the better fit.
If you're bare React Native or Expo prebuild
This is the segment we built for, so discount accordingly — but it is also the segment the market serves worst. Managed-Expo tooling assumes you never left the managed workflow; most CodePush-successor SaaS products were built against the legacy bridge era. What we think this segment actually needs:
- An update path built for Bridgeless/New Architecture, not retrofitted onto the old bridge.
- Bundle signing, because an unsigned OTA channel is an attack surface.
- Staged rollouts with a real server-side kill switch.
- No requirement to adopt a whole platform to get an update channel.
Stallion also plays here and is a credible product — they've pushed hard on patch-size reduction and enterprise self-hosting. Where we differ is mostly philosophy: BetterCodePush stays deliberately narrow (bare RN and prebuild, one native build, then OTA) rather than expanding into a general mobile-DevOps suite. Try both against your actual app; the integration takes an afternoon either way. If you decide to move, the Stallion migration guide covers signing, rollout mapping, and the two-population cutover.
The questions that actually decide it
- Does it work on React Native 0.76+ under Bridgeless? Test this, don't take the marketing page's word. A silent no-op looks exactly like success.
- What's the pricing unit? MAU, bandwidth, updates published — each model bites a different kind of app. Model your own numbers.
- Is OTA the vendor's core business? CodePush died as a side feature of a deprioritized product. That lesson generalizes.
- Is there an exit? Standard bundle formats and a documented removal path mean you can leave. Vendors confident in their product don't lock the doors.
However you land: ship the migration behind a staged rollout, keep the old system running until the new one has delivered a few clean updates, and only then rip it out. The migration guide covers that sequencing in detail.