The RevoPush alternative at half the price
RevoPush and Pulsar solve the same problem the same way: both speak the CodePush protocol, so both work with the client your app already ships. The difference is where the service runs and how it is priced.
What RevoPush is, and where it fits
RevoPush picked up CodePush after Microsoft dropped it, and it deserves credit for that — it kept the React Native client maintained through the New Architecture transition, which is not glamorous work. Pulsar’s own client is a fork of @revopush/react-native-code-push, and we say so in the package README.
Where the two diverge is operations. RevoPush is a managed SaaS metered by monthly active user — free to 1,000 MAU with 10 GB of egress, then $25/mo for 50K, $100/mo for 300K, and up from there, with self-hosting reserved for the Enterprise tier. Your update bundles and every device check-in flow through their infrastructure.
Because both speak the same on-device protocol, choosing between them is a backend decision: price, hosting, control and the release tooling around the client. Nothing in your app code changes either way.
Pulsar prices the same way, by monthly active user, at roughly half the rate: free to 1,000 MAU, $11.99/mo for 100K, $49.99/mo for 300K, $124.99/mo for 500K and $249.99/mo for 1M, with overage at $0.50 per extra 1,000 users and $0.015 per GB. The Pro plan also includes self-hosting: run it on your own servers and the bundles, the device ids and the adoption telemetry stay inside your perimeter.
When RevoPush is the better choice: RevoPush is a solid choice if you value its track record and are happy with its pricing at your scale. Both are managed services you never have to run yourself; the differences are price, per-release adoption metrics, and self-hosting on a lower tier.
Pulsar vs RevoPush
| Capability | Pulsar | RevoPush |
|---|---|---|
| CodePush protocol | Yes | Yes |
| Client lineage | Fork of the RevoPush client (MIT, credited) | Maintained CodePush fork |
| New Architecture support | Yes | Yes |
| Self-hosting | Yes, on the Pro plan | Enterprise tier only |
| Pricing model | Per MAU: free to 1K, $11.99/mo for 100K, $49.99/mo for 300K | Per MAU: free to 1K, $25/mo for 50K, $100/mo for 300K |
| Overage | $0.50 per 1,000 users, $0.015 per GB | $1 per 1,000 users, $0.03 per GB |
| Where bundles live | Pulsar cloud, or your infrastructure on Pro | RevoPush infrastructure |
| Staged rollouts | Yes, by deterministic % | Yes |
| Instant rollback | Yes | Yes |
| Differential updates | Yes, on Startup and above | Yes |
| Target specific devices | Yes — pin a release to explicit device ids | Rollout percentage |
| Open-source client + CLI | Yes (MIT) | Client open source |
Migrating from RevoPush
Both services speak the same protocol, so a migration is a package swap and a server URL — and because the package hash algorithm is identical, devices already running your current bundle correctly report as up to date instead of re-downloading it.
1. Swap the package
The JS API, the native modules and the hash algorithm are unchanged.
-import codePush from '@revopush/react-native-code-push';
+import codePush from '@novacraft-engineering/pulsar-code-push';2. Point at Pulsar
Set the deployment key from your Pulsar dashboard and the server URL — or your own host, if you are self-hosting.
<key>CodePushDeploymentKey</key>
<string>YOUR_DEPLOYMENT_KEY</string>
<key>CodePushServerURL</key>
<string>https://api.usepulsar.dev</string>3. Release from the CLI
The same release, promote, rollback and patch verbs you already use.
npx @novacraft-engineering/pulsar-cli release MyApp Production --platform android --target 1.4.0 --rollout 25Frequently asked questions
What should I insist on from any OTA service?
Staged rollouts to a deterministic percentage of devices, so a bad bundle never reaches everyone at once. Rollback in one command. Binary-version targeting, so an update only reaches native versions it is compatible with. And real adoption metrics, because served is not applied: a device can download an update and never run it.
Why do adoption metrics matter so much?
Silent non-adoption is the failure most OTA setups cannot see. If a service only counts what it served, a rollout can look finished while most users still run the old code. Pulsar reconciles what each device reports running against what was served, per release, so a stuck rollout shows up instead of hiding.
Is Pulsar’s client just RevoPush’s client renamed?
It is a fork of it, and the README says so. RevoPush maintained CodePush through the New Architecture transition; building a third native client from scratch would help nobody. The Pulsar-specific work is on the server, the CLI and the dashboard.
Do I need to ship a new binary to switch?
Yes — the server URL is compiled into the app, so a switch reaches devices with your next store release. Until then, devices on the old binary keep talking to RevoPush, which makes the changeover gradual rather than a cutover.
Is self-hosting Pulsar free?
No. Self-hosting is part of the Pro plan: you get a license key the server needs to start. The hosted service, including the free plan, is the way to use Pulsar without running anything.
Will my devices re-download the bundle they already have?
No. Pulsar computes the same path:sha256 CodePush package hash, so a device already running that bundle reports as up to date.
Compared with the others
- Pulsar vs Microsoft CodePush — the protocol both of them speak.
- Pulsar vs Expo EAS Update
- Pulsar vs Microsoft App Center
- Pulsar vs Stallion
- Pulsar vs hot-updater
Ship the fix without the queue.
Point your React Native app at Pulsar and release in seconds.
Get started →