Can a 100 MW data centre operate safely in low Earth orbit?

The decision this evidence supports

Proceed with design studies and a 0.1–1 MW demonstrator; defer a full 100 MW deployment. For an Earth-serving data centre, investigate independently powered and removable modules in roughly 450–650 km orbits. That is a study range, not a selected or approved orbit.

A single platform concentrates failure consequences: a punctured common cooling loop, loss of attitude control or failed disposal system could strand thousands of tonnes. Modules can limit the amount of computing lost in one incident, although they do not automatically reduce the total exposed area or aggregate impact count.

Reference case throughout: 100 MW of IT equipment, an assumed 10 MW of supporting electrical load, five years of operation, and continuous computing through eclipses. These are explicit assumptions, not requirements supplied by an operator.

Orbit choice changes the problem

Satellites continually move through shared space. Different orbital planes can cross, and an object whose average altitude lies elsewhere may still pass through the chosen band. Separation, tracking accuracy, manoeuvre coordination and debris lifetime determine whether an orbit remains usable. ESA’s 2026 environment report describes continuing pressure on this shared environment; its underlying population data run to the end of 2025. ESA report.

As a current occupancy check, I downloaded CelesTrak’s active-satellite catalogue on 2 November 2026 and derived approximate mean altitudes from the published orbital elements. The snapshot contains 16,847 records. These counts describe active satellites, not all debris or collision exposure. Catalogue endpoint · Element format.

The low active count near 850 km is not a safety recommendation. This table omits inactive spacecraft, rocket bodies and fragments. Higher altitude also weakens atmospheric removal. Nearby inclinations are not the only objects that can intersect a facility’s path.

The practical trade is between stronger drag and reboost demand at lower altitudes, and longer debris persistence at higher altitudes. Large panels make atmospheric density and attitude especially important. Density varies with solar and geomagnetic activity; it is not a constant determined by altitude alone. NOAA on satellite drag.

A dawn–dusk orbit still needs an eclipse allowance

A near-polar, Sun-synchronous orbit can keep solar arrays well illuminated, but continuous sunlight cannot simply be assumed at these altitudes. The tilt of Earth’s axis creates seasonal eclipse conditions. This is also recognised in published solar-observatory orbit studies. Solar-C mission study.

Own first-order calculation: circular orbit, ideal nodal precession, cylindrical Earth shadow and seasonal solar declination. It needs full-year numerical propagation before equipment is sized. Moving higher solely to avoid eclipses would introduce other disadvantages.

The power and cooling system dominates the structure

At 550 km, a 21.7-minute eclipse consumes about 39.7 MWh at a 110 MW total load. Assuming 80% usable battery depth and 95% discharge efficiency, battery packs at 150–200 Wh/kg weigh approximately 260–350 tonnes, before ageing reserve, shielding and replacement capacity.

Generating power for the load and recharging during sunlight requires about 146 MW in the worst eclipse season under the stated charging assumption. Allowing a 20% output derating gives approximately 182 MW of beginning-of-life array rating. At 30% conversion efficiency and 1,361 W/m² sunlight, that is 446,000 m² of active solar surface. Deployment structure, inter-panel gaps, shadowing and orientation require further design allowance.

Published Redwire ROSA configurations illustrate that complete array mass is substantial. Using an illustrative 80–125 W/kg range gives roughly 1,500–2,300 tonnes for the array system. This extrapolates far beyond the cited products; it is not a quotation or evidence that a 182 MW array can be built at that mass. ROSA specifications.

Radiator area is not the same as collision area

Vacuum removes the possibility of rejecting heat into surrounding air. Coolant must carry heat to surfaces that radiate it away, while those surfaces also absorb energy from the Sun, Earth and other spacecraft surfaces. NASA thermal-control overview.

The table assumes emissivity 0.9, an illustrative average absorbed external heat load of 100 W/m², and a 20% area margin. That environmental assumption is a sensitivity case, not a calculated Earth-view or sunlight model.

At 60°C, 250,000 m² means total emitting surface. If both faces work equally well, physical radiator panel area could be around 125,000 m². If only one face is effective, it is closer to 250,000 m². Neither assumption is guaranteed in a real layout. The chips and coolant must also operate above the radiator temperature with adequate temperature differences through the cooling circuit.

Solar panels plus radiators therefore occupy about 0.57–0.70 km² of physical panel area in this reference case, excluding trusses and clearances. Directional impact cross-section is a separate quantity: it depends on where particles come from and how the panels are oriented.

Revising the launch estimate

The IT analogy uses roughly 120 kW per rack and a representative 1,553 kg rack. The radiator coefficient comes from one NASA system mass model and is not a universal radiator specification. These sources provide scale, not a design validation. NVIDIA rack power · Aivres rack specification · NASA radiator mass model, table 4-20.

Using hypothetical delivered payloads, this corresponds to approximately 50–80 launches at 100 tonnes per flight, or 35–55 at 150 tonnes. Both are mass-division scenarios, not predictions of available Starship performance to this orbit. Packaging, assembly, propulsion delivery, spares and replacements could add flights. The earlier 40–60-flight estimate should therefore be treated as an optimistic preliminary illustration, not an upper bound.

Large exposed area makes impact tolerance essential

There are two different tasks: predicting close approaches to tracked objects, and surviving impacts from particles too small to manoeuvre around reliably. A good traffic-management service addresses the first. Segmented cooling loops, shielding, isolation valves and redundancy address consequences of the second.

NASA’s ORDEM and ESA’s MASTER provide debris-environment modelling methods. A design also needs a meteoroid environment model and current inputs appropriate to the mission. No ORDEM, MASTER or meteoroid simulation was run for this assessment. Active-satellite counts cannot substitute for them. NASA ORDEM · ESA modelling overview.

The following deliberately hypothetical calculation shows why the missing flux matters. Assume an effective exposed area of 250,000 m² for a specified particle population and a five-year mission. With a constant Poisson flux, expected impacts are λ = flux × area × time, and the probability of at least one is 1 − exp(−λ).

An impact is not equivalent to losing the facility. A particle might damage one cell, puncture a cooling channel or hit a critical bus; size, speed, angle and protection change the outcome. The area and flux conventions must match. One cannot multiply a directional model’s output by an unrelated radiator emitting area.

For tracked conjunctions, NASA’s civil-spacecraft process treats collision probability above 10⁻⁴ as a mitigation threshold. This is a useful operational reference, not a universal licensing rule or an acceptable annual loss probability. A very large flexible structure needs geometry-aware assessment, accurate trajectories and timely coordination. NASA conjunction risk assessment.

Manoeuvring is possible; dependable removal is harder

Mass alone does not make collision avoidance impossible. For a 5,000-tonne facility, an illustrative 0.1 m/s velocity change takes about 14 hours at 10 N thrust, 83 minutes at 100 N, or eight minutes at 1,000 N. These are impulse calculations, not proof of adequate avoidance capability. Warning time, thrust direction, flexible structures, attitude constraints and secondary conjunctions determine whether a manoeuvre works.

Drag is also sensitive to assumptions. For 100,000 m² of projected drag area, drag coefficient 2.2 and a 5,000-tonne mass at 550 km orbital speed, constant atmospheric densities of 10⁻¹³, 10⁻¹² and 10⁻¹¹ kg/m³ imply approximately 4, 40 and 400 m/s of annual reboost. Those densities are sensitivity cases, not annual forecasts for that altitude. A time-varying atmospheric model is required.

End of life must be designed into every module

An idealised impulsive burn lowering perigee from a 550 km circular orbit to 80 km needs about 134 m/s. At a chemical-propulsion specific impulse of 300 seconds, a 5,000-tonne initial mass would consume about 223 tonnes of propellant. This is only an orbital-energy calculation: it does not establish controlled entry, break-up behaviour or acceptable ground risk.

A large facility cannot rely on the assurance that it will eventually fall back. Each removable module needs a disposal path that survives credible failures, sufficient energy and propulsion reserves, and a means of external capture if its own systems fail. Planned controlled entry must account for the survival of dense equipment and hazardous materials.

For relevant US authorisations, the FCC’s five-year rule concerns qualifying spacecraft using uncontrolled atmospheric re-entry after mission end; it is not a general permission to abandon any LEO structure for five years. Applicable licensing and re-entry requirements need mission-specific review. NASA also publishes orbital-debris mitigation requirements for its missions. FCC rule · NASA debris standard.

A development path that can earn a larger deployment

My engineering recommendation is a 0.1–1 MW demonstrator with independent power, cooling, communications and disposal. Measure useful computing delivered over a full seasonal cycle, including eclipses and reduced-power recovery. Validate cooling-loop isolation, array behaviour, radiation-induced errors and remote repair assumptions.

At simple proportional scaling, a 1 MW module would still represent roughly 50–80 tonnes and 5,700–7,000 m² of panels. Smaller systems may have worse mass efficiency because essential hardware does not scale down linearly. A hundred modules would also create a hundred spacecraft to coordinate and retire.

Independent batch processing and inference are plausible early workloads. A tightly coupled training cluster demands a different case: inter-module bandwidth, latency, pointing, redundancy and communication energy may make distributing the hardware unattractive. No communications architecture or commercial service-level agreement has been demonstrated by this assessment.

The Moon offers a stable site without the same continuous orbital traffic-management burden. It still needs heat rejection, dependable power, landed hardware and maintenance. This assessment therefore does not establish that a lunar data centre is the better investment. The strongest supported next decision is to test a small orbital system before committing to either large space-based architecture.

Calculation notes and limits

All numerical design results above are calculations for this assessment, rounded to avoid implying precision beyond the assumptions. Source documents establish methods and representative hardware values; they do not endorse this proposed facility.

Prepared for Kenn Jordan. Evidence and assumptions dated 2 November 2026. No debris-flux simulation, conjunction campaign, detailed spacecraft design, operator quotation or launch booking was performed.

{
  "url": "https://guides.elmspark.com/orbital-data-centre-assessment/",
  "checked_at": "2026-11-02T22:20:00.891Z",
  "views": [
    {
      "width": 1440,
      "http_status": 200,
      "h1": "Can a 100 MW data centre operate safely in low Earth orbit?",
      "bodyWidth": 1440,
      "sections": 7,
      "brokenImages": 0,
      "placeholderCount": 0
    },
    {
      "width": 1024,
      "http_status": 200,
      "h1": "Can a 100 MW data centre operate safely in low Earth orbit?",
      "bodyWidth": 1024,
      "sections": 7,
      "brokenImages": 0,
      "placeholderCount": 0
    },
    {
      "width": 390,
      "http_status": 200,
      "h1": "Can a 100 MW data centre operate safely in low Earth orbit?",
      "bodyWidth": 390,
      "sections": 7,
      "brokenImages": 0,
      "placeholderCount": 0
    }
  ],
  "index": {
    "http_status": 200,
    "assessmentCards": 1,
    "totalCards": 338
  },
  "nojs": {
    "sections": 7,
    "verdictVisible": true
  },
  "console_errors": []
}

{
  "url": "https://elmspark.com/orbital-data-centre-assessment/",
  "checked_at": "2026-11-02T22:20:01.832Z",
  "accessibility": 100,
  "failures": []
}

DELIVERABLE GATE: PASS
All substantial content renders without JavaScript (0 candidate strings checked, 0 JS-only).