Expo Updatesprotocol v1
Over-the-air updates you host yourself
Ship JavaScript fixes to your Expo app without waiting on app store review.
Everything you need to ship an update
-
Your server signs every update, so nobody else can push code to your users.
-
Test on staging, then move the same build to production without an app store release.
-
Ship to a few users first, and pull it back before the rest ever see it.
-
Put any build back on its previous update, with the affected device count shown first.
-
Shared files are stored once and cached at Cloudflare’s edge, so devices download only what changed.
-
Who took the update, who hit a problem, and where, from the app’s own check-ins.
Deploy it once.
Publish as often as you like
One command sets everything up in your Cloudflare account. After that, shipping an update is one command from your app.
-
One command creates the server, its database, its file storage and the dashboard’s sign-in.
-
open-ota initpoints your app at the server, fills in the settings, and checks the result. -
open-ota publishuploads what changed, and devices pick it up on their next check.
Questions
No. Your app keeps the standard expo-updates library it already uses, pointed at your server instead of Expo’s. Your app code does not change.
Open OTA is MIT licensed. You pay Cloudflare for the Workers, D1, R2 and Analytics Engine usage in your own account, and nothing to us.
Any app using expo-updates that speaks version 1 of the update protocol. The server never looks at your Expo SDK version. Development and testing target SDK 57.
On its next check, which your app decides. There is no cache to clear: publish, widen a rollout, or roll one back, and the next check picks it up.
In your own Cloudflare account, and nowhere else. The update files, the device check-ins and the usage numbers all sit on infrastructure you control, and only people you name can open the dashboard.
Not yet. One deployment serves one app, across as many channels as you need. A second app means a second deployment.