OTA update security on every plan

Signing on every plan, verification on the device, and delivery with no server of ours on the path.

From the team behind Capawesome, trusted by 1,000+ teams

  • Bitpanda
  • BTC-ECHO
  • Clovis
  • DHBW
  • E.ON
  • EGYM
  • Eyloo
  • FARO
  • King Arthur Baking
  • Leexi
  • LLMBase
  • Logistiko
  • mobile function
  • Planfred
  • SINC
  • snapAddy
  • Tapni
  • Vattenfall
  • Vitruve
  • AppScreens
  • OpenForge
  • Summon Worlds
  • SpeedPay
  • Rechnerhaus
  • World Aquaculture Society
  • Helmholtz

How it works

Signed by you, checked by the device

Three questions come first: who can push an update, can a bad one be stopped, and does delivery depend on us.

Over-the-air (OTA) update security in HotCodePush rests on three answers: only you can sign an update, the device checks every file before it runs, and delivery has no server of ours on the path. You create a key pair and keep the private key; signing is available on every plan, free. Every file is verified on the device against what you released, and an update that fails to start in time rolls back on its own.

How an update reaches a device

The gates an update passes on the device: signed with your key, verified file by file, ready at first start, with the rollback path beneath.

The proof

Signing with a key only you hold

You create the key pair and keep the private key. HotCodePush stores the public half and refuses an unsigned upload once a key exists.

  • The private key never reaches us

  • Unsigned uploads refused once a key exists

  • Available on every plan, free

Two zones, yours with the laptop and the private key file, and HotCodePush with the public key only, joined by the signed manifest, with an unsigned upload marked refused.

The proof

No server of ours on the path

Devices read static files from the edge. Nothing we run sits between a published update and an installed app, so delivery never waits on us.

  • Published updates keep arriving without our servers

  • An update check is static files from the edge

  • Supports apps up to a billion devices, by construction

A phone reading the file stack on the edge while the control plane beside it is marked down: delivery runs from the edge with no server of ours on the path.

The proof

Rolls back on its own

An update that fails to come up is set aside, the device returns to the release before it, and the failure carries its reason.

  • A readiness check with no off switch

  • Back on the earlier release in seconds

  • The failure reported with its reason

A timeline from applied to launched to the readiness check, branching into confirmed or rolled back with its reason.

From the terminal

Sign once, then every upload is signed

Create your key pair, sign each release on your machine or in CI, and let doctor confirm the setup.

zsh — my-app

$ npx hotcodepush signing-key create
✓ key pair — wrote hotcodepush-private-key.pem; the private key never leaves this machine
✓ public key — registered with My App as sha256:9f2c4e1ab07d
$ npx hotcodepush release create --path dist --private-key-path hotcodepush-private-key.pem
✓ signed — manifest signed with sha256:9f2c4e1ab07d
✓ created release #43 on production — devices verify the signature before applying
$ npx hotcodepush doctor
ok configuration hotcodepush.json read
ok session logged in as Anna
ok signing_key 1 public key registered, HOTCODEPUSH_SIGNING_KEY matches it
ok versions SDK, CLI and hook are current
✓ clean — 11 checks, nothing to fix

Guarantees

What holds on every device

Guarantees a security review can trace along the device path.

unsigned uploads after a key
Refused
hash-checked on the device
Every file
resets a device
Never
data residency
EU

Figures as of November 1, 2026.

The field

How the field does it

Who may sign an update, what the device checks, and what answers an update check, from the vendors' own pages.

Feature HotCodePush EAS Update
Code signing Available on every plan, free Production and Enterprise plans
A bad update on a device Rolled back on its own when the first start misses the gate, on by default Error recovery before the first render, documented as not to be relied upon
What answers an update check Static files from the edge, read by the device A server answers each check with the newest manifest, per the Expo Updates protocol

Last verified 2026-10-28.

More features

Three more things every release gets

Each feature has its own page: the mechanism, the specifics, the field compared and the questions teams ask.

  • Adoption per release, every failed and skipped update with its reason, and monthly active devices that match the invoice, read in the console, the CLI or the API.

    See the feature
  • Labels your app sets choose which devices a release reaches, every condition is checked on the device, and the audience preview counts the reach before you publish.

    See the feature
  • Start a release small, let it widen on the schedule you set, and have it pause itself the moment failures rise, with one command back to the release before.

    See the feature

FAQ

Safety questions

You do. You create the key pair, keep the private key and sign on your machine or in your CI. HotCodePush stores the public key only, to show which key signed a release. Signing is available on every plan, free. Set up code signing
The device rolls back on its own. An update that fails to start in time is set aside, the device returns to the release before it, and the failure is reported with its reason. You can also roll back a release yourself with one command. Staged rollouts that pause themselves
They keep receiving updates. Devices read static files from the edge, and nothing we run is on that path, so an outage on our side delays your next release, never the delivery of the ones you already published. How an update reaches a device
The whole device path. What a device reads is public by design, so the security page lists every file it fetches, what it verifies and what it sends back. A reviewer can trace the path without an account. Read the security page
Yes. The key you sign CodePush bundles with is accepted as it is, and HotCodePush registers its public half with the app. You keep one key across the migration instead of rotating a new one in. Set up code signing
It is refused. Once a public key is registered for the app, every upload has to carry a signature from one of its keys, in your pipeline as much as on a laptop. Nothing unsigned reaches a device. How an update reaches a device

Signed with your key, verified on the device, on every plan.

Free for 1,000 MAU. No credit card.