Launch costs and heat rejection are two of the biggest expenses facing orbital data centers. At the engineering level, the challenge comes down to four interconnected questions: how to power an orbital server rack, remove its waste heat, keep it operating through faults, and schedule workloads when that rack becomes a network of 100 or 10,000 satellites.
1. The Four Layers of an Orbital Data Center
Each layer needs substantial redesign because the constraints in orbit differ fundamentally from those on Earth.
2. Power: Climbing from Watts to Kilowatts
A satellite’s computing power budget depends on solar-array area, solar-cell efficiency, illumination, power-conversion losses and battery capacity. The following tiers illustrate the scale of the challenge; figures for planned platforms are design targets rather than demonstrated operating capabilities.
Eclipse periods impose a hard constraint on power-system design. In many low Earth orbits, a satellite passes through Earth’s shadow for tens of minutes during each roughly 90-minute revolution. During that interval, batteries must support the computing payload and the rest of the spacecraft. The duration depends on altitude, orbital geometry and season; it is not a fixed 45 minutes. Some dawn-dusk sun-synchronous orbits offer near-continuous sunlight, substantially reducing battery requirements.
Starcloud-1’s operation of an NVIDIA H100 illustrates the challenge of supporting a data-center-class processor on a small spacecraft. An H100 SXM GPU can have a thermal design power of about 700 watts, before accounting for storage, communications and other spacecraft systems. Each step up the power ladder demands more generating capacity, more heat-rejection capacity and, often, a larger spacecraft and greater launch capacity.
3. Thermal Control: The Arithmetic of Radiative Cooling
Vacuum provides no surrounding air for convective cooling. Heat can still move through the spacecraft by conduction or through an internal fluid loop, but its ultimate route out to space is thermal radiation.
Under the Stefan–Boltzmann law, emitted thermal power scales with radiator area and the fourth power of absolute temperature. Net heat rejection also depends on emissivity, absorbed sunlight, Earth’s infrared radiation and the radiator’s view of cold space.
As an order-of-magnitude estimate, removing the full-power waste heat from a data-center GPU can require a radiator area on the order of a square meter or more. A figure such as 1.4 square meters for a 700-watt H100 assumes an effective heat-rejection rate of about 500 watts per square meter. It is an illustrative calculation, not a universal hardware requirement.
Three engineering approaches are central to the design:
Heat Pipes and Vapor Chambers
These components move heat from processors to radiator surfaces and help prevent local hot spots. They share underlying principles with cooling systems used in terrestrial computers, but spacecraft versions must withstand launch vibration and operate reliably under orbital conditions.
Deployable Radiators
Large radiator panels can fold for launch and deploy in orbit. Their performance helps determine how much heat-rejection capacity a mission obtains per kilogram of launched hardware. This makes radiator design a major constraint on orbital computing density.
Orientation Management
Solar arrays benefit from facing the Sun, while radiators benefit from minimizing absorbed sunlight and maintaining a clear view of cold space. These competing needs must be reconciled through spacecraft geometry, independently articulated components or carefully planned attitude control.
The large deployable structures envisioned for SpaceX AI1 and Starcloud-3 reflect the scale of the power and thermal problem. Installing more processors is only useful if the spacecraft can supply their electricity and remove their waste heat. The physical ceiling on computing density depends on radiator temperature, area, material properties and the surrounding thermal environment.
4. Computing and Scheduling: Fault Tolerance Meets Orbital Dynamics
The Computing Layer: Making Commercial Hardware Work in Space
Commercial GPUs can suffer radiation-induced bit flips, functional interruptions and potentially damaging events. The frequency and severity depend on the device, orbit, shielding and operating conditions.
One practical approach combines commercial processors with shielding, error detection and correction (EDAC), watchdogs, checkpointing and redundant copies of critical state. These measures reduce risk, but shielding alone does not make a commercial processor radiation-hardened.
ESA’s Φsat-1 provides an example of a low-power approach: it used the commercial Intel Movidius Myriad 2 vision processor after radiation testing. Its purpose was onboard image screening, rather than the much larger workloads associated with a data-center GPU.
Starcloud-1’s H100 demonstration provides evidence that commercial high-performance computing hardware can execute AI workloads in orbit. A successful demonstration, however, does not establish fleet-wide reliability or a predictable service life. Those questions require longer operating records, fault statistics and experience across more spacecraft.
The Scheduling Layer: A Different Kind of Load Balancing
When a server rack becomes a constellation, load balancing becomes a problem that combines computing, networking and orbital dynamics.
Communication windows: Orbital geometry determines when satellites can communicate with ground stations and with one another. Transfers must fit the available contact windows, and task placement must account for when input data can arrive and results can leave. Computation itself may continue between contacts if sufficient data and resources are available onboard.
Coupled power and workload scheduling: Before assigning a demanding job, the scheduler must consider battery charge, expected solar generation, upcoming eclipse periods and thermal headroom. Computing schedules and spacecraft resource schedules must be planned together.
Work sharing between satellites: Laser links can connect spacecraft into orbital computing clusters, allowing data and selected workloads to move between nodes. Routing and scheduling must cope with changing connectivity, link acquisition, bandwidth limits and interruptions. Some links between satellites in similar orbits may remain relatively stable, while others change more frequently.
Scaling from 100 satellites to 10,000 adds another challenge: the system must coordinate many more resource states, communication paths and possible failures. A scheduler that works for a small demonstration may need a distributed or hierarchical architecture to operate efficiently at constellation scale.
A Reality Check: Identify the Limiting Layer
Thermal control is a major potential bottleneck in orbital data centers, although the limiting factor varies by design. More solar-array area can increase generation, but also adds mass and deployment complexity. Commercial processors offer substantial computing capability, but require fault mitigation. Scheduling algorithms can improve utilization, but cannot create power, bandwidth or radiator capacity that the spacecraft does not have.
Heat rejection remains bounded by physics. Better materials, higher allowable temperatures and improved geometry can help, but they do not remove the need to balance heat generation against heat rejection.
When assessing an orbital data-center proposal, begin with three numbers: How many kilowatts can it sustain? How much radiator area does it carry? What is its launch mass? Then check the assumptions behind them, including radiator temperature, orbital illumination and the power consumed by supporting systems. If those figures do not form a coherent engineering budget, an attractive presentation is not enough.
Conclusion
An orbital data center requires more than putting terrestrial servers aboard a spacecraft. It requires power, thermal control, computing and scheduling to function as one integrated system. That is why the sector can attract both speculative expectations and substantial engineering investment: solving one layer is manageable; making all four work together at a competitive cost is the harder task.
For Earth observation users, the practical value of computing—whether performed in orbit or on the ground—lies in turning imagery into timely, usable answers. STARPATH GLOBAL combines global satellite resources with data processing and AI interpretation to support applications in agriculture, forestry, mining and infrastructure. To match the imagery, processing workflow and delivery requirements to your project, discuss your needs with STARPATH GLOBAL and build a service around the decisions your team needs to make.
