How SpaceX Manages Firmware Updates Across Millions of Starlink User Terminals
Most companies that manage four million devices at least get to use the internet to update them. SpaceX doesn’t have that luxury. Or rather, SpaceX is the internet. Every firmware update pushed to a Starlink user terminal travels through the same satellite constellation that serves the user’s traffic. The delivery pipe and the product are the same infrastructure. Push an update too aggressively, and you’re degrading the service you’re trying to improve. Push too slowly, and millions of terminals linger on stale code with known bugs.
This creates an engineering problem that no other hardware company faces at this scale. Over four million Starlink user terminals are deployed across 100+ countries. Each one runs custom firmware that SpaceX updates remotely, over a LEO satellite link, to hardware SpaceX also designed, through a constellation SpaceX also operates. The vertical integration is staggering, and it’s what makes the whole thing work.
This article reconstructs how that system operates using public evidence: FCC filings, GPL-mandated source code releases, hardware teardowns, SpaceX job postings, and community-reported data from r/Starlink. Where public documentation ends, I’ve applied industry-standard OTA practices and labeled every inference clearly.
What’s Actually Running Inside Your Dishy
The Starlink user terminal, affectionately called “Dishy McFlatface,” is a far more sophisticated embedded system than most people realize.
Hardware teardowns (notably by Oleg Kutkov and documented on iFixit) revealed early-generation terminals running a SpaceX-designed quad-core ARM Cortex-A53 SoC, eMMC flash storage, and custom beamforming ASICs driving the phased-array antenna. Later hardware revisions have moved to further custom silicon, but the architectural bones remain similar: a capable application processor, flash storage, and a lot of RF-specific hardware.
The software stack is Linux-based. This isn’t speculation. SpaceX has released kernel source code to comply with GPLv2 licensing obligations. The userland shows evidence of BusyBox, a standard lightweight utility suite common in embedded Linux systems. Firmware version strings follow a format like 2024.xx.xx.mr####, catalogued extensively by the Starlink user community on tracking sites and Reddit.
The critical architectural detail is the A/B partition scheme. Teardown analysis of the eMMC partition table reveals two root filesystem slots, rootfs_a and rootfs_b, plus a persistent data partition:
┌─────────────────────────────────────┐
│ eMMC Flash │
├──────────┬──────────┬───────────────┤
│ Bootloader│ │ │
│ (u-boot/ │ rootfs_a │ rootfs_b │
│ custom) │ (active) │ (standby) │
├──────────┴──────────┴───────────────┤
│ persistent_data │
│ (config, telemetry, credentials) │
└─────────────────────────────────────┘A/B partitioning is the gold standard for embedded OTA and the reason SpaceX can update millions of terminals without bricking them. The active partition runs the current firmware. The update writes to the standby partition. On reboot, the bootloader switches to the newly written partition. If something goes wrong, the bootloader reverts to the previous, known-good partition.
No half-written filesystem. No corruption. No truck roll to a customer’s rooftop. The update is atomic: it either fully succeeds or fully doesn’t.
The Delivery Path: Satellite to Terminal
This is where Starlink’s OTA challenge diverges from every terrestrial fleet. The update doesn’t travel over someone else’s network. It travels over SpaceX’s own constellation and shares bandwidth with every customer watching YouTube.
The physical link. Each Starlink satellite orbits at roughly 550 km altitude in low Earth orbit. At that altitude, a single satellite is overhead for only about two to eight minutes depending on elevation angle. The terminal’s phased-array antenna electronically steers its beam to track the satellite, then performs a handoff to the next one as it passes. The terminal is constantly switching between satellites. There is no persistent connection to a single bird.
Downlink as delivery pipe. Firmware payloads travel over the same Ku-band (or Ka-band on newer hardware revisions) downlink that carries user internet traffic. FCC filings describe the terminal’s ability to receive “management and control” data alongside user traffic, but the fundamental constraint remains: every byte of firmware is a byte not carrying customer data. At fleet scale, a full firmware image of 500 MB–1 GB pushed to four million terminals would consume a staggering amount of constellation capacity.
Delta updates are almost certain. SpaceX hasn’t publicly detailed its update compression strategy, but the math makes anything else untenable. Binary delta approaches (like bsdiff or similar tools) generate patches containing only the differences between firmware versions, often reducing payload size by 80–95%. SpaceX job postings have referenced “efficient update delivery” and “minimizing bandwidth consumption.” Based on industry-standard practice, delta updates are the overwhelmingly likely approach here. The economics of full-image updates at this scale simply don’t work.
Scheduling favors off-peak hours. Users on r/Starlink overwhelmingly report terminal reboots (the visible sign of a firmware update) occurring between 1 AM and 4 AM local time. This is consistent with SpaceX scheduling updates during low-usage windows, when bandwidth allocated to firmware delivery competes with fewer active user sessions.
Multicast is architecturally tempting. Satellite downlinks are inherently broadcast: one transmission can theoretically reach every terminal within a beam’s footprint. DVB-S2 standards, which Starlink’s physical layer has similarities to, support multicast delivery. While SpaceX hasn’t confirmed using multicast for firmware, the architectural logic is compelling. One transmission updating thousands of terminals simultaneously would be vastly more efficient than unicast delivery to each. This remains speculative.
The end-to-end path looks like this:
┌──────────┐ Ku/Ka-band ┌──────────────┐
│ Starlink │ ──────────────── │ User Terminal │
│ Satellite│ downlink beam │ (Dishy) │
└────┬─────┘ └──────┬────────┘
│ │
│ Inter-satellite laser link │ Writes to
│ or ground station uplink │ standby partition
│ │
┌────┴──────────┐ ┌──────┴────────┐
│ Ground Station │ │ Reboot into │
│ (gateway) │ │ new firmware │
└────┬───────────┘ └───────────────┘
│
┌────┴──────────────┐
│ SpaceX Firmware │
│ Deployment Service │
└────────────────────┘Phased Deployment at Fleet Scale
SpaceX does not push firmware to four million terminals simultaneously. The evidence for phased rollouts is strong and comes from multiple sources.
Job postings say it explicitly. SpaceX “Software Engineer, Starlink” listings have included responsibilities like “phased rollouts,” “feature flags,” and “A/B testing.” These aren’t ambiguous. They directly describe a staged deployment pipeline with gating mechanisms.
User-reported data confirms it. On r/Starlink and firmware tracking sites, users routinely report running different firmware versions at the same time. A new version might appear on a handful of terminals in one region, then gradually spread across geographies over days or weeks. This is the classic fingerprint of a canary → staged → global rollout pattern.
The fleet isn’t homogeneous. There are at minimum four major hardware revisions: the original round Dishy (v1), the rectangular v2, the v3/Standard, and the v4/Mini. Each has a distinct FCC ID (e.g., 2AWHPR201 for early revisions, distinct filings for subsequent generations) and distinct hardware configurations. Firmware must be built, tested, and validated per variant. A single “push to fleet” button doesn’t exist.
Telemetry drives rollout progression. SpaceX job postings reference “fleet health monitoring,” “anomaly detection,” and “telemetry pipelines.” Based on industry-standard practice for staged rollouts, SpaceX almost certainly monitors key metrics (error rates, reboot loops, signal-to-noise ratios, throughput) after each rollout stage before expanding to the next. If a canary group shows elevated failure rates, the rollout halts.
Rollback is automatic. With A/B partitioning, rollback isn’t a manual intervention. It’s a bootloader-level function. The standard embedded Linux pattern uses a watchdog timer: if the new firmware fails to reach a healthy state within a defined number of boot cycles, the bootloader reverts to the previous partition. Given SpaceX’s engineering rigor and the inaccessibility of many terminals (rooftops, remote locations, maritime installations), automated rollback isn’t optional. It’s survival.
Why Satellite OTA Is Harder Than Terrestrial
If you manage IoT devices over WiFi or cellular, you enjoy assumptions that Starlink engineers don’t get to make.
Intermittent connectivity is structural. A Starlink terminal’s link depends on constellation geometry, weather conditions, and physical obstructions. The connection is real-time reliable enough for internet service, but over the hours or days a firmware rollout spans, interruptions are inevitable. Updates must be resumable. A partial download written to the standby partition must not corrupt it. The system needs to pick up where it left off, or start over cleanly. A half-applied delta patch is worse than no update at all.
Latency matters for protocol overhead. LEO latency (roughly 25–60 ms round-trip) is far better than geostationary (~600 ms), but still introduces overhead for handshake-heavy protocols. Update protocols need to minimize round-trips.
Thermal and power constraints are real. Terminals consume 50–100W and generate significant heat, particularly the phased-array antenna. Writing to eMMC flash while the system is thermally stressed could affect flash reliability. Based on standard embedded engineering practice, the update process likely accounts for thermal state.
Firmware enforces regulation. Different countries have different RF transmission rules. FCC filings explicitly describe software-defined power limits and frequency band selection in Starlink terminals. The firmware itself is the enforcement mechanism for regional regulatory compliance. A firmware bug that sets incorrect transmission power in a specific country isn’t just a technical issue; it’s a regulatory violation. This adds a layer of validation to every update that most IoT teams never face.
What Your Fleet Can Steal From Starlink’s Playbook
You probably aren’t managing a satellite-connected phased-array antenna fleet. But the architectural principles Starlink uses scale down cleanly.
A/B partitioning is non-negotiable for any device fleet you can’t physically access. The cost of dual root filesystem partitions, a few hundred megabytes of extra flash, is trivial compared to a single truck roll or a bricked device.
Delta updates pay for themselves at roughly 1,000+ devices. Below that, the engineering overhead may not justify the bandwidth savings. Above that, the math becomes inescapable.
Phased rollouts with automated health gates prevent a bad firmware version from becoming a fleet-wide outage. Even simple staging (1% → 10% → 50% → 100% with error-rate thresholds at each gate) catches most catastrophic regressions.
Telemetry isn’t optional. You need to know your fleet’s state before, during, and after every rollout. If you can’t measure the impact of a firmware change, you can’t safely deploy one.
Design for resumable downloads from day one. Retrofitting resume capability into an OTA system is painful. Building it in from the start is straightforward.
Feature │ Starlink │ Typical IoT Fleet
─────────────────────┼───────────┼──────────────────
A/B Partitioning │ Yes │ ~40% adoption
Delta Updates │ Likely │ ~30% adoption
Phased Rollout │ Yes │ ~50% adoption
Rollback Capability │ Automatic │ Often manual
Link Reliability │ Variable │ Usually stable
Fleet Size │ 4M+ │ 1K–500K typicalThe adoption numbers above reflect industry surveys from OTA platform vendors like Mender and Memfault. The gap between what Starlink does and what most IoT fleets do is instructive, and closeable.
Building This Into Your Requirements
SpaceX is running one of the world’s largest embedded device fleets. They update it over a satellite link they also operate, running on hardware they also designed. That level of vertical integration creates a feedback loop: hardware informs firmware, firmware informs constellation operations, telemetry informs the next hardware revision. No other IoT operation can fully replicate that.
But you don’t need to replicate it. You need to steal the patterns.
As Starlink grows toward tens of millions of terminals and expands into vehicle-mounted, maritime, and aviation variants, the firmware management challenge compounds. More hardware variants. More regulatory regimes. More hostile thermal and vibration environments. The architectural decisions that make this manageable (A/B partitioning, delta updates, phased rollouts, automated rollback, deep telemetry) were made early and paid dividends at every stage of growth.
Whether you’re managing 500 sensors or five million, the principles are identical. Starlink just executes them in the most unforgiving delivery environment imaginable.
Hubble Network enables firmware-level connectivity to millions of devices via satellite—without requiring your own constellation. See how it works →