Managed vs Self-Hosted OTA: Which One Fits Your Team?

Choosing between managed and self-hosted OTA delivery is not mainly a question of where JavaScript bundles live. It is a question of who owns the system that decides which devices may receive a release, keeps the artifacts available, proves that downloaded content is valid, and restores service when any part of that path fails.

Both models can support a sound React Native release process. A managed service assigns much of the system's operation to a provider. A self-hosted system assigns it to the application team. Similar product features can therefore carry different responsibility boundaries.

OTA delivery sits on a production path and can affect installed applications without a new native binary. The right ownership model is one a team can operate safely over time—not simply the easiest to demonstrate.

The safety requirements stay; the ownership boundary moves

Managed OTA

The product team consumes an operated service.

Application and release policy

The mobile team owns compatibility decisions and release intent.

OTA service operation

The provider operates the service under its supported contract.

Platform maintenance

The provider owns service upgrades, resilience, and recovery work.

Self-hosted OTA

The organization runs the service in its own environment.

Application and release policy

The mobile team owns compatibility decisions and release intent.

OTA service operation

The internal platform team operates every production dependency.

Platform maintenance

The organization owns upgrades, resilience, recovery, and on-call.

Self-hosting changes control and responsibility; it does not remove the operational work.

Start with the safety boundary

Managed and self-hosted systems both need to keep JavaScript and assets inside the capabilities of the native binary already installed on each device. Other systems may express compatibility differently, but the underlying question is constant: which component is authoritative when deciding whether a release can run on this binary?

That answer must remain understandable during a migration, partial outage, or incident involving several native versions. Self-hosting gives the operating team more control over enforcement; a managed service still leaves the application team responsible for classifying native changes correctly. Runtime versions: the compatibility boundary for React Native OTA updates covers the per-platform model in detail.

Compare responsibility, not deployment labels

“Managed” and “self-hosted” cover a range of arrangements. A self-hosted deployment may run on an internal platform that already provides databases, object storage, observability, and identity. One team may operate published open-source software; another may build a custom service around an existing client protocol.

The useful comparison is the resulting responsibility map.

Area	Managed service	Self-hosted system
Native and client integration	App team integrates and upgrades the SDK	App team integrates the SDK and may also maintain protocol compatibility
Release control	Provider operates the control plane; app team defines release policy	Team implements or configures policy and operates its enforcement
Resolve and delivery availability	Provider operates the public service	Team owns availability, scaling, and incident recovery
Artifacts and retention	Provider supplies storage behavior and lifecycle controls	Team provisions storage, retention, cleanup, and recovery
Security maintenance	Shared between provider and customer	Team owns server patching and deployment, alongside client work
Customization	Limited to supported extension points	Potentially broad, with corresponding maintenance cost
Compliance and topology	Constrained to supported regions and controls	Can be designed around internal requirements

This is not a scorecard. Standardized behavior can help a small mobile team, while deep customization can be essential to a regulated platform team with an established control plane.

The client is only one part of the system

Both models require native integration. The SDK must initialize early enough to participate in update checks and recovery, preserve a working embedded bundle, and behave predictably across application restarts. React Native and Expo upgrades can affect native build inputs, bundling, assets, or the JavaScript engine, so client maintenance continues after the first successful update.

In a managed model, the provider normally maintains the service while the app team upgrades the client and validates its application. In a self-hosted model, the team may also coordinate server and client protocol versions, stage infrastructure upgrades, and preserve compatibility for older store binaries.

Mobile clients cannot be upgraded on demand. A server change must not silently break an older binary's update checks or recovery path. Before choosing self-hosting, identify who will test that compatibility matrix and how long old clients must remain supported.

Delivery includes more than object storage

Storing a bundle is straightforward. Operating a dependable delivery path includes more work:

• resolve availability and deterministic release selection;
• artifact storage, retention, cleanup, and restore procedures;
• integrity checks and, where required, signing and key lifecycle management;
• capacity planning for concentrated release traffic;
• patch and full-bundle delivery behavior;
• timeouts, partial downloads, retries, and safe activation;
• monitoring that distinguishes selection, transfer, validation, and apply failures.

A self-hosted system lets a team choose storage, topology, caching, and retention. That control can solve data-locality requirements or fit an internal platform. The team must also prove the path works during storage degradation, region failure, expired credentials, interrupted transfers, and backup restoration.

A managed service moves much of that work to a provider, but delivery risk remains. Teams should ask what happens during unavailability, whether the current verified bundle keeps running, and how a failed update is prevented from activating. They should understand retention and export behavior rather than assume managed artifacts are permanent.

Patch delivery deserves similar scrutiny. Smaller transfers can reduce bandwidth and exposure to unstable mobile networks, but a patch may require a particular starting state. A production design should define what happens when that state is absent or the optimized path cannot be used. Bundle Drop treats patch delivery as an optimization and retains verified full-bundle fallback; the principle is that delivery efficiency must not become a prerequisite for release reachability.

That transport tradeoff is examined separately in Why Bundle Drop Combines Patch Delivery with Full-Bundle Reliability.

Release controls need an operator

Channels, staged rollouts, targeting, and rollback are visible product features, but each depends on operational semantics below the interface.

A channel is a named release track. It should have documented behavior for publishing, promotion, retention, and access. Bundle Drop's channels documentation describes how bundles move between tracks, while production channels explains the separate retention designation for a real-user release path.

Controlled publishing also requires deterministic eligibility. When rollout state, audience rules, or percentages affect release selection, the system must apply those rules consistently and preserve an understandable audit trail. Bundle Drop documents its server-enforced model under Managed Publishing.

The concrete selection sequence is explained in How staged rollouts, targeting, and rollback fit together.

Self-hosted teams can adapt these controls to internal deployment approvals or identity systems. That can be a strong reason to own the service. The cost is that someone must define, test, and maintain the edge cases: paused releases, partial rollouts, missing audience properties, promotion between tracks, and concurrent operator actions.

Rollback illustrates why the operator matters. Changing server-side selection helps devices on their next successful check. It does not by itself recover a device that is offline or repeatedly fails during startup. A complete design needs a previous working bundle, a safe embedded fallback, and clear health semantics on the client. The Bundle Drop rollback guide separates dashboard rollback from on-device crash protection; any candidate system should be tested across both time horizons.

Observability, access, and audit are part of delivery

OTA releases create multiple JavaScript identities under one app-store version. During an incident, “version 4.2.0” may not identify the code actually running. Teams need the active bundle identity in error reports and need source maps associated with that same identity. Bundle Drop's observability guide shows this pattern for common error-tracking tools.

For a managed service, evaluate the available release history, runtime identity, logs, audit information, access model, and integration points. Also establish how provider incidents are communicated and which evidence is available to the customer during diagnosis.

For self-hosting, decide which metrics and traces constitute service health before production use. A successful API response is not enough if the selected artifact cannot be downloaded, verified, or activated. Access control should distinguish reading release state from publishing, promoting, rolling back, or deleting artifacts. Operator actions should be attributable, and audit records need their own retention policy.

These capabilities are easy to postpone because they do not affect the first internal update. They are harder to add after the system becomes a critical release path.

Security, backup, and disaster recovery remain ongoing work

Self-hosting offers direct control over network boundaries, credentials, encryption, regions, and data residency. It can be the appropriate choice when policy requires a specific topology, customer-controlled keys, an isolated network, or evidence produced by an existing compliance program.

That control brings continuing obligations: security updates, credential rotation, vulnerability response, database migrations, backups, restore tests, and disaster recovery. Metadata and artifacts must be recoverable into a consistent release state. Incident plans should cover both outages and operator mistakes.

Managed providers carry much of the infrastructure obligation, while customers still own application credentials, internal access decisions, SDK upgrades, and release policy. Compliance is not automatically solved by either model. A team should compare actual controls, contracts, regions, evidence, and incident responsibilities against its requirements.

Open source is not the same as zero operating cost

An open-source server may remove or reduce software license cost and give the team valuable control. It can also make the implementation inspectable and adaptable. Those are real benefits.

The sustained cost, however, is the work required to keep the release path safe and available. That includes infrastructure, upgrades, security response, database and artifact lifecycle, capacity testing, observability, on-call coverage, incident review, and compatibility validation as React Native, Expo, iOS, and Android evolve.

Existing platform capabilities change the calculation. A company with reliable patterns for services, object storage, identity, deployment, backups, and on-call may absorb an OTA service at reasonable marginal cost. A mobile team without those systems may spend substantial time building operational foundations.

Managed pricing likewise should be compared with total value and constraints, not treated as inherently cheaper. Provider fees, supported regions, limits, migration options, and dependence on the service all matter. The useful comparison is total operating cost over the expected lifetime, including the people needed to own failures—not license price versus subscription price.

Time-to-integrate and time-to-operate are different

A proof of concept measures whether an application can publish and load an update. Production readiness asks whether the organization can keep that system trustworthy.

For a managed service, time-to-operate still includes native integration, compatibility policy, channel design, access setup, monitoring context, staged-release practice, and rollback exercises. For self-hosting, add service deployment, hardening, upgrades, backups, capacity testing, alerting, and an on-call runbook.

Do not evaluate self-hosting only by the time needed to start a container, or a managed service only by the time needed to install an SDK. Test a complete release lifecycle: upload, controlled eligibility, interrupted delivery, safe activation, observability, rollback, credential rotation, and recovery from an unavailable dependency.

A practical decision framework

Self-hosting is a strong candidate when several of these statements are true:

• a hard regulatory or data-locality requirement cannot be met by available managed offerings;
• the organization already operates comparable high-availability services and artifact pipelines;
• custom authentication, release semantics, or network topology is essential rather than merely preferable;
• a named team accepts on-call and security ownership for the full OTA path;
• the organization is willing to maintain compatibility for installed clients over time.

A managed service is often a better organizational fit when:

• the mobile team wants to own application release policy without operating another production service;
• standard release controls meet the team's needs;
• predictable time-to-operate matters more than infrastructure customization;
• there is no dedicated team prepared to own resolve availability, artifact lifecycle, backups, and upgrades;
• provider-supported topology and compliance controls satisfy current requirements.

Before deciding, assign owners to these questions:

1. Who is paged when update checks or artifact downloads fail?
2. Who upgrades the service and validates old store binaries afterward?
3. Who restores metadata and artifacts, and when was that procedure last tested?
4. Who rotates signing or delivery credentials without disrupting installed clients?
5. Who proves that rollout, rollback, and fallback behavior still work after a platform change?
6. Which requirements genuinely need customization or local control?

If those answers are explicit, the choice tends to become clearer. If they are not, the deployment label is hiding unresolved operational ownership.

Where Bundle Drop fits today

Today, Bundle Drop should be evaluated as a managed service. Teams can assess its documented runtime compatibility, channel, publishing, delivery, rollback, retention, and observability behavior without taking on operation of the Bundle Drop service itself. The broader choice after CodePush is discussed in Life after CodePush: choosing an OTA strategy for React Native.

Self-hosting is part of Bundle Drop's longer-term product direction, but there is no announced availability date and no currently supported self-hosted deployment offering. That direction should not be treated as a commitment, an imminent feature, or a basis for present architecture planning. A team with a hard self-hosting requirement today should evaluate options that satisfy it today.

That limitation is important because ownership requirements are architectural constraints, not preferences to revisit after integration.

Choose the responsibility boundary your team can sustain

Managed and self-hosted OTA systems can both be reliable. Managed delivery exchanges some infrastructure control for a defined service boundary. Self-hosting exchanges provider dependence for deeper operational responsibility and customization.

The deciding factor should be organizational fit: existing platform staff, regulatory and topology requirements, the need for custom behavior, incident ownership, and willingness to maintain the whole safety envelope. Evaluate the system that must still work years after its first successful update—not only the deployment that is easiest to start today.