Managed vs Self-Hosted React Native OTA: Compare the Ownership Boundary

“Managed or self-hosted?” sounds like an infrastructure question.

For React Native OTA updates, it is really an ownership question.

Both approaches can deliver compatible JavaScript and bundled assets to installed applications.

Both can support channels.

Both can support rollouts.

Both can support rollback.

Both can use object storage and CDNs.

The important difference is not where the JavaScript file physically lives.

It is:

Who is responsible when the release path stops behaving correctly?

A managed service puts much of the OTA platform operation behind a provider boundary.

A self-hosted system moves that responsibility into your organization.

The safety requirements do not disappear.

The ownership boundary moves. (Bundle Drop)

The mobile team still owns compatibility either way

One responsibility cannot really be outsourced:

deciding whether a release is compatible with the native binary already installed on the device.

React Native OTA can replace JavaScript and bundled assets.

It cannot add a native module, permission, entitlement, engine, or compiled capability to an application that users already installed.

So whether the OTA infrastructure is managed or self-hosted, somebody on the application side still needs to decide:

Can this binary safely execute this update?

Bundle Drop expresses this with runtime gating, but the principle is provider-independent.

The current SDK only delivers updates that match the installed app’s native/runtime identity, and native changes still require another App Store or Play Store build. (npm)

Self-hosting gives you more control over how that compatibility rule is implemented.

It does not remove the need to define the rule correctly.

Compare responsibilities, not labels

“Self-hosted” covers a wide range of systems.

One company may run an existing open-source OTA server on infrastructure it already knows well.

Another may build a custom control plane around S3, a database, CDN infrastructure, signing keys, and an internal deployment platform.

Likewise, “managed” can mean different service boundaries depending on the provider.

The more useful comparison is the responsibility map.

This is not a scorecard.

A small mobile team can benefit enormously from standardized managed behavior.

A regulated organization with an established platform team may legitimately need infrastructure inside a particular region, network boundary, or internal identity system.

The question is which responsibility boundary fits the organization you actually have. (Bundle Drop)

Mobile clients make self-hosting different from running a normal web API

There is a complication with OTA infrastructure that is easy to underestimate.

Your clients cannot all be upgraded when the server changes.

A backend team can often deploy a coordinated frontend/backend change within a controlled window.

A mobile fleet is different.

Users keep old store binaries.

Some update immediately.

Some wait weeks.

Some managed devices wait much longer.

That means a self-hosted OTA server may need to preserve protocol behavior for several generations of installed clients at the same time.

A server migration therefore needs questions such as:

Which old binaries still exist?

Which manifest or download contracts do they understand?

How long must those contracts stay available?

What happens if the database schema changes?

Can a new server version still support rollback for an older client?

The canonical Bundle Drop comparison explicitly calls this out: in a self-hosted model, the team may be responsible for coordinating client and server protocol compatibility while old store binaries remain active. (Bundle Drop)

This is one of the biggest differences between:

“I can run this server.”

and:

“We can operate this release system for the next three years.”

Object storage is not an OTA platform

The easiest part of an OTA system is often putting an artifact somewhere downloadable.

A bucket plus CDN can solve storage and transfer.

That is not the complete release path.

A production OTA system also needs deterministic release selection, compatibility enforcement, artifact integrity, lifecycle management, rollback behavior, retries, safe activation, telemetry, access control, and incident recovery. (Bundle Drop)

Consider what happens when:

the database is healthy but object storage is degraded;

the artifact exists but the signing credential expired;

a device downloads only part of a bundle;

the control plane chooses the wrong runtime line;

a CDN still serves a release that was revoked;

or the service restores metadata from backup without restoring the matching artifacts.

Those failures are not theoretical implementation details.

They are part of the service you are choosing to own.

A self-hosted design gives you direct control over how they are handled.

It also makes your team responsible for testing them.

Release controls need an operator behind them

Channels, staged rollout, targeting, and rollback look like product features.

Operationally, each one is a state machine.

Take staged rollout.

A percentage value by itself is not enough.

The system needs deterministic eligibility.

It needs to know what happens when a device falls outside the newest release’s percentage.

It needs to handle paused releases, targeting rules, revoked artifacts, and several runtime versions on one channel.

Rollback also has more than one time horizon.

Changing server-side release selection helps devices when they next successfully check for an update.

It does not automatically rescue a device that already installed broken JavaScript and now fails before it can make another successful server request.

That requires local recovery behavior and a known-good fallback.

Bundle Drop’s current public model separates those two concerns: server-side release control and local rollback safety both exist, while the complete embedded/native bundle remains part of the recovery model. (Bundle Drop)

In a managed system, the provider implements and operates the release-selection machinery.

In a self-hosted system, your organization owns the correctness of that machinery.

That is often where the real cost of customization appears.

Patch delivery adds another operational path

Patch-sized downloads are attractive because many OTA releases change only a small fraction of the bundle.

But patches introduce another condition:

the device needs a suitable starting state.

A production fleet will contain installations with different histories.

Some users missed a release.

Some installed a fresh binary.

Some rolled back.

Some were outside an earlier rollout cohort.

So an optimized patch route needs a defined fallback.

Bundle Drop’s current public SDK treats patch transport as an optimization: it reconstructs and verifies the complete target bundle, and if patch transport is unavailable or fails, it can fall back to the signed full ZIP. (npm)

A self-hosted implementation can use any transport design it wants.

But somebody must own the failure semantics.

What if the patch artifact was cleaned up?

What if the source state does not match?

What if reconstruction fails?

What if the patch generator and client support different algorithms?

The bandwidth optimization becomes another production subsystem.

Observability is part of the OTA platform

OTA creates a debugging problem that normal store releases do not have.

Two devices can report the same native application version while running different JavaScript releases.

So:

App version: 4.2.0

is no longer enough to identify the running code.

You need the active OTA release identity as well.

Bundle Drop currently exposes the active bundle identity and observability context specifically so error trackers can associate a crash with the correct source map and JavaScript release. Its docs recommend using the OTA bundle hash to connect runtime reports with the corresponding source map. (Bundle Drop)

A self-hosted platform needs an equivalent model.

You should know:

Which release is running?

Which runtime line does it belong to?

Which channel selected it?

Did the download succeed?

Did verification succeed?

Was the candidate staged but not yet active?

Did a rollback happen?

Without that information, operating your own infrastructure may give you more server visibility while making application incidents harder to understand.

Access control and audit belong in the design too

Once OTA becomes a production release mechanism, publishing is a privileged operation.

So is rollback.

So is revocation.

So is deleting artifacts.

So is changing a rollout from 5% to 100%.

A self-hosted platform therefore needs more than authentication.

It needs a clear authorization model.

Read access and release-changing access should not automatically be equivalent.

Operator actions should be attributable.

Audit history needs retention.

Credentials need rotation.

CI credentials need narrower permissions than human administrators where possible.

These concerns may not matter during the first internal proof of concept.

They matter a lot after OTA becomes part of the normal production-release path. (Bundle Drop)

Open source does not mean zero operating cost

One of the weakest comparisons between managed and self-hosted infrastructure is:

Managed service: $X / month
Self-hosted software: $0

That measures software licensing.

It does not measure operating cost.

Self-hosting may still be the cheaper choice for a team that already has mature infrastructure for:

deployment;

identity;

object storage;

databases;

monitoring;

backups;

on-call;

incident response;

security patching.

For that organization, the marginal cost of another service may be small.

For a mobile team without that platform foundation, the engineering time required to create and maintain the same safety envelope can be much larger than the infrastructure bill.

The inverse is also true.

A managed service should not automatically be assumed to be cheaper.

Provider pricing, supported regions, limits, migration options, and organizational constraints all matter.

The useful comparison is total operating cost over the lifetime of the system, not subscription price versus server price. (Bundle Drop)

Time-to-integrate is not time-to-operate

A proof of concept answers:

Can this app download and launch an update?

Production readiness asks much more.

Can you upgrade the server without breaking old store binaries?

Can you restore both metadata and artifacts?

Can you rotate credentials?

Can you detect a release-selection incident?

Can you recover from object-storage failure?

Can you identify which JavaScript release caused a crash?

Can you roll back while part of the fleet is offline?

Can the embedded bundle still start if the OTA service is unavailable?

A managed service does not remove all of those questions.

It changes who owns large parts of the answer.

The app team still needs native integration, runtime policy, rollout practice, source-map handling, incident procedures, and SDK upgrades.

Self-hosting adds platform operation on top of those responsibilities. (Bundle Drop)

When self-hosting is the stronger fit

Self-hosting starts to make sense when control is an architectural requirement rather than a preference.

For example, an organization may have hard data-locality requirements.

It may need a particular isolated network topology.

It may already have an internal identity and release-control platform that every production service must use.

It may need custom protocol or rollout behavior that available managed services cannot provide.

And—critically—it may already have a named platform team willing to own the service.

That last part matters.

“I want control” is not the same requirement as:

“This team accepts availability, security, backups, upgrades, protocol compatibility, and on-call ownership.”

When managed OTA is the stronger fit

A managed service is often the better fit when the mobile team wants to own release policy without owning another production platform.

The team still decides:

which native changes require a new binary;

which runtime is compatible;

which release should go to production;

which audience should receive it;

when to pause or roll back.

But the team does not also need to operate the underlying OTA service.

That trade can be especially valuable when the mobile team is small and the release controls offered by the provider already fit the application’s requirements.

Six questions that usually make the decision clearer

Before choosing, assign an explicit owner to these questions:

1. Who gets paged when update checks or artifact downloads fail?
2. Who upgrades the OTA service and proves old store binaries still work afterward?
3. Who restores release metadata and artifacts after a failure?
4. Who rotates delivery or signing credentials without breaking installed apps?
5. Who validates rollout, rollback, and fallback behavior after React Native, Expo, iOS, or Android changes?
6. Which requirements truly need custom infrastructure rather than simply feeling nicer to control?

If the answers are obvious, the deployment choice usually becomes easier.

If nobody owns them, “self-hosted” is currently describing a topology rather than an operating model. (Bundle Drop)

Where Bundle Drop fits today

Disclosure: I built Bundle Drop.

Today, Bundle Drop should be evaluated as a managed OTA service.

Its public SDK currently documents Expo and bare React Native support, runtime gating, channel-based distribution, targeted rollouts, rollback safety, hybrid patch/full-bundle delivery, observability metadata, and CI/CD publishing. (npm)

Self-hosting is part of the project’s longer-term direction.

There is no announced availability date and no currently supported self-hosted Bundle Drop deployment.

So a team with a hard self-hosting requirement today should evaluate systems that satisfy that requirement today rather than planning around an unannounced future capability. (Bundle Drop)

That limitation is important.

Infrastructure ownership is an architectural constraint.

It should not depend on roadmap assumptions.

Choose the boundary your team can sustain

Managed and self-hosted OTA can both be reliable.

They move responsibility to different places.

Managed delivery trades some infrastructure control for an operated service boundary.

Self-hosting trades provider dependence for greater operational responsibility and customization.

The right choice is not the architecture that is easiest to demo.

It is the one your organization can still understand, maintain, secure, and recover during an incident years after the first successful OTA update.

Originally published on Bundle Drop Resources:

https://bundledrop.app/resources/managed-vs-self-hosted-ota