Every nation's most sensitive compute workloads — tax records, intelligence fusion, genomic databases, central-bank ledgers — sit on ground infrastructure subject to physical seizure, legal compulsion under foreign jurisdiction, or catastrophic single-site failure. Moving that infrastructure to orbit places it beyond the reach of bailiff orders, foreign subpoenas and even kinetic attack on national territory. The concept is not science fiction: Microsoft's Project Natick demonstrated sealed, pressure-tolerant server modules operating for two years in a hostile environment, and the thermal and power budgets of a large ESPA-class satellite bus already match a modest blade-server rack.
The satellite stack for an orbital data centre is a synthesis of capabilities maturing in parallel: high-efficiency photovoltaic arrays delivering multi-kilowatt payload power, radiation-hardened or radiation-tolerant COTS server blades, inter-satellite optical links at 10–100 Gbps for low-latency data replication between nodes, and active thermal radiators replacing the cooling towers that make ground data centres so energy-hungry. A constellation of six to twelve such platforms in MEO or high-LEO can maintain continuous mutual visibility, giving a synchronous distributed file system with no single point of failure and sub-100 ms replication lag globally.
The operational outcome is a sovereign compute enclave that no foreign court, no occupying force and no undersea cable cut can reach. For a nation facing geopolitical pressure, this is continuity-of-government infrastructure at its most resilient: the finance ministry can still process payments, the intelligence directorate can still run inference, and the head of state can still sign digital instruments of state — even if every data centre on the national territory is dark.
Frequently asked
Why would a nation bother putting a data centre in orbit instead of building a hardened ground facility?
A ground facility, however fortified, sits within a physical jurisdiction that can be raided, sanctioned, or coerced. An orbital data centre operates in a regime where physical interdiction is technically and legally far harder, and where a sovereign state retains exclusive operational control. For data classified at the highest sensitivity — cryptographic key material, intelligence-fusion outputs, strategic military planning — the jurisdictional isolation of orbit is a genuine security premium, not a novelty.
Doesn't the radiation environment make running modern AI chips in space completely impractical?
It makes it harder, not impossible. Techniques such as triple-modular redundancy, scrubbing memory on sub-second cycles, and selecting process nodes less susceptible to single-event upsets can extend COTS chip lifetimes to 3–5 years in LEO. ESA's Φ-lab demonstrated 68 TOPS per kg on the iX5-100 platform in 2023. Performance will remain 5–10× behind contemporaneous terrestrial accelerators for the foreseeable future, but that gap narrows every generation.
How does the orbital compute system stay connected to ground users without introducing unacceptable latency?
LEO orbital altitudes (400–1200 km) produce raw propagation latencies of 6–12 ms round-trip — comparable to a well-peered terrestrial cross-continental link. Optical inter-satellite links allow jobs to be routed across a constellation and results downlinked from the satellite nearest to the requesting ground station, keeping effective latency competitive with terrestrial cloud for most batch and near-real-time workloads. Synchronous interactive workloads below 5 ms remain the one class of application that is unsuitable.
What sovereign use cases actually justify the cost premium over renting AWS GovCloud or an equivalent?
Three categories dominate: (1) intelligence and defence processing where no foreign-jurisdiction cloud is legally or politically acceptable; (2) national AI training runs that a government wants to keep off foreign servers for competitive reasons; and (3) processing Earth-observation data in orbit before downlinking, so that raw imagery of sensitive national infrastructure never touches a foreign ground station. The cost premium shrinks as launch costs fall and as the political cost of cloud-dependency rises.
Is there an international legal framework for orbital data centres yet?
No. The Outer Space Treaty of 1967 establishes that launching states retain jurisdiction over their objects, which provides a baseline, but it says nothing about data sovereignty, uptime obligations, or liability for compute failures. ITU-R coordinates spectrum and orbital slots but does not govern compute services. Nations operating early orbital data centres will be writing the de facto legal norms, which is both a risk and a first-mover opportunity to shape the eventual framework through UN-OOSA working groups.
What orbit is best for an orbital data centre — LEO, MEO, or GEO?
LEO (500–1200 km) is the default for latency and launch-cost reasons. A constellation of 12–30 satellites in multiple orbital planes can provide near-continuous coverage of a nation's territory. MEO (8 000–20 000 km) trades latency for longer dwell times per pass, which suits archival or batch-compute workloads. GEO adds 240 ms latency and is generally unsuitable for interactive compute; it is only warranted where a single persistent contact over a large region is the overriding requirement.
How many satellites would a viable sovereign orbital data centre constellation actually need?
A minimum viable architecture for continuous national coverage (territory up to ~3 M km²) requires roughly 12–18 satellites in three orbital planes. Each node would carry a compute module equivalent to a ruggedised 1U server today, scaling to a rack equivalent within the decade as satellite buses grow. A full operational system with redundancy and dedicated inter-satellite mesh would realistically be 24–36 satellites, consistent with the scale of national EO constellations already being built by France (CSO), Germany (SARah), and Japan (IGS).
How do you handle software updates and security patching for compute hardware that you cannot physically access?
All updates must be delivered over the command uplink, cryptographically signed, and validated against a hardware root of trust before execution — the same model used for secure firmware updates in HSMs and military avionics. CCSDS 727.0-B-5 (CFDP) provides the reliable file-transfer layer. The critical additional requirement is a hardware-enforced rollback mechanism so that a failed patch does not brick an unreachable node; this is standard practice in modern spacecraft flight software but must be explicitly specified in procurement.