COMPUTE IN ORBIT
sovereignagentics.io

Orbital Data Center Planner

Plan a data center in orbit: size the GPU fleet, the solar array to power it, the radiators to cool it, the radiation shielding, launch mass, and the real cost per GPU-hour and latency to the ground.
🛰️ Solar Station

About the Orbital Data Center Planner

Putting AI compute in orbit is increasingly discussed because space offers near-continuous sunlight and no land or water constraints — but it comes with hard limits: you must reject every watt of heat with radiators, shield electronics from radiation, and accept latency to the ground. This planner turns those constraints into concrete numbers.

Enter a target compute load and an orbit, and it sizes the GPU fleet, the solar array, the radiators, the shielding, the launch mass, and the true cost per GPU-hour — the figures that decide whether an orbital data center makes sense.

How to use it

  1. Set your target IT (compute) load in megawatts.
  2. Choose an orbit — this sets sunlight availability and latency to the ground.
  3. Set GPU power draw, array efficiency, and a radiation-hardening mass overhead.
  4. Set launch and hardware costs.
  5. Read GPUs supported, array size, radiator area, masses, Starship flights, PUE-equivalent, capex, latency, and cost per GPU-hour.

How it works

The planner converts your IT load into a GPU count, then sizes the solar array to sustain that load given the orbit's sunlight fraction. Almost all compute power becomes heat, so it sizes radiators to reject that heat at roughly 300 K — the thermal wall that dominates orbital compute far more than power does on the ground.

It adds radiation-shielding mass as an overhead on the compute hardware, sums compute, shielding, array, and radiator mass into a launch manifest, and derives capex from launch plus hardware. Latency is set by orbit — a few milliseconds from low orbit up to about 119 ms one-way from geostationary — which decides what workloads are even viable. The result is a clear picture of the cost per GPU-hour and the mass you must lift.

Worked example

A 100 MW orbital data center in geostationary orbit supports a large GPU fleet on near-continuous solar, but needs radiators covering a fraction of a square kilometre and hundreds of tonnes to orbit — so its cost per GPU-hour is driven almost entirely by launch. Switch to low orbit and latency drops to a few milliseconds but sunlight falls and radiation rises, illustrating the core orbital trade.

Frequently asked questions

Why run a data center in orbit?

Near-continuous sunlight and no land, water, or grid constraints — at the cost of heat rejection, radiation, and latency, all of which this tool sizes.

What's the biggest constraint?

Thermal rejection. Every watt of compute becomes heat that only radiators can remove in vacuum, and radiator area grows quickly with load.

How does orbit affect latency?

Low orbit is a few milliseconds to the ground; geostationary is about 119 ms one-way, which rules out latency-sensitive workloads.

Why does radiation matter?

Electronics need shielding that adds mass; the tool lets you set that overhead and see its cost impact.

Are the numbers engineering-grade?

No — it's a transparent first-order model with adjustable public assumptions, for planning and education.

Is it free and multilingual?

Yes — free, browser-based, and available in 25 languages.

Related tools