All posts
3 min readBy BetterCodePush

Self-hosting a CodePush server in 2026: the honest total cost

Microsoft's open-sourced code-push-server makes self-hosting free the way a puppy is free. A clear-eyed accounting of what you take on, and the two situations where it's still the right call.

Self-HostingCodePushOTAInfrastructure

When Microsoft retired App Center, it published a standalone code-push-serverso teams could run the CodePush protocol on their own infrastructure. That repository is archived and Microsoft says it provides no support services. Self-hosting can remove a SaaS bill; it does not remove the operating work. Here's the whole budget.

What "self-hosted" actually means for an update server

An OTA server isn't a marketing site. It sits inside your release path and in your app's update path — clients may check it during launch, and your team needs it to ship a fix. That placement is what makes the operational load different from most internal tools:

  • The service itself — a server process you deploy, monitor, patch, and upgrade. The Microsoft repository is archived with no Microsoft support; if you adopt it, you own the service.
  • Storage and delivery — bundles need durable storage and a delivery design that works for the regions and network conditions you support.
  • Auth and access control — publish rights to this system are the ability to run code on every customer device. Locking that down is not a nice-to-have; it's the reason the OTA threat model exists.
  • Backups and history — release history is your rollback path and audit trail. Losing it during an incident means recovering by archaeology.
  • The client SDK problem — the archived react-native-code-push client states that it does not support the New Architecture. Self-hosting the server does nothing about that client compatibility gap.

The line items people forget

Infrastructure cost may be modest; the less visible spend is attention:

  • Upgrades and drift. Someone owns dependency updates, security patches, and compatibility testing as your apps change.
  • On-call, implicitly. Decide who responds when the update path is unavailable during an incident.
  • Ownership. Name maintainers, document recovery, and test the handover before the original implementer leaves.

Price attention honestly — maintenance time plus incident risk — alongside infrastructure and any SaaS quote. The comparison is not simply "free vs paid"; it is the cost of owning the release path versus delegating it.

When self-hosting is genuinely right

Two situations, and they're real:

  • Hard data-residency or air-gap requirements. If your policy or regulation prevents update artifacts from transiting third-party infrastructure, self-hosting may be required.
  • OTA is core infrastructure. A team with platform ownership, an on-call model, and clear requirements may reasonably choose to own the update path.

If you're neither, the honest question isn't "can we run it?" — of course you can. It's "is the update server where we want to spend our scarcest resource?" For most product teams the answer is no, which is why the practical middle ground is a managed service whose failure mode is safe: devices keep running their installed bundle if the service vanishes, and an exit path exists if the vendor disappoints. Keep the leverage, skip the pager.

Ship your first update

Create an organization and deploy an over-the-air update in minutes. No billing setup during the beta.

Start with BetterCodePush