Self-Hosted OTA Updates for React Native: The Real AWS Cost (2026 Breakdown)
Published
Somewhere in your team right now, someone is probably making a case for self-hosting OTA updates. Fork the open-source CodePush server. Build on Expo Updates. Or just roll something custom, since you've already got the AWS account and the team to run it. The pitch usually sounds something like: "it's just an app server, a database, and a CDN. We can stand this up in a week."
That pitch isn't wrong, exactly. It's just incomplete.
What actually lands on the AWS bill a few months later is a longer list than anyone scoped out in that first conversation, and some of the line items don't show up until you're already committed. So before that decision gets made, or unmade, it's worth knowing exactly what the real number looks like. Not a guess. The actual bill, broken down piece by piece, at three different scales.
That's what this post is.
This guide is for teams evaluating build vs buy OTA for React Native: What is the real React Native OTA update cost on AWS? How much does a CodePush self-host setup actually run per month? What line items get left out of back-of-envelope estimates?
The Setup
Here's what we're pricing, and why.
Infrastructure stack
The default choice for most teams, with well-documented pricing.
EC2
App servers that handle update-check requests and serve release metadata to client apps.
GCP: Compute Engine · Azure: Virtual Machines
RDS
Database for release records, device registrations, and rollout state.
GCP: Cloud SQL · Azure: Azure SQL
S3
Object storage for JavaScript bundles that users download on each update.
GCP: Cloud Storage · Azure: Blob Storage
CloudFront
CDN that delivers bundles to users globally — most of your bandwidth cost lives here.
GCP: Cloud CDN · Azure: Azure CDN
Pricing assumptions
Bundle size
9MB. A normal-sized React Native app.
Release cadence
4 releases a month. Roughly weekly, which is typical for an active team.
Bandwidth overhead
15% on top of the raw download numbers, to account for failed downloads and retries. Mobile networks aren't perfectly reliable, and this is a standard way to account for that.
Caching
Redis comes into the picture from Tier 2 onward. At low traffic, the database can handle update-check queries directly. Past a certain point, that traffic needs a cache in front of it.
Redundancy
From Tier 2 onward, we're assuming a setup with failover, Multi-AZ database, multiple app servers behind a load balancer. A single instance with no redundancy is realistic for a small app, but not for something a large user base depends on for updates.
CDN plan
For each tier, we picked the CloudFront plan that actually fits the traffic and the requirements of that tier, rather than using the same plan across the board. Where an uptime SLA matters, that's factored in separately.
Analytics infrastructure
From Tier 2 onward, we've included a basic line for storing and querying rollout data, which app versions are out there, how releases are performing. Even a minimal setup for this has a cost, and it's one that's easy to leave out of a back-of-envelope estimate.
Tier 1: ~6,000 Monthly Active Users
A small app, early stage. One app server, one small database, no Redis yet. CloudFront usage here is low enough to stay within the free tier.
| Component | Cost/month |
|---|---|
| EC2 (app server) | $15 |
| RDS (database) | $22 |
| S3 (bundle storage) | $1 |
| CloudFront | $0 (within free tier) |
| Total | $38/month |
This figure doesn't include an uptime SLA. CloudFront's SLA-backed plans start at a flat $200/month regardless of traffic, so adding one here would more than 6x this number. Whether that's necessary at this stage is a real question, and one worth coming back to once you've seen the larger tiers.
CloudFront SLA-backed plan
$200/month flat fee
Same cost whether you're serving 6,000 users or 600,000. Adding an SLA at Tier 1 would more than 6x the total bill.
Tier 2: ~60,000 Monthly Active Users
A growing app. More releases, more users checking for updates, and the point where Redis starts to matter and an uptime SLA becomes a reasonable thing to ask for.
Without an uptime SLA:
| Component | Cost/month |
|---|---|
| EC2 | $30 |
| RDS | $37 |
| Redis | $13 |
| S3 | $4 |
| CloudFront | $0 |
| CloudWatch (monitoring) | $10 |
| Basic analytics infrastructure | $30 |
| Total | $124/month |
With an uptime SLA:
| Component | Cost/month |
|---|---|
| Everything above, plus... | |
| CloudFront (SLA-backed plan) | $200 (replaces $0) |
| Total | $324/month |
The $200 CloudFront line is a flat fee, the same whether you're serving 60,000 users or 600,000. At this tier, it's the single largest line item by a wide margin, and it's worth noting that it doesn't scale down for smaller traffic the way most of the other costs do.
Tier 3: ~900,000 Monthly Active Users
A large app, production-grade. Redundant app servers, Multi-AZ database, and an uptime SLA that's no longer optional at this point.
| Component | Cost/month |
|---|---|
| EC2 (2x instances, redundant) | $124 |
| ALB (base) | $16 |
| ALB (capacity unit charges) | $30 |
| RDS (Multi-AZ) | $160 |
| Redis | $25 |
| S3 | $15 |
| Inter-AZ data transfer | $15 |
| CloudFront (SLA-backed) | $200 |
| NAT Gateway | $32 |
| CloudWatch | $28 |
| Analytics infrastructure | $50 |
| Total | $695/month |
At this scale, the infrastructure cost is real but proportionally smaller relative to everything else running. $695/month for the update infrastructure of an app with 900,000 monthly users is, on its own, not an unreasonable number.
How This Compares to React Native Stallion
We build React Native Stallion, an OTA update platform for React Native, so here's how the numbers above stack up against it.
| Tier | Self-Host (AWS) | React Native Stallion |
|---|---|---|
| ~6,000 MAU | $38/mo | $0/mo (Free) |
| ~60,000 MAU | $124–$324/mo | $51/mo (Pro) |
| ~900,000 MAU | $695/mo | $519/mo (Enterprise) |
At every scale in this comparison, self-hosted AWS infrastructure costs alone exceed React Native Stallion's hosted pricing. That's before any of the engineering or operational work below even enters the picture.
And the AWS bill, it turns out, is the cheap part.
See how React Native Stallion pricing compares at your scale
Free tier for small apps, Pro at $51/mo, and Enterprise plans for larger teams. No AWS bill to manage.
When Self-Hosting Is Actually the Right Call
All of this assumes the question is purely "what's cheaper." For most teams, it is. But there's a category of team for whom self-hosting isn't really a cost decision at all, it's a compliance one.
If you're in fintech, healthcare, government, or any sector where "where does our data physically live, and who can touch it" is a question your security team needs a precise answer to, a third-party hosted service may not be an option regardless of price. Data residency requirements, internal security audits, and contractual obligations with your own customers can mean the update infrastructure has to sit inside your own infrastructure, full stop.
This is also usually where the math changes. Everything in this post assumes a team building and running this themselves, on their own AWS account, with their own engineers carrying all of the work described above. For a large organization, that's often a real, ongoing cost. For teams at this end of the spectrum, typically apps with 1M or more monthly active users, that ongoing cost is exactly what gets handed off with a fully managed on-premise setup.
A fully managed on-premise setup runs entirely on your own infrastructure, inside your own environment, with no bundles or release data ever leaving it, while the provider handles the setup, updates, and ongoing support. You get the compliance posture of self-hosting without the part where your team owns it forever.
If this sounds like your situation, it's worth a conversation rather than a cost table.
Need on-premise OTA updates for compliance?
React Native Stallion's on-premise offering runs entirely inside your infrastructure — no bundles or release data ever leave your environment.
The Part That Isn't on the AWS Bill
Here's where the real cost of self-hosting lives, and it's not in any of the tables above.
Engineering time. Not "a sprint," the ongoing kind. Someone has to design this thing, build it, review the pull requests, argue about whether the rollback API should be REST or gRPC, and then maintain all of it for as long as the app exists. Every hour spent on any of that is an hour not spent on the actual product, the thing your users presumably opened the app for.
A monitoring stack. CloudWatch gets you logs and basic metrics, but knowing whether a rollout is actually healthy usually means something more, dashboards, alerting rules, maybe a tool like Grafana or Datadog layered on top. Someone has to set that up, and then someone has to keep looking at it.
Maintenance and DevOps, indefinitely. AWS services don't stay still. Instances need patching, dependencies need bumping, and every so often something that's worked fine for a year quietly stops working because an underlying API changed. This is the gift that keeps on giving, mostly in the form of small unplanned tasks that show up in sprint planning with a shrug and a "someone should probably look at this."
Building the features people actually expect. In-app testing so QA isn't stuck waiting for a full release cycle. SSO so the release dashboard isn't one shared login away from a security incident. CI/CD pipelines so releases aren't a manual, fingers-crossed process. None of these are exotic asks, they're table stakes for most teams, and every one of them is a project of its own when you're starting from a bare CodePush fork.
Operations. Patching, scaling, incident response, and being the person who gets paged if a rollout goes wrong. At 2am. While the rollback button, which definitely worked the last time anyone checked, may or may not still work.
None of these show up as a tidy line item with a dollar sign next to it, which is exactly what makes them easy to underestimate. But add them up, even loosely, and they tend to dwarf the actual server costs from the tables above. The AWS bill is the part of this you can see. Everything in this section is the part you live with.
Frequently Asked Questions
Do these costs change if I'm on GCP or Azure instead of AWS?
The overall shape of the bill stays the same, you're still paying for compute, a database, storage, a CDN, and a load balancer, just under different names (Compute Engine instead of EC2, Cloud SQL instead of RDS, and so on). The exact dollar figures will shift a bit depending on the provider and region, but the proportions, and the line items that are easy to forget, are largely the same across all three.
What about apps with more than a few million monthly active users?
Past the largest tier in this post, self-hosted infrastructure costs keep climbing in a fairly predictable way. React Native Stallion offers custom Enterprise and on-premise pricing at that scale — built around your traffic, compliance requirements, and rollout patterns. That includes dedicated support, custom SLAs, and the full platform without your team owning the infrastructure.
Do I need an uptime SLA at the smallest tier?
Not necessarily. At 6,000 monthly active users, an outage is unlikely to be catastrophic, and CloudFront's SLA-backed plans add a flat $200/month regardless of how little traffic you're sending through them. Most teams at this stage are better served by keeping costs low and revisiting the SLA question as the user base, and the cost of downtime, grows.
Is this still relevant if I'm not migrating off CodePush specifically?
Yes. The cost structure here applies to any self-hosted OTA update setup for React Native, whether that's a CodePush fork, a custom build, or something based on Expo Updates running on your own infrastructure. The underlying AWS services and their costs don't change based on which software is running on top of them.
Get OTA updates without owning the infrastructure
React Native Stallion handles rollbacks, analytics, and CI/CD integration so your team can ship releases without building or running an update stack. Free tier available for all developers.
Related Resources
CodePush Alternative
Why teams fork CodePush and what self-hosting actually involves, including the AWS infrastructure behind it.
CodePush Alternative Comparison
Feature-by-feature comparison of self-hosted CodePush forks, Expo Updates, and React Native Stallion.
Expo EAS Update Pricing
How Expo EAS Update billing works at scale: MAUs, bandwidth, and why costs grow faster than expected.
Enterprise & On-Premise
Fully managed on-premise OTA updates for teams with data residency and compliance requirements.