Hosted vs self-hosted OTA updates for React Native#

An OTA update system can be run as a service you pay for or as infrastructure you operate. Both are legitimate choices, and the right one depends less on preference than on what an update pipeline actually has to do. This page lays out that scope first, then the trade-offs in each direction, so the decision is about your team rather than about slogans.

What an OTA pipeline has to do#

Whoever runs it, a production OTA system has the same parts:

• An update-check endpoint. Every installed app asks it, on launch or on resume, whether a newer bundle exists for its channel and native build. It sits in the startup path of your entire install base, so its availability and latency matter more than any dashboard's.
• Bundle storage and delivery. Built bundles have to live somewhere durable and be served quickly to devices worldwide, usually through a CDN.
• Compatibility gating. A JavaScript bundle built against one native surface must never be handed to a binary with a different one. The pipeline needs a fingerprint or version scheme baked into the binary at build time and enforced at check time.
• Signing and verification. Updates replace running application code, which makes the pipeline a supply-chain target. Bundles need to be signed at release and verified on the device, and the private key needs somewhere safer than a laptop or a CI log.
• Channels and staged rollout. Preview builds and production builds must not receive each other's updates, and a new release should be able to reach a fraction of devices before all of them.
• Rollback. When a bad bundle ships, reverting the channel has to be immediate and has to work under pressure — it is the feature you need exactly when everything else is on fire.
• Monitoring. You need to know how far a rollout has spread and whether the new bundle is crashing before you raise the percentage.

When self-hosting makes sense#

Self-hosting is a real option, and open-source React Native OTA stacks exist to build on. It fits when at least one of these is true:

• Data residency or compliance requires it. If update traffic and bundles must stay inside your infrastructure, that decides the question by itself.
• You already operate a platform. A team that runs its own CDN, secret management, and on-call rotation is adding one more service, not standing up its first.
• Your scale makes the economics work. With a very large install base, serving bundles from infrastructure you already pay for can cost less than any per-something price — once the engineering time to build and operate the pipeline is genuinely accounted for.

The recurring mistake is comparing a hosted service's price to a storage bill. The storage is the cheap part; the update-check endpoint's uptime, key management, rollout logic, rollback under pressure, and the on-call burden of a service in every app launch are where the real cost lives.

When a hosted service makes sense#

A hosted service fits when shipping the app is your team's job and the update pipeline is not:

• Nobody has to be on call for the update-check endpoint.
• Signing, key custody, compatibility gating, channels, staged rollout, and rollback exist on day one instead of accreting over months.
• The cost is a known subscription line instead of unbudgeted engineering time.

The honest downsides run the other way: update metadata flows through a third party, you depend on that party's uptime, and at extreme scale a subscription can cost more than infrastructure you already own.

How Rollbird fits#

Rollbird is the hosted side of this trade-off: a hosted OTA update service for bare React Native and Expo apps, with staged releases, free rollback, and no per-user pricing. rollbird init embeds the channel, public signing key, and native-build fingerprint into your binary; rollbird release bundles, signs, and publishes; the update check gates on fingerprint compatibility; and rollbird rollback reverts a channel instantly, at no cost, regardless of plan status or quota.

Plans scale on apps, storage, seats, and release history — never on end users or monthly active users, so a successful launch doesn't change the bill. See pricing for the current plans, and the getting-started guide to try the pipeline end to end.