The elevator pitch for space-based data centers always includes thermal management. “No cooling costs! Radiative rejection to the void! Unlimited heat sink!”

The physics are real. Radiative cooling in vacuum is effective-there’s no theoretical limit on heat rejection rate, just a function of radiator area and temperature differential. Terrestrial data centers spend 30-40% of their energy on cooling. In orbit, that drops to near zero.

But when we built our thermal simulator and started modeling realistic orbital compute scenarios, we found the picture is more complicated than the pitch suggests. Some of what we learned was counterintuitive. Some of it changes how you should design these systems.

The equilibrium temperature problem

Here’s the basic physics. An object in orbit receives heat from three sources:

  1. Direct solar radiation: ~1,361 W/m² when facing the sun
  2. Earth albedo: reflected sunlight from Earth’s surface, varying with cloud cover and surface type
  3. Earth infrared: thermal radiation from Earth itself, ~240 W/m² average

It rejects heat through one mechanism: thermal radiation, proportional to T⁴ (Stefan-Boltzmann law).

At equilibrium, heat in equals heat out. A passive object in orbit stabilizes at some temperature determined by its geometry, optical properties, and orbital position.

Now add internal heat generation from compute hardware. The system needs to radiate that additional heat, which requires running hotter than the passive equilibrium.

Here’s the first counterintuitive finding: equilibrium temperature is very sensitive to radiator orientation. A radiator facing deep space sees a 3K heat sink. A radiator facing Earth sees a 255K heat sink. The difference in heat rejection capacity is enormous-roughly 20x for a radiator at 350K.

Most conceptual designs show radiator panels sticking out from a spacecraft body. They’re implicitly assuming those panels face deep space. In practice, maintaining that orientation continuously requires attitude control and limits how you can orient solar panels. The thermal design and the power design are coupled, and the coupling is non-trivial.

The eclipse cycling problem

Spacecraft in LEO go through eclipse cycles-typically 30-40 minutes of darkness per 90-minute orbit. During eclipse, solar input goes to zero while radiative output continues.

For traditional satellites with modest power dissipation, this isn’t a big deal. Internal temperatures drop a few degrees during eclipse, then recover.

For orbital data centers with tens of kilowatts of dissipation, eclipse cycles create a different problem: you have too much cooling capacity during eclipse.

We simulated a 50kW compute payload in a 550km orbit. During sunlight, radiator temperature stabilizes around 330K-warm but manageable for electronics. During eclipse, with no solar input but continued internal dissipation, radiator temperature drops to 280K within 15 minutes. If you’re not careful, internal components start approaching condensation temperatures.

The standard terrestrial intuition-“more cooling is always better”-doesn’t apply. In orbit, you need thermal mass and active control to handle eclipse transients, which adds complexity and mass.

Our simulations showed that optimal thermal designs for orbital compute are counterintuitively insulative in some areas-retaining heat during eclipse rather than maximizing rejection. This is opposite to terrestrial design principles.

The hot spot problem

Radiative heat rejection scales with surface area. A 100kW data center might need 200+ m² of radiator area, depending on operating temperature. That’s a lot of surface-bigger than most spacecraft buses.

The challenge is getting heat from concentrated sources (GPU dies, memory modules) to distributed radiators. On Earth, this is solved with liquid cooling loops and CRAC units. In orbit, you need similar heat transport, but the systems work differently.

Liquid cooling works in microgravity, but gravity-driven circulation doesn’t. You need pumped loops, which add power consumption and failure modes. Heat pipes work excellently in microgravity (arguably better than on Earth due to improved capillary action without gravity), but they have limited heat transport capacity and distance limitations.

When we model realistic compute payloads, we find that heat transport from source to radiator is often the binding constraint, not radiator area. You can add more radiator panels, but you can’t always get the heat to them efficiently.

The implication for orbital data center design: distributed compute architectures with processing spread across the spacecraft may thermal-limit at lower total power than concentrated architectures, because heat transport is distributed. This is counterintuitive-you might expect concentrated designs to overheat more easily.

The solar panel coupling

Here’s something that isn’t obvious until you model it: solar panels generate heat too.

Photovoltaic cells are maybe 30% efficient. The other 70% of incident solar energy becomes heat in the panel. A 100kW solar array absorbs ~330kW of solar energy. That’s 230kW of heat generation in the panels themselves.

If those panels are thermally coupled to the spacecraft body (which they usually are to some degree), they’re adding heat load to the system. If they’re thermally isolated, they run hot-reducing efficiency and accelerating degradation.

Our simulations found an optimal panel operating temperature around 50-80°C that balances efficiency against degradation rate. Achieving this requires careful thermal design of the panel-to-bus interface-neither fully coupled nor fully isolated.

This affects the total system design. You can’t analyze thermal management independent of power system design. The two are coupled through solar panel thermal behavior.

The debris impact wildcard

Radiators are the largest exposed surfaces on an orbital compute platform. They’re also vulnerable to micrometeorite and debris impact.

A penetrating impact on a liquid cooling loop is potentially mission-ending-you lose coolant, thermal management fails, electronics overheat. Redundancy helps but adds mass and complexity.

When we model long-duration missions (5+ years), the cumulative probability of a damaging radiator impact becomes non-trivial. For a 200m² radiator in LEO, we estimate 5-15% probability of a penetrating impact over a 5-year mission, depending on orbital altitude and solar cycle phase.

This has design implications. Robust thermal designs for orbital data centers probably need:

  • Segmented cooling loops that can isolate damaged sections
  • Self-sealing loop architectures
  • Excess thermal margin to operate with degraded radiator area

These features add mass, cost, and complexity. They’re not part of most conceptual designs we’ve seen, which treat thermal management as a solved problem. Thermal survivability over multi-year missions is not solved.

What the simulation tells you

Our thermal simulator models all of these effects: orbital geometry, eclipse cycling, Earth albedo variation, radiator orientation, internal heat generation, solar panel coupling, and transient behavior.

The output isn’t just “your radiator needs to be X m²”. It’s a time-series of temperatures throughout the system, identification of hot spots and cold spots, eclipse transient behavior, and sensitivity analysis to design parameters.

What users typically find: their initial designs either underestimate eclipse transients, underestimate heat transport limitations, or underestimate the solar panel thermal coupling. The “obvious” design usually isn’t optimal.

The simulator has also revealed general design principles that aren’t in the standard literature:

  1. Radiator sizing should target eclipse conditions, not sunlight conditions-you have excess capacity during eclipse that you need to manage
  2. Heat transport architecture matters as much as radiator area-distributed vs. concentrated thermal design is a key trade
  3. Active thermal control is mandatory, not optional-passive designs can’t handle the eclipse transients
  4. Radiator orientation drives overall spacecraft design more than most teams expect

These insights came from simulation, not intuition. Thermal design for orbital compute is different enough from traditional spacecraft thermal design that experience doesn’t always transfer.

The bottom line

Space-based data centers will have lower cooling costs than terrestrial facilities. That part of the pitch is true.

But “lower cost” doesn’t mean “simple.” Thermal management in vacuum has its own complexities-eclipse transients, orientation constraints, heat transport limitations, debris vulnerability. Systems that ignore these complexities will fail.

The teams we’ve worked with who model thermal behavior rigorously end up with better designs-more robust, more mass-efficient, more likely to survive long-duration missions. The teams who hand-wave thermal as “solved” end up with problems.

If you’re working on orbital compute thermal design, we’d like to show you what our simulations reveal for your specific architecture.

The RotaStellar thermal simulator is part of the Orbital Compute Suite. Request a demo to see what it shows for your design.