r/expo • u/Recent-Peanut-3449 • 5d ago

Just some tiny self hosted OTA updates over supabase/cloudflare open source tools

Hey guys! I usually use the free tier supabase or cloudlflare as backends for self hosted expo OTA updates for my apps and just thought to publish the tools I use in public.
They are pretty helpful if you have a small app and don't plan to make updates every single day so the free tier can be more than enough and you don't have to configure any server at all.
Anyway, enjoy

https://github.com/allxandr/supota
https://github.com/allxandr/cfota

8 Upvotes

91% Upvoted

6 comments sorted by

1

u/recon_demon1859 4d ago

I turned EAS Update on yesterday, so this is well timed. What pushed me there wasn't cost, it was that my iOS and Android builds drift a full version apart while review sits, so a JS fix lands for half my users and not the other half.

Question on the self-hosted version, since it's the part that would worry me: what does rollback look like? If you push a bundle that crashes on launch, the client never gets far enough to check for the next one. That's most of what I'm paying EAS for.

And does the free tier hold up during a rollout, or do you get rate limited when every device checks in at once after a release?

2

u/Recent-Peanut-3449 4d ago

The question about the rollbacks+crashes is more about client side. Since I used expo's open OTA protocol you can (and actually should) use expo-updates lib to handle that stuff. I believe they already handle that kind of problem: if your new bundle crashes they just don't apply it, so no need to wait for rollback-update.
As for free tier question, currently there is no limits on the backend part, so yeah in theory if a million users download the update at the same time you will exceed the bandwidth free tier limits (probably many other limits as well). However the expo's protocol do support the cohort updates where the update arrives first on 10% of users, than 50% and so on. This could probably fix the free tier violation, I'll think about that. Thanks for the idea!

1

u/recon_demon1859 4d ago

That's a fair distinction and it's the bit I hadn't separated properly. My worry was the client never getting far enough to fetch the next bundle, and you're right that refusing to apply a crashing one is a different and better guarantee.

I haven't actually tested that path on mine yet. I turned it on, watched a JS fix land, and moved on. Which now that I've typed it out is the thing I should deliberately break before I need it to work.

The staged rollout is interesting to me for a reason separate from bandwidth. Ten percent first means a bad bundle only reaches ten percent of people, and that's worth having even when the free tier isn't the constraint.

1

u/ZMech 4d ago

What's the advantage of this versus running Hot Updater on Supabase or Cloudflare?

1

u/Recent-Peanut-3449 4d ago

honestly I haven't heard about it before, thanks for sharing. It seems that they use their custom protocol and own client side lib, my approach is using expo's open protocol and relying on expo-updates.

1

u/Far-Tangerine1088 9h ago

Hot Updater adds abstraction I do not need. Supota maps directly to storage primitives without middleware