Every Android OEM building on AOSP eventually hits the same fork: the device ships, the field fills with units, and now firmware has to reach all of them safely. The instinct is to build the pipeline. The question nobody costs out first is whether that pipeline is product or overhead.

TL;DR

• Production-grade OTA is six pieces of infrastructure, not one feature: CDN distribution, cryptographic signing, staged rollout and rollback logic, per-device tracking, the servers under all of it, and a team to keep it running.
• None of those six differentiate the product. They're table stakes that enterprise customers expect but don't pay extra for.
• Building in-house is a multi-quarter project competing with the roadmap for the same engineers. Every sprint spent on OTA plumbing is a sprint not spent on the product your customers are actually buying.
• Esper Airwave is the buy-side answer: the same OTA subsystem already delivering firmware to Esper Foundation across hundreds of thousands of production devices, no servers or CDN to stand up, and no platform to adopt. You keep signing authority; Airwave never touches your firmware.
• Esper Airwave product page · Esper docs

What goes into production OTA infrastructure?

Before committing engineers to an OTA pipeline, cost out what "production-grade" actually requires. It's not one service. It's six infrastructure components, each with its own failure modes, operational burden, and staffing requirement.

1. Servers and backend. Compute, storage, and a database layer for package management, device registry, and rollout state. This isn't a weekend project. It's a production system that has to stay up when 50,000 devices check in simultaneously after a staged rollout window opens. Schema migrations, capacity planning, and incident response come with it.

2. CDN distribution. Global edge delivery so those 50,000 devices don't all hit one origin server. Without a CDN layer, firmware downloads become a bottleneck that throttles your rollout speed and creates regional disparities in update delivery. You're now in the content delivery business.

3. Cryptographic signing. Key management, a signing pipeline, key rotation policies, and HSM considerations for compliance-sensitive verticals. Signing isn't optional. Unsigned or improperly signed updates are a compliance risk that disqualifies you from enterprise procurement cycles. Healthcare, payments, and logistics buyers require documented signing chains in their RFPs.

4. Staged rollout and rollback logic. Phased deployment, the ability to halt before a bad build reaches the whole fleet, and recovery on the devices that already took it. This is the difference between a firmware update and a firmware incident. Worth knowing before you scope it: the rollback half is partly the platform's job, not yours. On A/B-partition devices, Android reverts a failed update to the known-good slot at the bootloader level on its own. What you build is the staging and the visibility around it, not the rollback itself.

5. Per-device tracking. Which device has which build, which failed, which rolled back, and where firmware drift is accumulating across the fleet. Without this visibility, your support team debugs version-specific issues blind. Every escalation that traces back to firmware drift is engineering time spent on ops instead of roadmap.

6. The team. Someone owns this 24/7. On-call rotations. Incident response runbooks. Capacity planning before every major rollout. OTA infrastructure doesn't run itself, and the person maintaining it isn't shipping product features.

Each of these is a cost center and an operational dependency. None of them differentiate your hardware or software in the market.

Why is each piece load-bearing?

Remove any one of the six and the consequences are immediate. Unsigned updates mean compliance risk and lost enterprise deals in any vertical with procurement security requirements. No staged rollout means a bad build reaches the entire fleet before anyone knows it's broken. No per-device tracking means blind fleet management where your support team can't distinguish a product bug from a firmware drift issue. For the full technical breakdown of how Android OTA signing, rollback, and verification work at the OS level, see How Android OTA Updates Work.

What does building OTA in-house actually cost?

The cost of building OTA infrastructure isn't measured in cloud bills. It's measured in what your engineering team doesn't ship while they're building plumbing.

The engineers qualified to build a production OTA pipeline are the same engineers qualified to ship the product features your customers are actually paying for. That's not a staffing problem you can hire around. Platform engineering talent with AOSP experience is scarce. The people who understand A/B partition schemes, cryptographic signing chains, and staged rollout state machines are the same people who understand your device firmware at the deepest level. Pointing them at OTA infrastructure means pulling them off the roadmap.

Building a production OTA pipeline is a multi-quarter commitment. The initial implementation is the smaller portion of the cost. The ongoing maintenance, the on-call rotation, the capacity planning before each major rollout, the incident response when a staged deployment stalls at 30% and nobody knows why: that's the standing tax. It doesn't shrink as the fleet grows. It compounds.

The pattern repeating across the Android OEM landscape is revealing. Teams that haven't built OTA infrastructure are distributing firmware via zip files hosted on shared drives, USB sticks shipped to customer sites, or engineers flying to field locations to flash devices manually. This isn't a hypothetical. It's the actual state of firmware delivery at OEMs that chose to defer the OTA investment and haven't found a viable alternative.

That manual approach has a specific business cost beyond engineering time. Enterprise procurement teams now require documented patch management and automated OTA capabilities in their RFPs. An OEM that can't demonstrate automated firmware delivery loses deals to competitors who can, regardless of how strong the hardware is. The firmware delivery gap is a sales problem masquerading as a technical one.

When does building your own OTA make sense (and when doesn't it)?

Honest decision criteria matter here. Build-vs-buy on OTA infrastructure has a clear decision boundary, and it's narrower than most engineering teams assume.

Build if OTA delivery IS your product. If you're selling update infrastructure as a service to other OEMs, then the OTA pipeline is your core value proposition. Build it, staff it, and invest in it as a product line. The same logic applies if you have genuinely idle platform-engineering capacity with nothing competing for those engineers on the product roadmap. That situation is rare enough that it's worth naming explicitly: idle AOSP platform engineers with no roadmap pressure is not a common state.

Buy if OTA is table-stakes infrastructure. Your customers expect reliable firmware updates. They don't pay a premium for them. The OTA pipeline doesn't differentiate your hardware or your software. It's the delivery mechanism for the things that do differentiate you. This is the case for nearly every Android OEM shipping dedicated hardware into enterprise verticals.

The build-vs-buy calculation simplifies to one question: does the OTA pipeline generate revenue, or does it protect revenue? If it protects revenue, it's infrastructure. If it's infrastructure, the engineering investment is overhead, not product investment.

The buy-side answer that doesn't force you onto a platform

Esper Airwave maps directly against those six infrastructure components. Most of them it takes on outright; signing stays with you by design, and one piece of the rollback story was never anyone's to build. Each component it absorbs is engineering capacity returned to the product roadmap.

• Servers and backend: Airwave provides the compute, storage, and device registry. No infrastructure to stand up or maintain. No capacity planning before rollouts.
• CDN distribution: Airwave handles global edge delivery. Firmware packages reach devices at the edge without your team managing a CDN layer.
• Cryptographic signing stays with you. This is the one component of the six Airwave doesn't take over, by design. You keep full signing authority and key management; Airwave validates each build against your registered signing fingerprint, delivers it, and never holds your keys or touches firmware content. Signing stays yours because that's the security boundary OEMs want, not a gap Airwave fills.
• Staged rollout and rollback: Airwave delivers firmware through an approval gate to targeted device groups, so a build reaches a controlled set before it reaches the fleet. Granular staged-rollout controls, configurable percentage rings, automatic pause thresholds, timed observation windows, are on the Airwave roadmap rather than in the console today; in the interim, maintenance windows can be honored through device policy. The rollback half of this component isn't Airwave's to provide: on A/B-partition devices, Android itself reverts a failed update to the previous slot at the bootloader level, with no instruction from Airwave and no new data delivered. What Airwave adds is the delivery and the visibility around it.
• Per-device tracking: Airwave provides rollout observability. Which devices have which build, which failed, which rolled back. Firmware drift visibility across the fleet.
• The team: Esper operates the OTA infrastructure. The on-call rotation, incident response, and capacity planning are Esper's operational responsibility, not yours.

Airwave runs on the same OTA infrastructure that has delivered firmware for Esper Foundation across hundreds of thousands of production devices for years. The standalone product is newly available (request early access below), but the infrastructure underneath isn't a beta. It's production-hardened against the failure modes that surface at fleet scale.

The no-MDM thread matters here. Airwave works with any AOSP build, alongside any MDM (Esper MDM, Workspace ONE, Intune, SOTI) or no MDM at all. There's no vendor lock-in. No platform adoption required. No enrollment dependency. You bring the firmware package, Airwave handles delivery. For a closer look at Airwave, Introducing Esper Airwave.

The instinct to build the pipeline is the expensive default

The default move at every engineering-led OEM is "build it, we're engineers." Nobody runs opportunity-cost math on that instinct. The pipeline feels like control. It feels like the responsible infrastructure investment. But control over what? Over six pieces of undifferentiated infrastructure that consume engineering bandwidth indefinitely and produce zero competitive advantage.

The actual mistake isn't building something that's hard. It's treating undifferentiated infrastructure as a product investment. The engineers maintaining an OTA backend, debugging CDN cache invalidation, rotating signing keys, and troubleshooting stalled rollouts are engineers who aren't improving the product that customers buy. That's not infrastructure investment. It's opportunity cost with a permanent headcount allocation and no product return.

Every quarter the OTA pipeline stays in-house is a quarter where the roadmap absorbs the maintenance burden. The pipeline doesn't get cheaper to operate as the fleet grows. It gets more expensive. More devices, more rollout complexity, more edge cases, more on-call hours. The standing tax compounds in the same direction as the fleet.

Building OTA in-house protects revenue. It never generates it.

Shipping firmware over the air safely is six pieces of infrastructure that don't differentiate your product. Building them yourself is the most expensive way to solve a problem someone has already turned into managed infrastructure.

Request early access to Esper Airwave

Get a 50-device test cohort ready. Esper will handle the infrastructure so your engineers can get back to the roadmap. Request access to Esper Airwave →

FAQ

What does it take to build an OTA update system for Android devices?

Production-grade OTA requires six infrastructure components: servers and backend for package management and device registry, CDN distribution for global edge delivery, cryptographic signing with key management and rotation, staged rollout and rollback logic, per-device tracking for firmware drift visibility, and a dedicated team for on-call operations and capacity planning. Each component has its own failure modes and operational burden. One nuance worth knowing going in: the rollback piece is partly handled by Android itself on A/B-partition devices, so what you build is the staging and visibility, not the reversion. For a technical breakdown of how Android OTA signing and rollback work at the OS level, see How Android OTA Updates Work.

Should an Android OEM build OTA infrastructure in-house or buy it?

Build if OTA delivery is your product, meaning you sell update infrastructure as a service. Buy if OTA is table-stakes infrastructure your customers expect but that doesn't differentiate your hardware or software. For nearly every Android OEM shipping dedicated hardware into enterprise verticals, OTA is a delivery mechanism, not a product. The engineering investment in building it in-house competes directly with the product roadmap for the same engineers.

Do you need an MDM to do OTA firmware updates on Android?

No. OTA firmware delivery and MDM are separate infrastructure layers. Esper Airwave works with any AOSP build, alongside any MDM (Esper MDM, Workspace ONE, Intune, SOTI) or no MDM at all. There's no enrollment dependency and no vendor lock-in. You bring the signed firmware package, Airwave handles the delivery pipeline.

How long does it take to build a production OTA pipeline for AOSP?

Building a production OTA pipeline is a multi-quarter engineering commitment, and the initial build is the smaller portion of the total cost. Ongoing maintenance, on-call rotations, capacity planning, incident response, and scaling the infrastructure as the fleet grows represent the standing operational tax. The engineers qualified to build this pipeline are typically the same engineers who should be shipping product features.

What's the risk of doing manual firmware updates instead of OTA?

Manual firmware delivery via zip files, USB sticks, or on-site engineers creates three compounding risks: unpatched devices accumulate security vulnerabilities that disqualify OEMs from enterprise procurement (RFPs now routinely require documented patch management), firmware version fragmentation makes support debugging expensive and unreliable, and the manual process doesn't scale as the fleet grows. Each risk has a direct revenue impact.

Is Esper Airwave tied to Esper MDM or Foundation?

Airwave operates independently of Esper MDM. It works with any AOSP build and any device management setup. Airwave runs on the same OTA infrastructure that has delivered firmware for Esper Foundation across hundreds of thousands of production devices, but it doesn't require Foundation or any other Esper product. The architecture is OTA-only, with no platform adoption required.