SpaceX filed for a million-satellite orbital data centre constellation, Starcloud hit a $1.1 billion valuation in March 2026, and eight organisations committed major orbital data centre funding in the first 90 days of 2026 alone. That is a lot of money moving in one direction. But investment activity is not the same as procurement readiness.
For most mid-market companies in 2026, these belong on a watch list — not an infrastructure roadmap. This article explains why, and what conditions would change that. If you want the full landscape first, the computing beyond the grid primer is a good place to start.
ABI Research puts orbital compute at roughly 78 times the cost per unit of a terrestrial equivalent. They flag it as a rough estimate. But even if you discount it aggressively, you are not landing at 2x or 3x — where early adopters might take a punt. You are at an order of magnitude that rules out cost-motivated adoption for any mid-market company this year.
Yes — for most mid-market companies in 2026, orbital and underwater compute belongs on the watch list, not an active infrastructure roadmap. The ABI Research 78x TCO premium is the number that anchors that decision.
Underwater data centres are further along than orbital. China’s Hainan facility has been operational since 2025 — 24 racks at 35 metres depth, with a PUE of 1.07 using natural seawater cooling. Microsoft’s Project Natick showed lower hardware failure rates for sealed subsea deployments than terrestrial equivalents. Both required hyperscaler-scale capital. Neither is a mid-market procurement option today.
The planning horizon to watch is ABI Research’s 2035 forecast, where orbital compute $/W reaches convergence with terrestrial benchmarks. The trigger conditions are not yet met. Monitor with discipline, allocate no budget in 2026, and establish the criteria that would actually change the assessment.
Five conditions, met together, would move orbital compute from background monitoring to active planning consideration. No single one is enough on its own.
1. Starship commercial flight cadence reaching approximately 12 launches per year Not yet at commercial frequency. You can track this through FAA launch licences and SpaceX manifests. Starcloud CEO Philip Johnston expects commercial Starship access in 2028–2029.
2. Launch cost approaching $200/kg Not yet demonstrated. It is Starship-dependent — best-case Falcon Heavy sits at roughly $1,500/kg as of mid-2026.
3. A published SOC 2 or equivalent compliance framework for orbital workloads No framework exists. No orbital provider has undergone a SOC 2 audit for space-based workloads.
4. Commercially available ODC capacity from non-BHDT vendors Limited. The closest evaluable product today is Atomic-6’s ODC.space marketplace — a sovereign 42U rack at $3.5M per month with 2–3 year delivery. That means 2028–2029, not 2026.
5. At least one verifiable enterprise deployment at scale None as of 2026.
The next concrete evidence events to watch: Lonestar StarVault’s October 2026 launch, NVIDIA Space-1 confirmed for 2027, and the FCC ruling on SpaceX’s million-satellite application SAT-LOA-20260108-00016. For more on the SpaceX FCC filing and S-1 risk disclosures, and what Axiom Space’s commercial orbital nodes actually look like in practice today, we have articles covering both.
The viable candidates in 2026 are non-critical, latency-tolerant, compute-heavy workloads. Real-time transactional workloads, regulated-data processing, and AI training runs are not viable. Full stop.
Rishi Gupta of Infosys puts the starting point well: identify non-critical workloads. LEO introduces 20–40ms roundtrip latency. Any workload where sub-10ms latency is baked into the architecture is unsuitable.
Here is the workload split:
Viable today (2026)
Viable in the 2030s
The AI inference versus training distinction is the one that matters most for your planning. Inference requests are independent and parallelisable, which makes kW-scale LEO edge nodes viable today. Training requires tightly coupled multi-GPU systems with high-bandwidth interconnects — infrastructure that does not exist in orbit in 2026. For the thermal constraints that define workload viability, see the physics of orbital and underwater cooling and the NVIDIA Space-1 hardware roadmap.
No SOC 2, GDPR, HIPAA, or FedRAMP framework currently applies to data processed in orbital environments. For FinTech, HealthTech, and regulated SaaS companies, that makes orbital data processing non-compliant by default.
Here is where each framework stands:
SOC 2: designed for cloud providers in defined geographic jurisdictions with physical access controls — none of those assumptions hold in orbit. No orbital provider has undergone a SOC 2 audit for space-based workloads.
GDPR: Chapter V assumes data crosses between jurisdictions with defined adequacy frameworks. Orbital processing sits in a legal grey zone with no published adequacy determination.
HIPAA: no published Business Associate Agreement template exists for orbital healthcare data processing.
FedRAMP: requires authorised providers on US soil or in documented overseas environments. Orbital is excluded.
The underlying question — which jurisdiction governs data processed in orbit? — is unresolved. The operator’s incorporation, the satellite’s flag state, the ground station jurisdiction, and your data residency requirements may all apply and conflict with each other.
ITAR is worth noting too: US-manufactured satellites and hardware are typically ITAR-controlled, creating potential obligations for non-US customers on US-domiciled orbital providers. For a broader view of the alternative computing landscape — including the underwater and orbital environments where these compliance gaps apply — the computing beyond the grid overview maps the full scope.
Most orbital compute providers have no track record of operating commercial data services — no SLA history, no uptime data, no established escalation paths. That is categorically different from procuring from a hyperscaler.
Starcloud raised $170 million at $1.1 billion valuation — Y Combinator’s fastest unicorn — with AWS, Google Cloud, NVIDIA, and Crusoe delivering hardware for Starcloud-2. A meaningful credibility signal. But not revenue.
SpaceX’s S-1 uses the language “significant technical complexity and unproven technologies, and may not achieve commercial viability”. That is three months after Musk called orbital data centres a “no-brainer” at Davos. The S-1 is the legally binding document. Keep that in mind.
Atomic-6 at $3.5M per month with 2–3 year delivery is procurement for 2028–2029. Lonestar StarVault (October 2026) is a storage service, not a compute platform. Hardware obsolescence compounds the risk: GPUs depreciate every 2–3 years, but in orbit every replacement requires a launch or a robotic servicing mission.
Six publicly observable signals, reviewed quarterly, turn passive awareness into structured monitoring.
Starship commercial flight rate via FAA launch licences and SpaceX manifests. Watch for a sustained cadence of 12 or more commercial launches per year.
NVIDIA Space-1 Vera Rubin Module (2027) — the first space-hardened GPU from a Tier 1 vendor. Its availability validates the AI inference thesis.
Lonestar StarVault October 2026 launch — the first concrete evidence event. If it operates for 90+ days, the “first commercial orbital data service” claim becomes verifiable. If it slips, reset your timeline expectations.
Starcloud-2 late 2026 launch — the first satellite to run commercial cloud workloads for Crusoe, AWS, and Google. Hardware is being delivered to the Redmond integration facility now.
FCC ruling on SAT-LOA-20260108-00016 — approval or denial signals whether the FCC will licence large-scale orbital data centre constellations. More than 1,000 public submissions have been received, the majority opposed.
Any published compliance framework for orbital workloads from CSA, CISA, or ENISA. Its emergence would be a step-change signal for regulated industries.
Monitoring setup: Google Alerts for “orbital data centre,” “space compute,” “Starcloud,” “Lonestar StarVault”; FCC IBFS for SAT-LOA-20260108-00016 docket activity; Atomic-6 ODC.space for delivery updates. The energy economics trajectory and ABI Research 2035 convergence forecast has the cost curve context for all of these.
Once you have the watch-list in place and the threshold conditions clear, the board question is easy to handle. It usually arrives triggered by a news cycle. The structure of the answer is the same every time.
SpaceX’s S-1 simultaneously promotes and disclaims orbital data centres — it is a credible growth story for a $1.75 trillion pre-IPO valuation, sitting alongside “significant technical complexity and unproven technologies” in the same document. Google Project Suncatcher is a research initiative, not a commercial product. Neither is a procurement option.
Hyperscalers have the capital to participate as early adopters. Mid-market companies do not need to — the adoption curve works in their favour if they monitor the right signals and move when threshold conditions are met.
Board-ready summary: “The 78x cost differential established by ABI Research rules out cost-motivated adoption today. The convergence forecast is 2035, contingent on Starship economics not yet demonstrated. No compliance framework exists for orbital workloads — a hard blocker for our regulated data. We have a watch-list of six trackable signals reviewed quarterly. We will revisit when [specific threshold condition].”
The more immediate planning pressure for most mid-market companies is not space infrastructure — it is terrestrial capacity constraints. Grid interconnection queues in North American and European hubs now average seven to ten years, with seven of 13 major US grid regions projected below critical safety margins by 2030. That is the near-term infrastructure risk that deserves budget attention now. For geopolitical context and underwater commercial evidence, the China underwater data centres analysis covers both Project Natick and China’s deployments.
For a complete overview of orbital, underwater, and alternative data centre environments — and how all the pieces fit together — see the full scope of orbital and underwater data centres.
ABI Research explicitly describes the 78x figure as a “rough estimate” — treat it as an order-of-magnitude indicator, not a precise ratio. Its value is in confirming that we are not at 2x–3x, where early adopters might experiment. We are at an order of magnitude that rules out cost-motivated adoption for mid-market companies in 2026.
Orbital compute is a subset of edge compute architectures, but the physical constraints — launch cost, radiation hardening, vacuum cooling, limited repair access — make it categorically different from terrestrial edge. ABI Research’s kW-scale versus MW-scale taxonomy is the useful distinction: today’s orbital nodes operate at kW-scale edge capacity; terrestrial edge data centres routinely operate at MW scale.
Atomic-6’s ODC.space introduced this distinction: sovereign capacity means owning an entire dedicated satellite ($3.5M per month, 2–3 year delivery); colocated capacity means renting shared capacity on a multi-tenant satellite at lower cost. Neither is practical for mid-market companies in 2026. The colocated model, if it matures, would be the more accessible entry point for non-hyperscale buyers.
GDPR, HIPAA, and data residency laws all assume data is processed in a geographic jurisdiction with defined legal obligations. Orbital processing sits outside any jurisdiction’s clear remit. For regulated industries, there is no legal basis for claiming compliance with frameworks your customers or auditors expect. Orbital data processing is non-compliant by default until a specific certification framework is published and audited.
Lonestar StarVault, launching October 2026 aboard LizzieSat-4, is the first commercially purchasable non-BHDT orbital data service — a storage service, not a compute platform. Starcloud-2 (late 2026) would be the first commercial orbital compute offering, but enterprise availability is likely 2027–2028 at the earliest.
AI inference is viable at LEO edge scale because each request is independent and parallelisable. AI training requires tightly coupled multi-GPU systems with high-bandwidth interconnects — infrastructure that does not exist in orbit in 2026. Edge inference is a candidate workload today. Training runs in orbit are a 2030s proposition.
Google Project Suncatcher is a Google Research initiative equipping satellites with Tensor Processing Units, targeting a two-satellite learning mission with Planet Labs by early 2027. It is not a commercial product. Its significance is that Google Research projects cost parity by approximately 2035 — the same convergence horizon ABI Research forecasts.
Starcloud-2 is scheduled for launch before year-end 2026, using AWS Outposts hardware alongside NVIDIA, Google, and Crusoe. It generates about 8 kilowatts — 100 times more than Starcloud-1. Philip Johnston’s 2028–2029 estimate for earliest viable commercial orbital compute is based on Starcloud-2 delivering and Starship reaching sufficient launch cadence.
Both use unconventional cooling, are physically inaccessible once deployed, and are in earlier commercial maturity than hyperscaler cloud regions. China’s Hainan facility — operational since 2025, 35 metres below the surface, PUE of 1.07 — proves the technology works at commercial scale. China’s deployments are not directly accessible to Western mid-market companies, but the technology proof is real.
For most mid-market companies in 2026, no. The 78x cost differential, compliance gap, pre-revenue vendor landscape, and Starship-dependent timeline all point to 2030 at the earliest as realistic. Set up a structured watch-list with an annual review cadence instead. The conversation that deserves active budget attention now is grid interconnection queue risk: the average wait time for a new large-scale grid connection in North American and European hubs is now seven to ten years.
ITAR restricts transfer of defence-related technology; US-manufactured satellites and hardware are typically ITAR-controlled. Non-US companies using US-domiciled orbital infrastructure — Atomic-6, Starcloud, and Lonestar are all US-based — may face ITAR obligations depending on their workloads. Get legal advice on ITAR exposure before any LOI or commercial agreement with US orbital providers.
The Physics of Alternative Data Centre Cooling — Orbital Vacuum and Ocean ThermalSpace sits at 2.7 K — a few degrees above absolute zero. And cooling is still the hardest engineering problem facing orbital data centres. Understanding why tells you most of what you need to know about alternative compute environments.
This is a technical comparison of thermal management across three environments: traditional terrestrial, orbital vacuum, and underwater ocean thermal. Real PUE numbers, specific facility data, and physics that doesn’t bend for vendor narratives. It connects to the broader case for computing beyond the terrestrial grid.
Cooling eats roughly 40% of total energy in a traditional data centre. That’s the economic motivation behind every alternative-environment deployment being discussed right now.
PUE — Power Usage Effectiveness — is the ratio of total facility power to IT equipment power. A PUE of 1.54 means 54 cents of overhead for every dollar spent on compute. Theoretical minimum is 1.0. The Uptime Institute’s 15th Annual Global Data Center Survey found the global average stuck at 1.54 for the sixth consecutive year. That’s not a great scorecard.
The problem gets worse as GPU power density climbs. NVIDIA GB200 NVL72 racks draw up to 120 kW per rack. Air cooling simply can’t manage that at full utilisation. Vertiv reported liquid cooling revenue more than doubled in Q1 2025, with 40% CAGR projected through 2028. Lawrence Berkeley National Laboratory projects US data centre energy consumption reaching 325–580 TWh annually by 2028, up from 176 TWh in 2023. The cooling overhead scales at the same rate. The rest of this article tests whether alternative environments can change that equation.
Earth gives you three mechanisms for moving heat: conduction, convection, and radiation. Traditional data centres rely almost entirely on conduction and convection — and both require a fluid medium, which on Earth you have in abundance.
Traditional HVAC-cooled facilities average PUE 1.54. Co-location and enterprise often run 1.58–1.80. Hyperscalers do better. Google, Meta, Microsoft, and Amazon achieve PUE 1.10–1.15 through purpose-built infrastructure combined with free cooling — using ambient environmental temperature rather than mechanical refrigeration. Google reported 1.09 in 2025. Free cooling is the key lever, and geography determines whether it’s available: cold ambient air in northern Europe, cold seawater near coastlines.
Even the best hyperscalers run into an engineering floor around 1.05–1.10. Power conversion losses can’t be eliminated. To beat hyperscaler-class efficiency, an alternative environment needs to achieve PUE measurably below 1.10. That’s the bar.
Vacuum is a thermal insulator. That’s the whole answer — but it needs unpacking.
On Earth, heat moves via conduction and convection. Both require a medium. Vacuum eliminates both. The 2.7 K cosmic microwave background is extraordinarily cold, but there’s nothing to carry heat from your server to that background. Temperature and cooling capacity are not the same property in a vacuum. This is where most people’s intuition about space being “cold” falls apart.
The only mechanism available in orbit is thermal radiation: every object above absolute zero emits infrared energy. The rate is governed by the Stefan-Boltzmann Law — radiated power per unit area scales as the fourth power of absolute temperature (P = εσT⁴, where σ = 5.67 × 10⁻⁸ W·m⁻²·K⁻⁴). Double an object’s temperature in Kelvin and it radiates 16 times more heat. Radiator temperature, not just surface area, is what determines how fast heat actually leaves.
At 20°C, a radiator panel with emissivity 0.9 emits roughly 633 W per square metre. To radiate 1 MW, you need approximately 1,200 m² of surface — the area of four tennis courts. And that’s for just 1 MW. Raising operating temperature is the more powerful lever than better surface coatings alone.
For the solar energy side of the orbital energy budget, see the orbital solar energy cost equation.
This is where physics translates into engineering constraints you can actually cost out.
ABI Research figures put each NVIDIA H100 GPU at approximately 1.1 m² of required radiator area in orbit. A full DGX H100 system — eight H100s plus support hardware — needs approximately 16 m² of radiators. That’s the size of a large living room, for a single server unit.
At rack scale, a standard 42U rack running H100-class hardware at full load could require 50–100 m² of radiator panel. Per rack. Per satellite. Radiator panels weigh 5–9 kg per square metre, so the mass implications build fast.
Heat moves from processor to radiator fin via heat pipes — sealed tubes using a working fluid’s phase change. No moving parts, no pumps, individual failures don’t cascade. That’s the standard approach in all current orbital designs: Starcloud, Axiom Space’s ISS nodes, Sophia Space. For the operational cooling reality in current ISS deployments, the Axiom Space article details how these constraints play out in practice.
Starcloud-2 will carry what Starcloud CEO Chris Johnston describes as “the largest deployable radiator flown on a private satellite.” Deployable means stored compactly during launch and mechanically extended in orbit — necessary because Stefan-Boltzmann demands large surface areas and launch volume is finite. It’s an elegant engineering problem with expensive answers.
The governing framework is SWaP — Size, Weight, and Power. Spacecraft engineering treats all three as a single unified budget. The cooling radiator consumes the largest share of all three. Launch costs to LEO run 1, 000–5,000 per kg, so radiator mass directly multiplies total system cost.
Two-phase fluid loops and space-rated heat pumps are under development for megawatt-class cooling, expected operational around 2027. Not available yet. For NVIDIA’s Space-1 thermal specifications, see NVIDIA’s Vera Rubin Space-1 module.
The underwater case runs on a completely different set of physics.
In an underwater data centre, servers operate in a sealed pressure vessel surrounded by seawater. Waste heat conducts through the vessel wall to the ambient ocean — no mechanical chillers, no pumps, no HVAC. The ocean does the work.
The BHDT (Beijing Highlander Digital Technology) Hainan facility is the operational benchmark: a 1,433-ton sealed cabin at 35 m depth off Lingshui county, running 24 racks and up to 500 servers. Reported PUE: 1.07 — better than Google’s best reported 1.09, achieved simply by eliminating HVAC overhead entirely.
There’s a second architecture worth knowing about: the Subsea Cloud Jules Verne pod near Port Angeles, Washington, at 9 m depth. Rather than a sealed-air vessel, it uses pressure equalisation and submerges servers in dielectric immersion fluid — a non-conductive liquid that extracts heat directly from hardware. Sixteen racks, approximately 800 servers, 1 MW IT capacity.
BHDT’s sealed-air design keeps servers in familiar environments — standard rack hardware, standard air cooling inside the cabin. Subsea Cloud’s immersion approach is more direct but requires specialised hardware preparation. Neither has a clear winner yet.
The historical precedent is Microsoft’s Project Natick, deployed off the Orkney Islands in 2018 with 864 servers for two years. It proved technical feasibility, reported excellent server reliability, then was discontinued citing maintenance concerns. BHDT Hainan is the first commercial operation to build on what Natick demonstrated. Two open questions remain: biofouling and seawater corrosion aren’t yet quantified for multi-year operations.
For more depth on the seawater cooling specifics, see China’s underwater data centres and Microsoft’s Project Natick.
Here’s the direct comparison across the three environments.
Terrestrial (traditional): Air and HVAC convection. PUE 1.54 global average; 1.09–1.15 for hyperscalers with free cooling. Infrastructure: HVAC plant, chillers, cold aisles. Challenge: 30–40% energy overhead at scale. Examples: enterprise data centres globally.
Underwater (ocean thermal): Seawater passive conduction through the hull. PUE 1.07 (BHDT Hainan) — the only commercial operational data point so far. Infrastructure: sealed pressure vessel or pressure-equalised immersion pod. Challenge: biofouling, maintenance access at depth, cable management. Examples: BHDT Hainan (35 m), Subsea Cloud Jules Verne (9 m).
Orbital vacuum: Thermal radiation only. PUE not yet measurable at commercial scale — radiator mass is the binding constraint, not energy overhead. Infrastructure: deployable radiator arrays, heat pipes. Challenge: SWaP budget, launch cost per kg, eclipse cycles. Examples: Starcloud-1 (H100, 60 kg satellite, launched November 2025), Axiom Space ISS nodes (launched January 2026).
The near-term practicable alternative is underwater ocean thermal. PUE 1.07 is proven and operational today. Orbital cooling is physics-constrained in a way that makes PUE almost the wrong metric — the real binding constraint is radiator mass and launch cost. ABI Research’s TCO analysis puts orbital compute cost at upward of 78 times the terrestrial equivalent at current economics, with convergence forecast by 2035 contingent on launch prices dropping substantially. For the full picture of why these environments are attracting investment despite current cost premiums, the comprehensive alternative data centre overview covers the market context alongside the engineering fundamentals explored here.
PUE doesn’t capture what orbital uniquely offers: solar power with no grid dependency, geographical neutrality, potential regulatory arbitrage, zero water consumption. Voyager Technologies CEO Dylan Taylor describes orbital cooling as “one of the most serious technical barriers facing space-based computing infrastructure.” That’s an honest assessment of where the engineering sits today.
For the planning framework built on this data, see the case for computing beyond the terrestrial grid.
Why is space cold but bad at cooling servers? Space has a background temperature of 2.7 K, but vacuum is a thermal insulator — there’s no air or liquid to carry heat away from a server. The only available mechanism is thermal radiation, which is far slower and more area-intensive than conduction or convection. Temperature and cooling capacity are not the same property in a vacuum.
What is PUE and why does 1.07 matter? PUE (Power Usage Effectiveness) is the ratio of total facility power to IT equipment power. A PUE of 1.07 — the BHDT Hainan figure — means only 7 cents of overhead per dollar of compute. The global average is 1.54 (54 cents overhead). The BHDT figure outperforms Google’s best reported 1.09 and approaches the theoretical minimum.
What is the Stefan-Boltzmann law in plain English? It describes how much energy a surface radiates based on its temperature. The key point: radiated power scales with the fourth power of temperature — an object twice as hot (in Kelvin) radiates 16 times more energy. For spacecraft radiators, operating at higher temperatures reduces the surface area required, but there’s a ceiling set by the electronics being cooled.
How does the BHDT Hainan underwater data centre work? BHDT operates a 1,433-ton sealed cabin at 35 m depth off Lingshui county, Hainan. Servers run inside a sealed air environment. Waste heat conducts through the cabin wall directly into ambient seawater — no mechanical pumping required. The facility runs 24 racks at PUE 1.07.
What is the difference between BHDT and Subsea Cloud’s cooling approach? BHDT uses a sealed-air pressure vessel — servers are air-cooled inside the cabin and hull conduction transfers heat to the ocean. Subsea Cloud’s Jules Verne pod uses pressure equalisation and submerges servers in dielectric immersion fluid for direct heat extraction. Different trade-offs in hardware compatibility and maintenance complexity.
What is a deployable radiator and why does Starcloud need one? A deployable radiator is a lightweight panel stored compactly during launch and mechanically extended in orbit. Because the Stefan-Boltzmann law requires large surface areas to reject GPU-class heat loads in vacuum, and launch costs run thousands of dollars per kilogram, radiators must fold for launch and unfold on orbit. Starcloud-2’s deployable radiator is described as the largest commercial example yet flown on a private satellite.
What were the results of Microsoft’s Project Natick? Deployed off the Orkney Islands in 2018, with 864 servers at approximately 36 m depth for two years. It demonstrated ocean-cooled computing viability and reported excellent server reliability. Microsoft discontinued the programme citing maintenance and lifecycle concerns. BHDT Hainan is the first commercial operation to build on Natick’s proof-of-concept.
What is the SWaP constraint in orbital data centres? SWaP stands for Size, Weight, and Power — a spacecraft engineering framework that treats all three as a unified budget. In orbital data centres, the cooling radiator consumes the largest share of all three. Increasing radiator area to handle more compute means more mass, more launch cost, and a larger structure to orient and deploy. Cooling, not compute, determines the upper limit of orbital data centre capacity.
Does seawater cooling cause environmental harm? At current operational scales (BHDT Hainan: 24 racks), heat rejection into the ocean is negligible relative to natural thermal variation. At the larger scales planned — the Hainan government’s 14th Five-Year Plan targets 100 underwater cabins — cumulative heat discharge and biofouling become open questions not yet addressed in available research.
Can orbital data centres achieve better PUE than hyperscalers? PUE is the wrong metric for orbital environments. Terrestrial hyperscalers achieve 1.09–1.15 by optimising energy overhead. Orbital facilities are constrained by radiator mass, not energy overhead. A hypothetical orbital facility with unlimited radiator area could approach PUE 1.0, but the launch economics at current prices would make per-FLOP cost far higher than terrestrial alternatives.
What is free cooling and which environments benefit from it? Free cooling means using ambient environmental temperature rather than mechanical refrigeration to reject heat. Hyperscalers in northern Europe use cold ambient air; underwater data centres use cold seawater. In both cases, the mechanical chiller plant is partially or entirely eliminated.
What happens to an orbital data centre during an eclipse? During eclipse, the satellite enters Earth’s shadow — solar power availability drops and the radiator’s orientation relative to the sun changes. Radiators previously emitting toward deep space may face warm terrestrial infrared. Thermal throttling may occur if the cooling system can’t maintain processor temperatures within spec. No published source currently quantifies eclipse-cycle impact on compute throughput for orbital data centre designs.
Power from the Sky — Orbital Solar Energy and the Data Centre Cost EquationAI infrastructure is running into a wall. Not a processing wall. A power wall. The IEA reports global data centre electricity consumption reached 415 TWh in 2024, growing at roughly 12% annually. The US Department of Energy projects large computing centres will account for 4.4% of US electricity consumption — essentially nothing a decade ago.
Some operators are proposing a structural fix: move compute off the terrestrial grid entirely and run it on solar arrays that never experience night, weather, or atmospheric interference. In this article we’re going to walk through the physics that makes orbital solar so compelling, the economics that currently make it 78 times more expensive than the ground alternative, and the single variable — launch cost — that determines whether parity arrives by 2035 or not at all. Speculative concepts like SpaceX Terafab are labelled explicitly. For the full thesis, see Computing Beyond the Grid.
AI workload growth has triggered the first four consecutive years of US power demand growth in two decades. The US Department of Energy projects data centre electricity consumption rising from 176 TWh in 2023 to between 325 and 580 TWh by 2028. Northern Virginia — the world’s largest data centre market — has grid interconnection queues stretching beyond 10 years. Around half of planned US AI data centre capacity is already delayed or cancelled. That’s roughly 7 GW stalled.
Near-term workarounds include BTM (behind-the-meter) generation — on-site power that bypasses the interconnection queue entirely — and SMRs (small modular reactors), compact nuclear reactors being evaluated for large AI campuses. Both are partial solutions. The power constraints already visible on current ISS-deployed orbital nodes show just how tight the energy budget gets when you leave the grid behind entirely.
A solar panel in sun-synchronous orbit (SSO) produces 10 to 40 times more usable energy per year than the same panel on Earth’s surface. Three factors compound: solar irradiance at the top of the atmosphere runs at 1,361 W/m² versus below 1,000 W/m² on the ground; there is no weather interrupting generation; and SSO panels face the sun almost continuously.
The number that matters here is capacity factor — the ratio of actual energy generated to the theoretical maximum. A sunny ground-based solar site achieves around 5–9 full-sun-equivalent hours per day. An SSO panel achieves above 95% year-round. That is what “10 to 40 times more” actually means in practice.
SSO is a polar dawn-to-dusk configuration where the satellite passes over any point at the same local solar time each day. Google’s Project Suncatcher feasibility study puts the combined productivity advantage at around 8x — different methodology, same direction.
One thing to be clear about: the energy supply side and heat dissipation are entirely separate problems in orbit. Without atmosphere or water, heat rejection is entirely radiative. The thermodynamics is covered separately in the physics of orbital and alternative data centre cooling.
Running an orbital data centre costs approximately 78 times more than a terrestrial equivalent on a TCO basis, according to ABI Research. That is current state, not a projection.
The premium sits across four buckets: launch cost amortisation, bespoke solar array hardware, cooling infrastructure mass that must be launched, and operational complexity with no physical access. Orbital solar LCOE (levelised cost of energy) sits around $500/MWh against terrestrial solar below $50/MWh — a 10x energy cost difference that compounds everything else.
Starcloud CEO Philip Johnston put it plainly: “We have to build it in-house because the cost equation is brutal.” Starcloud-3 targets $0.05/kWh — within hyperscaler PPA range — but that is contingent on $500/kg Starship launch costs not yet demonstrated. If costs stall at $1,500/kg, orbital energy cost triples. See Computing Beyond the Grid for the full TCO comparison.
The orbital compute cost case succeeds or fails on a single variable: cost-per-kilogram to orbit. Google’s Project Suncatcher analysis established $200/kg as the threshold at which orbital data centres become competitive. Falcon 9 currently runs at roughly $1,400/kg. Starship is projected at $100–500/kg at commercial scale — but every test flight to date has been expendable and no commercial pricing has been demonstrated.
Philip Johnston expects commercial Starship access in 2028–2029, describing Falcon 9 as a “tread water strategy” until then. That is the earliest, not the expected date. For more on SpaceX’s orbital compute plans, see SpaceX’s FCC filing and the launch economics underlying them.
Multiple organisations are making capital commitments across different layers of the same stack.
SpaceX Terafab — speculative — targets one terawatt of processor output annually, 50x all current advanced chip manufacturers combined. A new Advanced Technology Fab is planned near Austin, Texas, with estimated costs reaching $119 billion across all phases. No commercial product announced, no schedules disclosed. Worth monitoring, but not a near-term planning factor. The SpaceX orbital compute ambitions are a better near-term signal.
Blue Origin TeraWave is the connectivity layer: 5,400-plus LEO satellites delivering up to 6 terabits per second, serving as a precursor to Blue Origin’s Project Sunrise orbital compute filing. ESA’s ASCEND Programme runs €300M through 2027, treating orbital solar as a European energy independence and sovereignty question. Google Project Suncatcher plans two test satellites with TPUs in partnership with Planet Labs by early 2027.
China’s Xingshidai Constellation — a parallel orbital compute programme flagged in Scientific American — is a geopolitical monitoring signal that Western sources have not deeply analysed. That is a strategic blind spot worth keeping on your radar.
ABI Research projects orbital compute cost-per-watt reaching parity with terrestrial benchmarks by around 2035, forecasting up to 18,600 data centres in space with 1.5 GW of effective compute power. SemiAnalysis‘s more conservative modelling puts full LCOC parity closer to 2040. The honest planning window is 2035–2040.
Four conditions need to hold simultaneously for that to happen: Starship reaching $100–200/kg commercial pricing; orbital solar manufacturing closing the 10x LCOE gap; hardware standardisation reducing mass-per-compute-unit; and terrestrial energy costs staying elevated. If grid constraints ease, the competing baseline improves and the gap widens again.
The environmental picture is contested. A Saarland University “Dirty Bits” analysis found orbital data centres could produce up to 10x more lifecycle emissions than terrestrial equivalents when launch propellant, hardware manufacture, and reentry are counted. SpaceX’s FCC filing claims a significant environmental benefit — but counts only operational emissions. The methodology is unresolved.
The 2035 convergence scenario is a 10-year monitoring signal, not a near-term purchase decision. The relevant decisions now are about avoiding lock-in — keeping options open when orbital alternatives become commercially viable. For a framework, see when orbital and underwater data centres become an infrastructure planning factor and the full alternative compute thesis.
SBSP deploys photovoltaic arrays in Earth orbit to capture solar energy without atmospheric interference. It is the proposed long-term structural answer to terrestrial grid capacity constraints — removing compute from the grid rather than competing for scarce interconnection slots.
10 to 40 times more energy-dense per square metre annually. Solar irradiance in LEO is approximately 1,361 W/m² versus below 1,000 W/m² on the ground; there is no weather; and SSO capacity factor exceeds 95% versus 12–25% for terrestrial solar.
SSO is a polar dawn-to-dusk orbit where panels face the sun almost continuously. Google’s Project Suncatcher envisions 81-satellite compute clusters in SSO for this reason — strong solar availability and low latency, though the orbit is already becoming congested.
ABI Research puts the current TCO premium at approximately 78 times a terrestrial equivalent, across four buckets: launch cost amortisation, bespoke solar array hardware, cooling infrastructure mass, and operational complexity with no physical access.
Google’s orbital solar feasibility initiative pairing TPU-equipped satellites with free-space optical links, targeting a two-satellite demonstration with Planet Labs by early 2027. The key output is the $200/kg launch cost threshold at which orbital data centres become competitive — cited in Scientific American as a credibility signal from a hyperscaler with direct infrastructure interests.
A speculative concept for vertically integrating orbital solar panel and chip manufacturing, targeting one terawatt of processors annually. With estimated costs at $119 billion across all phases and no disclosed schedules, Terafab is not a near-term planning factor.
Contested. SpaceX’s FCC filing claims significant environmental benefit counting only operational emissions. The Saarland University “Dirty Bits” analysis found up to 10x more lifecycle emissions when launch propellant, hardware manufacture, and reentry are included. The methodology is unresolved — treat both claims accordingly.
The planning window is 2035–2040. ABI Research projects convergence by 2035; SemiAnalysis puts full LCOC parity closer to 2040. Philip Johnston (Starcloud CEO) puts earliest commercial viability at 2028–2029, contingent on Starship at $500/kg.
Google’s 200/kgthresholdversusFalcon9′scurrent 1,400/kg means the entire cost case depends on Starship achieving commercial pricing and cadence. Every Starship test flight to date has been expendable; commercial reuse pricing has not been demonstrated. If costs stall at $1,500/kg, Starcloud’s orbital energy cost triples from its target.
BTM generation is on-site power that bypasses grid interconnection queues — ExxonMobil and Chevron are developing dedicated BTM gas plants for US data centres. SMRs are compact nuclear reactors being evaluated for large AI campuses. Both are near-term partial solutions to terrestrial grid scarcity, not competitors to orbital compute — different timescales, different problems.
China’s parallel orbital solar and compute programme, flagged in Scientific American as a geopolitical signal but not deeply analysed in Western sources — a strategic blind spot for infrastructure planners monitoring the orbital compute landscape.
Without atmosphere or water, radiative dissipation is the only heat rejection mechanism. To radiate 1 MW of heat at 20°C, an orbital data centre needs roughly 1,200 m² of radiator surface. The full thermodynamics treatment is in the physics of alternative data centre cooling.
China’s Underwater Data Centres and What Microsoft Abandoned with Project NatickMicrosoft spent five years proving underwater data centres work, then walked away in 2024. China’s BHDT has been running one commercially since 2023. Same technology. Same PUE numbers. So what happened?
The short answer is demand. Seawater passive cooling really does achieve a PUE of 1.07 — you can verify that from both Microsoft’s Orkney results and BHDT’s operational Hainan facility. But that efficiency gain only justifies deployment cost if you’re running enough compute to make the economics work. Microsoft wasn’t. China is.
Here’s what this article covers: what the Hainan facility actually is, how seawater cooling gets to those efficiency numbers, what Microsoft proved and why it stopped, and what the “thermal debt” controversy is really arguing. For the broader picture of where underwater sits in the alternative data centre landscape, see the Computing Beyond the Grid overview.
Beijing Highlander Digital Technologies (BHDT) and its subsidiary Shenzhen HiCloud Data Centre Technology operate China’s first commercial underwater data centre off Lingshui County, Hainan Island, in the South China Sea. It’s been running since March 2023.
The specs: a 1,300-tonne sealed pressure vessel sitting at 35 metres depth. Each cabin holds 24 racks, 400 to 500 servers, pressurised with dry nitrogen. Phase 2 added a second module in February 2025, and Hainan’s 14th Five-Year Plan targets 100 cabins at the site. HiCloud has also launched Hailanyun off Shanghai — offshore wind-powered, May 2026, 2,000 servers, 24 MW.
This isn’t a pilot. The facility runs live production AI workloads — 7,000 inference queries per second.
One thing worth flagging if you’re in a US-regulated business: BHDT is on the US Commerce Department Entity List. US-based firms face restrictions on exporting items, software, and technology to listed entities. If you’re subject to US export controls, any BHDT engagement needs a legal review first, full stop.
The facility operates within the Hainan Free Trade Port policy framework — green development is written into all planning decisions, which is a big part of why BHDT could move so fast.
PUE — Power Usage Effectiveness — is total facility energy divided by IT equipment energy. A perfect score is 1.0. The industry average sits around 1.58; well-run hyperscalers like AWS and Google average 1.1 to 1.2. At 1.07, only 7% of total power goes to overhead — cooling, lighting, power conversion. At 1.5, that’s 50%. That’s roughly 30% more efficient than a well-run hyperscaler.
The mechanism is straightforward. Server heat is conducted through the sealed metallic hull into ambient seawater via copper-pipe heat exchangers. No pumps. No mechanical chillers. No active cooling loop. The seawater is the radiator.
Why it holds up so well: at 35 metres depth, seawater temperature is stable year-round — no warm-day degradation, no evaporative water loss, no refrigeration energy draw. The inert nitrogen atmosphere limits corrosion and removes the mechanical vibration and temperature fluctuations that accelerate hardware failure on land.
Microsoft’s Project Natick Phase 2 at Orkney measured the exact same PUE of 1.07. This isn’t a China-specific result — it’s a property of the cooling mechanism itself. For a deeper dive into how the thermodynamics actually work, see the physics of alternative data centre cooling.
Phase 1 ran for 105 days in 2015 off California. It was a proof of concept — servers could operate underwater in a sealed vessel without failure. Phase 2 ran from 2018 to 2020 off the Orkney Islands, with 864 servers over 25 months. PUE 1.07 confirmed at scale. Server failure rate underwater was 0.7% versus 5.9% on land — roughly a 6x improvement, attributed to the nitrogen atmosphere and the absence of human-caused disturbance. Microsoft called it a success. The results weren’t disputed.
Then in June 2024, Microsoft announced it would not build subsea data centres anywhere in the world. Three reasons.
First, the sealed hull is fixed capacity. You cannot upgrade or replace hardware without surfacing the entire pod. A land data centre swaps GPU generations in-place. An underwater pod cannot. During the H100 to H200 to Blackwell hardware cycle, that’s a structural problem.
Second, seabed permitting is a multi-jurisdictional obstacle — and without state backing, it’s a serious one. Microsoft ran Phase 2 on a research permit. Commercial deployment needs seabed leases, environmental assessments, and ongoing regulatory approval across jurisdictions.
Third, the economics at 2020 demand levels just didn’t justify the incremental costs. Deloitte Insights put it plainly: Microsoft ended the programme; Chinese Highlander deployed commercial modules with government backing. The technology worked. The conditions for commercialisation weren’t there.
The technology didn’t change. The demand did.
China’s internet firms — Alibaba, Baidu, ByteDance, Tencent — are investing over $70 billion in AI infrastructure in 2026 alone (Goldman Sachs). Data centre capacity is growing from 32 GW toward 60 GW by 2030, with intelligent compute expected to grow roughly 43% year over year. At that scale, a 30% efficiency gain over a well-run hyperscaler stops being a curiosity and becomes worth engineering for — the PUE savings that didn’t justify deployment costs in 2020 are now material.
There’s also a policy driver. New facilities in China’s 8 national computing hubs must source at least 80% of their energy from renewables. Underwater coastal deployment addresses this directly: seawater cooling cuts total energy consumption, and offshore locations tie directly to offshore wind. BHDT’s facility draws power from nearby offshore wind sources and avoids consuming land or freshwater.
BHDT is a state-adjacent operator in an environment where the government controls both permitting and the demand signal. What took Microsoft years of research permitting in UK waters, BHDT navigated as a domestic state-enabled deployment.
BHDT manages the fixed-capacity constraint by adding new pods rather than upgrading sealed ones — but individual cabins remain fixed-capacity. Subsea Cloud’s Jules Verne pod in Port Angeles, WA (9m depth, 16 racks, 1 MW) shows the technology works commercially outside China too — the demand and regulatory conditions just differ. For the geopolitical implications of that distinction, it matters quite a bit.
“Thermal debt” was coined in a 2024 National Interest article arguing that underwater data centres discharge waste heat as an unpriced externality. Ding Duo in China Daily called it absurd and unscientific — tests show temperature increases of under 1–2°C at the outlet, dissipating within metres. Microsoft’s own Natick measurements showed ambient increases of a few thousandths of a degree.
Neither source is neutral. The National Interest has an obvious interest in framing Chinese AI infrastructure negatively; China Daily has an equally obvious interest in defending it. Neither is a peer-reviewed environmental impact study.
What is factual: seawater does warm from the heat discharge. Initial studies suggest limited impacts at small scales, but uncertainty remains about cumulative effects at large-scale deployment. No standardised Environmental Impact Assessment framework exists as of 2026. At current density, the impact is unlikely to be material. At 100-cabin scale, the evidence base doesn’t yet exist. This is a monitoring issue, not a settled verdict.
The global underwater data centre market was valued at around USD 3.2 billion in 2025 and is projected to reach USD 14.8 billion by 2034 at 18.6% annual growth (DataIntelo). Fast-growing niche. Not yet mainstream infrastructure.
Three commercially operating facilities as of mid-2026: BHDT Hainan (AI inference, South China Sea), HiCloud Hailanyun (Shanghai, 24 MW, offshore wind), and Subsea Cloud’s Jules Verne (Port Angeles, WA, 1 MW). South Korea, Japan, and Singapore have announced plans; none are yet operational. Engineering is splitting into two approaches: sealed-hull passive cooling (BHDT, Natick) versus pressure-equalised dielectric immersion (Subsea Cloud). Neither has dominated yet.
For most organisations, underwater data centres aren’t a near-term vendor option. On a 3 to 5-year planning horizon, the question is which vendors in your region might offer this, and what compliance and entity-list considerations attach. For alternatives at the other end of the physical spectrum, Axiom Space’s orbital data centre nodes are worth understanding. The alternative data centre landscape is moving from research into commercial operation faster than most planning cycles account for.
What exactly is an underwater data centre?
A sealed or pressure-equalised computing vessel on the seabed, using ambient seawater as the primary cooling medium — no mechanical chillers, no active cooling loops. Operational examples: BHDT Hainan (35m, South China Sea, since 2023) and Subsea Cloud Jules Verne (9m, Port Angeles WA, since 2023).
Why do China’s data centre economics make underwater deployment viable when Microsoft’s did not?
China’s AI compute demand is growing at roughly 43% per year, with $70B+ in infrastructure investment in 2026 alone and an 80% renewable energy mandate that makes alternative cooling economically necessary. State-backed permitting removes the regulatory timeline that blocked Microsoft. Same technology; completely different demand and policy context.
Why is PUE 1.07 considered exceptional?
Industry average is around 1.58; hyperscalers reach 1.1 to 1.2. At 1.07, only 7% of power goes to overhead versus 50% at 1.5. The gap to 1.2 is roughly 11% lower energy cost per compute unit — material at AI inference scale.
What workloads is China’s Hainan underwater data centre running?
Production AI inference workloads — processing 7,000 queries per second. Commercial, not experimental.
How did Microsoft Project Natick perform before being discontinued?
Phase 2 (Orkney, 2018–2020): 864 servers, 25 months, PUE 1.07. Server failure rate 0.7% underwater versus 5.9% on land — roughly a 6x reliability improvement. Microsoft confirmed the results were technically successful before discontinuing.
Can the servers inside an underwater data centre pod be upgraded or replaced?
Not in-place. The pod must be surfaced to add, replace, or upgrade hardware. BHDT adds new pods rather than upgrading existing ones — a workaround, not a fix. Pressure-equalised designs have different access characteristics but their own servicing constraints.
What is BHDT’s US entity list status and what does it mean for your business?
BHDT is on the US Commerce Department Entity List. US-based firms and those subject to US export controls face restrictions on exporting items, software, and technology to listed entities. If that’s you, any BHDT engagement needs legal review first.
How does China’s approach to underwater data centres differ from Subsea Cloud’s Jules Verne pod?
BHDT: sealed pressure vessel, passive hull-conduction cooling, nitrogen atmosphere, 35m depth, South China Sea, multi-module at 400–500 servers per cabin. Jules Verne: pressure-equalised chamber, dielectric immersion cooling, 9m depth, Port Angeles WA, 16 racks, ~800 servers, 1 MW. Two distinct engineering philosophies.
Are underwater data centres better for the environment than land-based ones?
On energy: yes — up to 40% less energy consumption than traditional data centres, no freshwater use, lower emissions paired with renewables. On marine impact: genuinely uncertain — limited impacts at small scales, cumulative effects at large deployment scale unestablished. No standardised EIA framework as of 2026.
What regulatory approvals are required to deploy an underwater data centre?
Seabed permitting, marine construction permits, EIA requirements, and ongoing maritime compliance — no standardised global EIA framework as of 2026. China’s Hainan Free Trade Port framework lets state-adjacent operators move fast. Western commercial operators face a multi-year process with no clear template.
What countries are planning underwater data centres after China?
South Korea, Japan, and Singapore have announced plans; none operational yet. The US has Jules Verne (Port Angeles, since 2023). Europe had Project Natick Phase 2 in Orkney — no commercial successor announced.
NVIDIA Vera Rubin Space-1 — The Hardware Behind Orbital AI ComputeAt GTC in March 2026, Jensen Huang announced that “Space computing, the final frontier, has arrived.” Great line. The hardware reality behind it is a bit more specific — and a lot more useful for your planning — than that headline lets on.
NVIDIA rolled out a three-product space computing platform: the Space-1 Vera Rubin Module for orbital AI at scale (not yet shipping), IGX Thor for mission-critical edge work (available now), and Jetson Orin for compact inference on mass-constrained satellites (available now and already in orbit). Alongside those products, NVIDIA announced six launch partners: Aetherflux, Axiom Space, Kepler Communications, Planet Labs PBC, Sophia Space, and Starcloud.
The engineering constraints that make orbital data centre (ODC) deployments tricky come down to three things: SWaP (Size, Weight, and Power), thermal management in vacuum, and radiation tolerance. This article breaks down what each constraint means for your hardware planning, which products address which, and where the six partners actually sit today versus the roadmap.
Space-1 is a 2027 story. IGX Thor and Jetson Orin are ready to go right now.
The GTC announcement was more a formalisation of existing momentum than a launch from scratch. Starcloud had already put an H100 into orbit on 2 November 2025 — the first NVIDIA GPU in space — and run Google’s Gemma LLM on it. NVIDIA’s announcement put a name to that trajectory and extended the hardware roadmap.
The three-tier product hierarchy is deliberate. Space-1 is aimed at high-density ODCs running LLMs and foundation model inference in orbit. IGX Thor handles mission-critical edge applications where reliability and functional safety matter most. Jetson Orin covers small form-factor satellites where power and mass budgets are tight.
Naming six partners at launch also signals that NVIDIA wants to be an ecosystem builder, not just a chip vendor. Over 35 companies make up the ODC ecosystem as of mid-2026 — a number ABI Research expects to double by 2027.
The Space-1 Vera Rubin Module is an integrated CPU-GPU system with high-bandwidth interconnect, built from the ground up for orbital data centres running LLMs and foundation models. NVIDIA claims 25x more AI compute than the H100 for orbital inferencing workloads — no independent methodology backs that figure yet, so treat it as a marketing claim until third-party benchmarks arrive.
Space-1 draws on NVIDIA’s Vera Rubin architecture and is engineered to the SWaP and thermal envelope of space deployment. The design target is the Starcloud milestone — first LLM inference in orbit on an H100 — scaled natively.
Two gaps are worth flagging. NVIDIA has not disclosed silicon specs — die size, memory type, or power envelope. And Chen Su, NVIDIA’s head of edge AI product marketing, confirmed availability in 2027, with no further details on CUDA software-stack compatibility for Space-1. If ground-based CUDA workloads can’t port cleanly, that changes the value proposition significantly. Plan accordingly.
SWaP stands for Size, Weight, and Power — the three-dimensional engineering budget every satellite payload must stay within. SWaP-C adds Cost as a fourth dimension.
Size: a standard H100 PCIe card plus its supporting infrastructure has to fit inside a satellite bus that was never designed around a data centre GPU. Weight: SpaceX has brought LEO launch costs to roughly $1,400/kg for Falcon Heavy, with Starship targeting $100/kg — every kilogram has a direct dollar cost attached to it. Power: an H100 at peak draw is 700W TDP. In LEO, solar power is available roughly 60% of each orbit. For a 2,000-kg satellite generating 100 kW, around 670 kg may go to solar panels alone, leaving very little budget for compute.
Philip Johnston, CEO of Starcloud, put it plainly: “An H100 is probably not the best chip for space, to be honest, but the reason we did it is we wanted to prove that we could run state of the art terrestrial chips in space.” Starcloud’s 59 kg satellite was purpose-built around a single H100. It proved feasibility. But it required engineering an entire spacecraft around the chip.
Jetson Orin is designed for missions where the SWaP envelope leaves no room to move. Compact, low-power, CUDA-enabled — and available now.
In a vacuum, convection doesn’t exist. No fans. No liquid loops that vent to open air. The only way to shed heat is through radiative cooling — emitting accumulated heat as infrared radiation, governed by the Stefan-Boltzmann law. To shed more heat, you either increase radiator area or increase operating temperature, which affects chip longevity.
ABI Research’s numbers make this concrete: a single H100 GPU needs approximately 1.1 m² of radiator surface. A full DGX H100 system needs approximately 16 m² — larger than a king-sized bed — plus 33 m² of solar panels.
Three design approaches are in use today. Starcloud uses deployable radiators — panels that unfurl after reaching orbit. Sophia Space integrates passive radiators across the entire spacecraft surface. Axiom Space is testing thermal tiles with Spacebilt that radiate heat toward the cosmic microwave background. Active thermal control using space-rated heat pumps is expected to improve radiator efficiency from 2027. The physics of orbital cooling article in this cluster goes deeper on radiator sizing and thermal constraints.
Traditional space hardware uses radiation-hardened chips — semiconductors purpose-designed for the ionising radiation of space. They’re reliable. But they’re also expensive, low-volume, and typically one to several generations behind commercial silicon. The most capable rad-hard processor available today can’t run current-generation AI workloads.
COTS — Commercial Off-The-Shelf — means using standard commercial chips in orbit without full radiation-hardening certification. The risk is Single-Event Upsets (SEUs): bit-flip errors in semiconductor memory caused by cosmic radiation. The mitigations are shielding, hardware redundancy, and error-correction software.
Starcloud went COTS. The performance advantage of a current-generation commercial GPU is simply too large to forfeit. But Philip Johnston confirmed that a predecessor mission using an NVIDIA A6000 GPU failed during or shortly after launch — the GPU did not survive. The H100 mission succeeded. That failure is the industry’s concrete data point that COTS in orbit is an engineering tradeoff, not a solved problem.
NVIDIA has not disclosed the radiation tolerance or SEU mitigation approach for Space-1. That’s an unaddressed gap as of mid-2026.
NVIDIA named six partners at GTC. Each occupies a different position in the orbital compute stack, and they are not all at the same stage.
Starcloud (CEO Philip Johnston) is the furthest along. It launched the first NVIDIA GPU in orbit in November 2025, ran Gemma LLM inference, and raised $170 million Series A. Starcloud-2 will use Blackwell architecture plus an AWS server blade before end of 2026.
Kepler Communications (CEO Mina Mitry) has the largest NVIDIA footprint in orbit today: 10 satellites, approximately 40 Jetson Orin processors — an operational fleet, not a pilot.
Axiom Space launched dedicated ODC nodes in January 2026, handling cloud compute, AI/ML workloads, and data fusion. See the Axiom Space ISS deployment article for the full picture.
Planet Labs PBC (CEO Will Marshall) is integrating NVIDIA platforms across its space-to-ground pipeline for GEOINT workloads, using CorrDiff AI models for near real-time insights.
Sophia Space (CEO Rob DeMillo) raised $10 million seed in February 2026 and is testing its ODC software on Kepler satellites, with its own launch planned for 2027.
Aetherflux (CEO Baiju Bhatt) is pre-launch, planning its first data centre satellite around Space-1 once the module ships.
So: one partner (Kepler) is running substantial NVIDIA hardware in orbit today. One (Starcloud) ran a milestone demonstration. Two (Axiom, Planet Labs) are in active deployment. Two (Sophia Space, Aetherflux) are pre-launch. That gap between announced and deployed is the planning factor that matters most right now.
Orbital data centres currently cost somewhere between 3x and 78x the terrestrial equivalent — 3x per IEEE Spectrum’s operational cost comparison, up to 78x per ABI Research’s full TCO analysis. ABI Research projects convergence by 2035. If your use case is GEOINT, satellite data management, or defence/ISR, the economics work for some operators now. For general compute, not yet. SpaceX’s orbital constellation plans will shape that timeline considerably.
What is the NVIDIA Vera Rubin Space-1 module?
An integrated CPU-GPU module on NVIDIA’s Vera Rubin architecture, designed for ODCs running LLMs and foundation models. Claims 25x more AI compute than the H100 for orbital inferencing; no independent benchmark available yet. Announced at GTC March 2026; projected availability 2027 per Chen Su, NVIDIA’s head of edge AI product marketing.
When will the NVIDIA Space-1 be available?
No formal release date. IGX Thor, Jetson Orin, and RTX PRO 6000 Blackwell Server Edition are available now. Space-1 is in the announced-but-not-shipping category; Chen Su confirmed “2027.”
What NVIDIA hardware is available now for orbital deployment?
IGX Thor: mission-critical edge on Blackwell; 8x performance over the previous gold standard. Jetson Orin: ultra-compact AI inference; deployed by Kepler across ~40 processors on 10 satellites. RTX PRO 6000 Blackwell Server Edition: ground-based GEOINT analysis GPU.
What does SWaP mean in the context of satellite computing?
SWaP = Size, Weight, and Power — the engineering budget every satellite payload must stay within. SWaP-C adds Cost. Tighter envelopes require lower-power, lighter, more compact hardware — the reason Jetson Orin exists at the low end of NVIDIA’s space stack.
How does NVIDIA cool a GPU in space if there’s no air?
In vacuum, heat dissipation is only possible through radiation. ABI Research puts the requirement at 1.1 m² of radiator per H100 GPU; 16 m² per DGX H100 system. Approaches: deployable radiators (Starcloud), passive surface radiators (Sophia Space), thermal tiles (Axiom Space/Spacebilt).
What happened to Starcloud’s first satellite attempt?
Starcloud’s predecessor mission using an NVIDIA A6000 GPU failed during or shortly after launch — the GPU did not survive. The H100 mission in November 2025 succeeded, running Gemma LLM inference in orbit. It’s the industry’s concrete data point that COTS in orbit carries real risk.
What is the difference between radiation-hardened and COTS chips for space?
Rad-hard: purpose-designed for ionising radiation; expensive, low-volume, typically one to two generations behind commercial silicon. COTS: modern performance at commercial cost, but carries radiation risk via Single-Event Upsets. The industry chose COTS because modern GPU performance simply isn’t available in rad-hard products.
Does NVIDIA Space-1 support existing CUDA workloads?
NVIDIA has not disclosed CUDA compatibility for Space-1. Jetson Orin is confirmed CUDA-enabled. For Space-1, ground-based workload portability is still an open question.
What is an orbital data centre (ODC)?
A compute facility in orbit — aboard a satellite — running AI inference or data processing workloads in space. Primary advantage: processing sensor data before downlinking reduces bandwidth and latency. Primary challenges: SWaP constraints, thermal management, radiation tolerance, and intermittent solar power.
Is orbital AI computing economically viable?
ABI Research puts current ODC TCO at up to 78x a terrestrial equivalent; IEEE Spectrum at roughly 3x depending on what’s being measured. ABI Research projects $/W convergence with terrestrial by 2035. If your use case is GEOINT or defence/ISR, the economics work for some operators now. For general compute, not yet.
What is the NVIDIA IGX Thor and who uses it?
Industrial-grade, mission-critical edge computing on Blackwell architecture; available now; 8x the compute of the previous gold standard for space-based AI. Supports functional safety, real-time AI processing, and autonomous operation for spacecraft sensor workloads.
Who is Kepler Communications and what are they running in orbit?
Kepler Communications operates the largest NVIDIA deployment in orbit — approximately 40 Jetson Orin processors across 10 satellites, linked by optical laser, for AI-driven data management. CEO Mina Mitry. Not a proof-of-concept — an operational fleet.
The Space-1 hardware story is one layer of a broader shift. Orbital vacuum cooling, underwater data centres, orbital solar power, and the first commercial deployments are each changing the economics of where compute runs. For a complete overview of all the environments and the strategic questions they raise, see our guide to orbital and underwater computing environments.
SpaceX and the Million-Satellite FCC Filing — Orbital Data Centre Plans at ScaleMost data centre announcements describe buildings. SpaceX filed a document with the FCC in January 2026 proposing up to one million satellites to do the same job. That document — SAT-LOA-20260108-00016 — is real and you can look it up.
Here’s the interesting tension though: SpaceX’s own S-1 IPO risk disclosures describe orbital data centres as involving “significant technical complexity and unproven technologies.” That gap runs through everything — the FCC filing, the Anthropic deal, the competition, and what it all means when someone at your board table starts asking about it. This is part of our broader look at the alternative computing landscape.
SAT-LOA-20260108-00016 was filed by SpaceX in late January 2026 and accepted by the FCC on 4 February 2026. It seeks authorisation to deploy up to 1 million satellites in non-geostationary orbit between 500 and 2,000 km altitude. There’s no dedicated “space data centre” licensing category — this sits within the existing NGSO framework.
That one million figure is a ceiling, not a commitment. Regulatory filings routinely ask for more than operators intend to build. SpaceX’s actual deployment pace will depend on Starship launch economics and commercial demand.
Some scale context. SpaceX’s active Starlink constellation runs to roughly 7,000–10,000 satellites. The filing’s ceiling is a roughly 70-fold increase over the entire current low Earth orbit population — and Ars Technica put the barebones deployment cost at “at least $1 trillion.”
The filing covers infrastructure authorisation only. Per-satellite compute hardware was outlined separately at the AI Sat Mini announcement on 21 March 2026: a satellite carrying 100 kW of power for onboard AI processors. These are complementary documents, not the same plan. The AI Sat Mini’s 100 kW power budget connects to the hardware constraints explored in our NVIDIA Space-1 analysis.
For comparison, Blue Origin filed its own application — SAT-LOA-20260310-00118 — on 19 March 2026 for a 51,600-satellite orbital data centre network called Project Sunrise. That one’s still pending FCC approval as of mid-2026.
SpaceX acquired xAI on 2 February 2026 in an all-stock deal valuing xAI at $250 billion. Grok and Tesla’s autonomous driving AI became the primary internal workloads the whole orbital compute bet is designed to serve.
Elon Musk hasn’t been shy about the strategic logic. At the World Economic Forum in January 2026, he called space-based AI data centres a “no-brainer” and predicted more AI capacity would sit in orbit than on Earth within five years. Those are leadership positioning statements, not operational commitments — and they sit in sharp contrast to what SpaceX put in its SEC filings.
Then in May 2026, Anthropic expressed interest in partnering with SpaceX for multiple gigawatts of orbital AI compute capacity. For context: SpaceX’s entire Starlink constellation produces roughly 200 MW of total power. Gigawatt-scale orbital compute would require five to fifteen times that. Alongside this, Anthropic signed a near-term deal to take the full capacity of SpaceX’s Colossus 1 terrestrial data centre — 222,000+ Nvidia GPUs and 300+ MW of compute — for a reported $15 billion per year.
SpaceX is simultaneously platform provider and major customer. Whether future third-party enterprise customers get priority access or competitive pricing is a practical question that hasn’t been answered. Orbital compute economics are part of the wider alternative infrastructure picture.
Starcloud (formerly Lumen Orbit) raised a $170 million Series A on 30 March 2026 at a $1.1 billion valuation. Benchmark partner Chetan Puttagunta nailed the investment thesis: “The cost of power on Earth is rising faster than the cost of launch is falling. That crossover is the entire investment case.”
Starcloud plans 88,000 satellites and has positioned itself as infrastructure-for-others from day one. AWS, Nvidia, Crusoe Energy, and the US Department of Defense are early customers. SpaceX is building primarily for Grok and Tesla. Starcloud is the AWS of orbital compute.
The staging tells the economic story. Starcloud-1 launched in November 2025 and ran the first in-orbit LLM training in December 2025. Starcloud-2 (~100 kW, Nvidia Blackwell) is planned for Q4 2026 as the first satellite expected to generate more revenue than it costs to build and launch. Starcloud-3 (3 tonnes, 200 kW) is designed for Starship deployment. Johnston has been direct about the dependency: “Until Starship is flying we can basically tread water launching on Falcon 9.”
Blue Origin’s Project Sunrise proposes 51,600 satellites with FCC approval still pending. Google’s Project Suncatcher plans two test satellites carrying Google TPUs by early 2027. All four players — SpaceX, Starcloud, Blue Origin, Google — share the same structural constraint. Axiom Space’s first commercial orbital nodes represent a different entry point: kW-scale edge compute already operational while SpaceX plans at the million-satellite horizon.
The most interesting counterpoint to SpaceX’s orbital compute ambitions comes from SpaceX itself. The S-1 states directly: “Our initiatives to develop orbital AI compute and in-orbit, lunar, and interplanetary industrialization are in early stages, involve significant technical complexity and unproven technologies, and may not achieve commercial viability.”
Risk disclosures carry legal weight. As The Next Web put it: “The gap between Davos in January and the SEC in April is the gap between a pitch and a prospectus. Both are real. Only one carries legal liability.”
The specific technical risks are real and worth understanding. Radiation causes permanent circuit damage and radiation-hardened chips lag multiple generations behind commercial processors. Hardware cannot be replaced or upgraded once in orbit — operators have a 3–5 year window before the compute is obsolete. Heat rejection is a hard physical constraint: radiating one megawatt at 20 degrees Celsius requires roughly 1,200 square metres of radiator. You can’t negotiate with thermodynamics.
ABI Research estimates that an orbital data centre costs upward of 78 times more than a terrestrial equivalent today. That gap only closes if launch costs fall dramatically, power-per-kg ratios improve, and manufacturing reaches scale — all projected, not current.
Current Falcon 9 launch costs run approximately $1,400–1,500/kg to LEO. Starship, at scale, is designed to reach $100–500/kg — a 3–14 times reduction that hasn’t been demonstrated yet. Until Starship reaches commercial operational cadence, all orbital compute operators face Falcon 9 economics, and at those prices orbital compute can’t compete with terrestrial hyperscalers.
Starcloud’s staged approach makes the dependency concrete. Falcon 9 launches are proof-of-concept, not commercial economics. Johnston expects commercial Starship access in the “mid- to late-2028 timeframe,” with commercial payloads following 18–24 months after that. Google’s feasibility threshold is $200/kg, projected by the mid-2030s.
The AI Sat Mini signals SpaceX’s near-term hardware approach — a proof-of-concept unit, not a deployment-ready commercial product. There’s also a chip supply dependency: SpaceX’s Terafab project targets 1 terawatt of processors annually — roughly 50 times all current AI chip production. Both are pre-commercial. The energy economics that make orbital compute viable are examined in detail in our orbital solar analysis.
SpaceX’s FCC filing and the Anthropic agreement are real signals. They show serious capital and regulatory effort going into orbital compute infrastructure. They are not planning factors for the next 3–5 years for most organisations.
ABI Research identifies the near-term use cases for 2026–2029 as Earth Observation, kW-scale Compute-as-a-Service, and space traffic management. General-purpose enterprise AI workloads are firmly a 2030s conversation.
Here’s what would need to happen for orbital compute to move from watch-list to planning factor: Starship achieving commercial launch cadence, a published enterprise pricing model with contractual SLAs, and at least one regulated-industry customer — SOC 2, HIPAA, FedRAMP — running production workloads with verifiable uptime data. None of these currently exist.
Board questions about SpaceX or Google orbital compute most often reflect investor enthusiasm rather than near-term supply chain risk or competitive displacement. This is a 2030s infrastructure conversation, not a 2026–2028 decision.
What to actually track: Starship commercial launch cadence and per-kg cost announcements, FCC final approval or denial for SAT-LOA-20260108-00016 and SAT-LOA-20260310-00118, and whether any regulated enterprise customer publishes a case study for orbital workloads. That last one is the clearest signal that compliance blockers have been resolved — and right now, no such case study exists.
For a full decision framework on when alternative data centres become a planning factor, see our infrastructure planning guide. The alternative computing landscape continues to attract genuine investment, but in 2026 the question is what to track, not what to act on.
SAT-LOA-20260108-00016 is the FCC application filed by SpaceX in late January 2026, accepted by the FCC on 4 February 2026, seeking authorisation to deploy up to 1 million satellites in low Earth orbit for orbital data centre purposes. It sits within the existing non-geostationary satellite orbit (NGSO) licensing framework — no dedicated “space data centre” regulatory category exists. The filing can be searched on the FCC’s International Communications Filing System.
It’s a ceiling — the maximum SpaceX is requesting permission to deploy, not a committed launch schedule. Regulatory filings routinely ask for more than operators intend to build to preserve future flexibility. SpaceX’s actual deployment pace depends on Starship launch economics and commercial demand, not FCC approval.
The AI Sat Mini is SpaceX’s proposed initial orbital compute satellite, outlined on 21 March 2026. It’s designed to carry 100 kW of power for onboard AI processors. The FCC filing covers the broader constellation authorisation; the AI Sat Mini describes the hardware approach. They’re complementary documents covering different layers of the same plan.
No. The May 2026 development is a compute agreement indicating Anthropic’s interest in partnering with SpaceX for multiple gigawatts of orbital AI compute capacity. It’s a demand signal and expression of intent, not a binding commercial contract.
SpaceX’s orbital compute plan is internal-first — primarily serving Grok (xAI) and Tesla workloads, with external customers secondary. Starcloud is infrastructure-for-others from day one, with AWS, Nvidia, Crusoe Energy, and the US DoD as early customers. SpaceX plans up to 1 million satellites; Starcloud plans 88,000. Both share a Starship dependency for commercial unit economics.
SpaceX’s S-1 IPO risk disclosures identify: significant technical complexity and unproven technologies; the unpredictable space environment making commercial viability uncertain; radiation effects that corrupt hardware; and the inability to upgrade or replace hardware once it’s in orbit. These are material risk disclosures that carry legal weight as investor information.
Current Falcon 9 launch costs are approximately $1,400/kg to LEO. Starship, at scale, is projected to bring that down to $100–500/kg — a 3–14 times reduction. ABI Research estimates orbital data centres cost upward of 78 times more than terrestrial equivalents today. That gap only closes if launch costs fall dramatically. Google’s feasibility threshold is $200/kg, projected around 2035.
For most organisations, orbital compute is a watch-list item, not a planning factor, for 2026–2029. The evidence for putting it on the watch list is strong: $3 billion-plus in ODC ecosystem funding, credible operators, real FCC filings, and the Anthropic demand signal. The evidence for making it an active planning factor isn’t there yet: no commercial enterprise SLAs exist, no regulated-industry workload case studies have been published, and Starship launch economics remain a 2028–2030 prospect at best.
Axiom Space Orbital Data Centre Nodes — The First Commercial Launch in January 2026On 11 January 2026, a SpaceX Falcon 9 lifted off from Vandenberg Space Force Base carrying the first commercially operated standalone compute units in orbit. Not a research experiment. A commercial service offering.
What changed in January 2026 is that Axiom Space crossed the line from announced to operational. The nodes are running on Kepler Communications satellites in low-Earth orbit, and workloads can be submitted right now. Is this real, and should you care? Yes and yes — with caveats. We’ll cover what launched, what workloads are viable, how the hardware and software work, and what the Axiom milestone does and does not prove. For the bigger picture, that sits in the computing beyond the grid story.
Two ODC nodes launched aboard Kepler Communications satellites on 11 January 2026. Each Kepler carrier satellite weighs roughly 300 kg and carries multi-GPU compute modules, terabytes of on-board storage, and four optical terminals — compatible with Space Development Agency Tranche 1 standards running at 2.5 Gbps per link.
Here’s the progression: in 2022, AWS Snowcone became the first commercial AI inferencing hardware on the ISS. In August 2025, Axiom deployed AxDCU-1 — a prototype sponsored by the ISS National Laboratory, running Red Hat Device Edge and MicroShift. The January 2026 Kepler-hosted nodes are the standalone successor — commercial infrastructure, not a NASA-hosted experiment.
Operating altitude is around 400 km — low-Earth orbit (LEO) — giving you roughly 5–20 ms round-trip latency versus ~600 ms for geostationary orbit. One transparency note: Axiom hasn’t publicly released per-node performance specs or customer names. Everything here is sourced from ISS National Lab press releases, Axiom product announcements, and Kepler’s technical filings.
At current kW-scale, the viable categories are: AI/ML inference, Earth observation data fusion, satellite telemetry processing, and sovereign cloud compute. That list is short and deliberate.
AI training is out. Training large models requires roughly 7.2 Tbps of GPU interconnect bandwidth. Current optical inter-satellite links deliver around 100 Gbps — one to two orders of magnitude short. Inference on pre-trained models fits. Training does not.
Earth observation is the primary demand driver. The raw data from a single imaging pass can exceed ground downlink capacity. Process on-orbit — filter, compress, analyse — and you cut result latency from hours to minutes. Planet Labs is already doing this with NVIDIA GPUs on their Pelican satellites.
Sovereign cloud is the use case with the strongest near-term consensus. 141 countries have data localisation laws — orbital nodes can process data during an orbital window over a given territory without touching conflicting terrestrial infrastructure. Defence contractors, national space agencies, and financial institutions in data-sensitive markets are already paying attention. That market doesn’t need hyperscaler scale; kW-scale is enough for the right use case.
COTS stands for commercial off-the-shelf — standard, commercially available components rather than custom-designed space hardware. The reason you go COTS is straightforward.
Rad-hard ASICs lag multiple chip generations behind commercial processors. LEO’s radiation environment is manageable with selective shielding on COTS hardware, which means you get near-current GPU performance without the custom design overhead. Starcloud-1 validated that NVIDIA H100 silicon can survive and operate in LEO without a custom redesign.
AxDCU-1 runs Red Hat Device Edge with MicroShift — a lightweight Kubernetes distribution stripped to a single-node footprint. Automated rollback is built in: if an update fails validation during a contact window, the system reverts without ground intervention. The abstraction layer is familiar; it’s the contact window scheduling, radiation-induced bit flips, and thermal cycling that require orbital-specific middleware not found in standard Kubernetes.
SWaP stands for Size, Weight, and Power — the three physical constraints that define what hardware can go on a satellite. Kepler’s ~300 kg satellites have a limited payload envelope; a standard DGX server rack does not fit. Launch costs run approximately 1, 500–2,500 per kilogram to LEO, so every kilogram is expensive. Solar panels on a LEO satellite are limited — current nodes operate at kW-scale while terrestrial hyperscaler racks run at megawatt scale. That gap defines the workload envelope. Everything comes back to SWaP.
ABI Research estimates an ODC can cost upward of 78x more than a terrestrial equivalent. Starcloud-3, contingent on Starship launch economics, is projected to be the first cost-competitive orbital data centre by 2028–2029. The Axiom/Kepler nodes prove the concept is operational. The scale story is what comes next.
There’s no air in orbit, which means convective cooling — fans, liquid cooling, the majority of heat removal in terrestrial data centres — doesn’t work at all. The only viable mechanism is radiative cooling: passive panels that re-radiate heat as infrared radiation into space.
To radiate just one megawatt at 20°C, an orbital data centre needs roughly 1,200 square metres of radiator surface — four tennis courts. Compute density is thermally limited by radiator surface area, not just power budget.
LEO thermal cycling adds further complexity: ~90-minute orbital periods alternating between direct solar heating and deep cold (~−150°C). For a full treatment of radiative cooling constraints, ART006 covers the physics in depth.
Here’s what is documented and operational: COTS hardware with containerised software can survive LEO. Earth observation and AI inference workloads are viable at kW-scale. A developer can deploy a containerised workload to orbit using familiar tooling.
Here’s what it does not prove: cost-competitiveness with terrestrial cloud, scale to training capacity, or SLA commitments that match enterprise expectations. The Axiom deployment is one data point within a broader alternative computing landscape that spans underwater facilities, orbital solar concepts, and purpose-built hardware platforms.
SpaceX’s own S-1 pre-IPO filing states orbital AI compute “involve[s] significant technical complexity and unproven technologies, and may not achieve commercial viability” — from the same company that called space data centres a no-brainer at Davos three months earlier. That tension isn’t noise. It’s an accurate description of where orbital compute sits on the maturity curve.
No operator has published per-inference or per-GB cost figures. The honest planning frame: put orbital compute on a 3–5 year watch list. It’s not an immediate procurement option.
The Axiom/Kepler deployment is Tier 1: kW-scale, single-node inference, OISL relay. It proves the concept is operational.
Tier 2 is announced but not deployed. Starcloud’s planned 88,000-satellite constellation raised $170 million in April 2026, with AWS, Google Cloud, NVIDIA, and Crusoe flying hardware on Starcloud-2. SpaceX filed for up to 1 million orbital data centre satellites. The hardware signal is NVIDIA’s Space-1 Vera Rubin Module — up to 25x more AI compute than an H100 for space-based inferencing. See the NVIDIA Space-1 article for the full picture.
The concrete re-evaluation triggers are: Starcloud-3 deployment (2028–2029), any operator publishing real SLA commitments, and per-workload cost dropping to within 10x of terrestrial cloud. When any of those land, move orbital compute from watch list to evaluate. Until then, keep an eye on the broader planning question — not whether orbital compute arrives, but when it becomes a factor for your specific use cases. For a complete overview of orbital, underwater, and alternative computing environments, see our guide to computing beyond the grid.
What is an orbital data centre node?
A purpose-built compute unit on a satellite in low-Earth orbit — processing, storage, and network relay independent of terrestrial infrastructure. Think of it like edge computing: you’re processing at the data source rather than shipping everything to a remote centralised facility. No convective cooling, no persistent power grid, no physical access.
Is the Axiom Space orbital data centre actually operational or still experimental?
Operational. Two nodes launched 11 January 2026 on Kepler Communications satellites as a commercial service offering. The January 2026 nodes are the first standalone commercial deployment. “Operational” means workloads can be submitted — it does not mean published SLA commitments or cost parity with terrestrial cloud.
What software runs on an orbital data centre node?
Red Hat Device Edge with MicroShift — a lightweight Kubernetes distribution for resource-constrained environments. Workloads are deployed as containers, the same way you’d deploy to a terrestrial edge node. Automated rollback and delta updates work over-the-air.
Why can’t you just put a standard GPU server in orbit?
SWaP constraints. A standard DGX server weighs hundreds of kilograms and requires active liquid cooling — neither fits a ~300 kg satellite payload envelope or a vacuum environment. Launch costs of 1, 500–2,500/kg make every kilogram expensive, and passive thermal radiators limit compute density.
What is the latency of an orbital data centre compared to a terrestrial one?
LEO nodes at ~400 km altitude have round-trip latency of roughly 5–20 ms. GEO at ~36,000 km has ~600 ms, making it unsuitable for latency-sensitive workloads. Persistent low-latency connections aren’t available from a single node without a constellation relay architecture.
Can you train AI models in orbit?
Not at current kW-scale. Training requires ~7.2 Tbps of GPU interconnect bandwidth; current optical inter-satellite links run at ~2.5–100 Gbps — a gap of one to three orders of magnitude. Inference is viable. Training is not.
What is the sovereign cloud use case for orbital data centres?
141 countries have data localisation laws. Orbital nodes can process data during an orbital window over a given territory without routing through conflicting terrestrial infrastructure. This has the strongest near-term commercial consensus among defence contractors, national space agencies, and financial institutions in data-sensitive markets.
How is an orbital node different from a satellite with onboard processing?
Commercial access and software abstraction. Purpose-built satellites are designed for one mission. ODC nodes are general-purpose compute infrastructure that any authorised customer can submit workloads to — the containerised OS layer enables multi-tenant, multi-workload operation.
Who are the main competitors to Axiom Space in orbital data centres?
Starcloud: 88,000-satellite constellation, $170M Series A in April 2026, AWS/Google Cloud/NVIDIA/Crusoe on Starcloud-2. SpaceX: FCC application for up to 1 million ODC satellites. Google Project Suncatcher: TPU clusters in orbit, test satellites planned early 2027. OrbitsEdge: first orbital demonstration planned 2026. Blue Origin: FCC application for 51,600 data centre satellites.
What happens to an orbital node if a software update fails?
Red Hat Device Edge supports automated rollback: if a delta update fails validation, the system reverts to the previous known-good state without ground intervention. Contact windows are limited to minutes per pass — a failed update could leave a node in an inconsistent state for hours.
What is the contact window constraint for orbital data centres?
A LEO node at ~400 km is within line-of-sight of any given ground station for approximately 5–10 minutes per ~90-minute orbital pass. Workloads must be queued before the window and results relayed via optical intersatellite links (OISL). Kepler’s OISL constellation partially addresses this by relaying between nodes.
How does heat dissipation work on an orbital data centre node?
Convective cooling doesn’t work in vacuum. Thermal radiators — passive panels that re-radiate heat as infrared radiation — are the only viable cooling mechanism. LEO thermal cycling (solar heating to ~−150°C cold over ~90-minute orbital periods) adds engineering complexity. Waste heat, not power, is described as the binding constraint on high-density orbital compute.
Computing Beyond the Grid — Orbital, Underwater, and Alternative Data Centres ExplainedTerrestrial data centre expansion is running into a wall. US data centres now consume 4.4% of national electricity. Grid interconnection queues in Northern Virginia stretch past a decade, and community opposition to gigawatt-scale hyperscaler campuses has made that timeline worse. AI power demand is on a trajectory that outpaces everything utilities are planning to build. That wall is why, in the first 90 days of 2026 alone, eight organisations filed plans, launched hardware, or committed major funding to compute environments outside the terrestrial grid — orbital nodes on low Earth orbit (LEO) satellites, sealed pressure vessels on the ocean floor, and remote edge installations.
This hub maps the full territory. It links to seven in-depth cluster articles covering each facet of the alternative data centre landscape. The orbital market is projected to reach $39B by 2035 at 67% CAGR; the underwater market is growing from $3.2B in 2025 toward $14.8B by 2034. Neither figure tells you whether any of this matters for your infrastructure planning yet — that is what the articles are here to answer.
Use the table below to go straight to the topic you need, or read through each section for a full map of the territory.
| Article | One-Sentence Description | Slug |
|---|---|---|
| Axiom Space Orbital Data Centre Nodes | The first two commercial orbital data centre nodes were deployed to the ISS in January 2026 — here is what they do and what they prove. | /axiom-space-orbital-data-centre-nodes-first-commercial-launch-january-2026 |
| SpaceX Million-Satellite FCC Filing | SpaceX filed for a million-satellite orbital compute constellation — alongside frank S-1 warnings about technical risk. | /spacex-million-satellite-fcc-filing-orbital-data-centre-plans-at-scale |
| NVIDIA Vera Rubin Space-1 | NVIDIA’s space computing hardware line — from the Jetson Orin flying today to the Space-1 Vera Rubin module arriving in 2027. | /nvidia-vera-rubin-space-1-hardware-behind-orbital-ai-compute |
| China Underwater Data Centres and Project Natick | China is commercially running the underwater data centre concept Microsoft proved but did not monetise. | /china-underwater-data-centres-microsoft-project-natick |
| Power from the Sky | Orbital solar irradiance is 10–40× terrestrial — here is what that means for the data centre cost equation, and when the economics close. | /power-from-the-sky-orbital-solar-energy-data-centre-cost-equation |
| Physics of Alternative Cooling | Vacuum radiative cooling and seawater passive heat exchange: why both environments offer structurally better PUE than terrestrial DCs. | /physics-alternative-data-centre-cooling-orbital-vacuum-ocean-thermal |
| When Alternative DCs Become a Planning Factor | A framework for deciding when orbital and underwater data centres move from watch list to infrastructure roadmap. | /when-orbital-underwater-data-centres-become-infrastructure-planning-factor |
Alternative data centres (ADCs) are computing facilities deployed outside the conventional terrestrial power grid — orbital nodes on LEO satellites, sealed pressure vessels on the ocean floor, and remote edge installations. They are converging in 2026 because the constraint is the same for all three: grid capacity cannot keep pace with AI power demand, and community opposition to new on-grid construction has extended interconnection timelines to a decade or more in major US markets. Orbital compute exploits near-continuous solar energy and vacuum cooling; underwater compute exploits passive seawater heat exchange.
The cooling physics that make both environments viable are covered in the physics of alternative data centre cooling.
Two commercial orbital data centre nodes are operational, deployed by Axiom Space to the ISS on 11 January 2026 — kW-scale edge nodes running cloud computing, AI/ML inference, data fusion, and cybersecurity workloads on commercial off-the-shelf (COTS) hardware. Starcloud launched its first satellite in November 2025: a 60 kg spacecraft with a single NVIDIA H100 GPU, the first to train a large language model entirely in orbit. Deloitte’s Project Constellation followed in March 2026.
The ISS nodes manage tens of kilowatts. An AI data centre needs megawatts. That gap is the primary engineering constraint of the field.
The full account of what Axiom Space deployed and what ran on it is in Axiom Space Orbital Data Centre Nodes — The First Commercial Launch in January 2026.
SpaceX filed FCC application SAT-LOA-20260108-00016 in January 2026 for a constellation of up to one million satellites with onboard AI compute capability. In May 2026, Anthropic signed an agreement expressing interest in multiple gigawatts of orbital AI capacity — the first AI-native company to signal hyperscale ODC demand. SpaceX’s own S-1 risk disclosures describe “significant technical complexity and unproven technologies” and note that orbital compute “may not achieve commercial viability.” SpaceX is not alone in this race: Blue Origin has filed for a 50,000+ satellite constellation (Project Sunrise), and Google’s Project Suncatcher is targeting a TPU-equipped demonstration by early 2027.
The Anthropic agreement is the most significant commercial signal to date, but it sits alongside SpaceX’s own frank acknowledgement that the million-satellite ambition has no precedent at this scale. For regulatory and competitive depth, the full analysis of SpaceX’s million-satellite FCC filing covers the filing, S-1 disclosures, and what the Anthropic deal actually commits.
The full regulatory and competitive analysis of the filing is in SpaceX and the Million-Satellite FCC Filing.
NVIDIA announced its Space Computing product line at GTC in March 2026: the Jetson Orin (available now, SWaP-constrained edge), the IGX Thor (Blackwell architecture, available now), and the Space-1 Vera Rubin Module (25× the AI compute of an H100, confirmed 2027 availability). SWaP — Size, Weight, and Power — is the engineering constraint that makes standard DGX server racks non-viable in orbit. A single H100 GPU requires 1.1 m² of radiator area to dissipate heat in vacuum; a full DGX H100 system requires 16 m² (ABI Research). That is not a satellite payload.
Understanding the SWaP tradeoffs is essential before evaluating any orbital compute vendor claim — the NVIDIA Vera Rubin Space-1 hardware breakdown explains the constraints that define what the entire product generation can and cannot do.
The full technical breakdown of Space-1, SWaP constraints, and the six-partner ecosystem — Aetherflux, Axiom Space, Kepler Communications, Planet Labs, Sophia Space, and Starcloud — is in NVIDIA Vera Rubin Space-1 — The Hardware Behind Orbital AI Compute.
Beijing Highlander Digital Technologies (BHDT) / Shenzhen HiCloud is operating a sealed underwater data centre at 35m depth off Lingshui, Hainan Island — a 1,300-tonne pressure vessel targeting 24 MW capacity and claiming a Power Usage Effectiveness (PUE) of 1.07. For context: hyperscalers achieve ~1.1–1.2; traditional data centres average ~1.5–1.6; theoretical minimum is 1.0. Microsoft ran Project Natick trials successfully from 2018 to 2020 and did not commercialise. China’s domestic AI compute demand created unit economics that did not exist in Microsoft’s market context — the technology was proven; the commercial conditions were not. BHDT is on the US entity list. Subsea Cloud’s Jules Verne pod near Port Angeles, WA, is the US-based alternative.
The PUE 1.07 figure is the key benchmark — and understanding why China could reach it commercially while Microsoft could not is the subject of the comparative analysis of China’s underwater data centres and Project Natick.
The full comparative analysis is in China’s Underwater Data Centres and What Microsoft Abandoned with Project Natick.
Low Earth orbit receives solar irradiance of approximately 1,361 W/m² — no atmospheric absorption, no weather, drastically reduced night cycles — delivering 10–40× the energy density of ground-based solar. That is a measurable input-side advantage with no grid dependency. ABI Research estimates orbital compute costs 78× more than terrestrial equivalents today; Google’s Project Suncatcher research sets $200/kg as the launch cost threshold at which parity becomes credible, projected around 2035. One important counterpoint: research from Saarland University, reported in Scientific American, finds that counting full lifecycle emissions — rocket propellant, satellite manufacturing, atmospheric reentry — could make orbital data centres an order of magnitude worse on greenhouse gas terms.
All of that solar energy becomes heat the moment compute hardware processes it — which is where the cooling physics matter as much as the power economics. The full analysis is in Power from the Sky — Orbital Solar Energy and the Data Centre Cost Equation.
In orbit, heat can only leave a system by infrared radiation — every watt of waste heat requires radiator surface area. Underwater, sealed pressure vessels conduct waste heat through the hull to ambient seawater — a passive heat sink whose capacity far exceeds any data centre load at current scales — eliminating HVAC entirely. Cooling accounts for roughly 40% of traditional data centre energy overhead, so removing it restructures the entire energy budget. China’s Hainan facility achieves PUE 1.07 at 24 MW — the seawater advantage is commercially proven today. Orbital vacuum cooling achieves better theoretical PUE but is currently constrained to kW-scale deployments.
The full thermodynamic comparison, including PUE tables and radiator sizing, is in The Physics of Alternative Data Centre Cooling — Orbital Vacuum and Ocean Thermal.
For most organisations in 2026, alternative data centres belong on the watch list. The ABI Research 78× TCO premium is the quantitative basis for that answer. The conditions that change it are measurable: Starship reaching commercial flight frequency, launch costs below $200/kg, NVIDIA Space-1 shipping, and a draft SOC 2 or GDPR framework for orbital workloads. The Anthropic/SpaceX compute agreement (May 2026) — the first hyperscaler-level demand signal from an AI-native company — is a signal to track, not act on. The compliance blocker with no current answer: no jurisdiction governs data processed in orbit — a hard blocker in 2026 for any organisation handling regulated data. Atomic-6 / ODC.space is the closest thing to a purchasable product today: a sovereign rack at $3.5M/month with 2–3 year delivery.
The full decision framework — watch-list criteria, compliance gap analysis, and 24-month tracking signals — is in When Orbital and Underwater Data Centres Become an Infrastructure Planning Factor.
An orbital data centre is a computing facility mounted on satellites in low Earth orbit, powered by solar energy and dissipating waste heat via infrared radiation to the vacuum of space. The first two commercial nodes were deployed to the International Space Station by Axiom Space on 11 January 2026. For full operational detail: Axiom Space Orbital Data Centre Nodes.
The terms are used interchangeably in mainstream coverage. “Orbital data centre” (ODC) is the preferred industry and analyst term — used by ABI Research, NVIDIA, and SpaceNews; “space data center” and “space-based computing” appear more often in consumer tech coverage. This hub uses “orbital data centre” throughout; both terms describe the same category.
kW-scale edge deployments — Axiom Space’s ISS nodes, Kepler Communications’ 10-satellite cluster — are operational today, handling AI inference and data fusion at power levels a single satellite can sustain. MW and GW-scale ambitions (Starcloud-3, SpaceX’s million-satellite constellation, Google Project Suncatcher) require Starship launch economics and radiator arrays that do not yet exist at commercial scale. Conflating these two tiers is the most common error in mainstream coverage of this topic. The orbital AI hardware roadmap — from Jetson Orin to Space-1 — illustrates exactly where the capability gap sits today.
ABI Research estimates orbital compute costs approximately 78× more than terrestrial equivalents today. Cost convergence is projected around 2035, contingent on Starship reaching commercial launch frequency and driving costs below $200/kg — the threshold Google’s Project Suncatcher research identifies as the break-even point. For the full economic analysis: Power from the Sky.
The honest answer is contested. The solar power advantage is real — orbital irradiance of 1,361 W/m² with no atmospheric losses delivers 10–40× the energy density of ground-based solar. But research from Saarland University, reported in Scientific American, finds that counting full lifecycle emissions — rocket propellant combustion, satellite manufacturing, and atmospheric reentry — orbital data centres could generate an order of magnitude greater greenhouse gas emissions than terrestrial equivalents. Both findings are credible and should inform any ESG evaluation.
There are none — because no framework currently exists. SOC 2, GDPR, HIPAA, and FedRAMP do not address orbital workloads. The jurisdictional question of which country’s law governs data processed in orbit is legally unresolved. For organisations in regulated industries, this is a hard blocker in 2026. For the full compliance gap analysis: When Orbital and Underwater Data Centres Become an Infrastructure Planning Factor.
Latency-tolerant, compute-heavy, parallelisable processing: Earth observation AI, cybersecurity analytics, data fusion for satellite-native datasets. Orbital AI inference — running pre-trained model inference where each request is independent — is viable at kW-scale edge nodes today. Distributed LLM training, which requires tightly coupled multi-GPU systems, is a 2030s capability. The China Hainan underwater data centre demonstrates what commercially viable alternative data centre workloads look like at scale today — 24 MW at PUE 1.07, running AI inference and data processing that does not require orbital positioning.
The category is real, the deployments are small, and the economics are not there yet. What changes that verdict — and the timeline for when it changes — is laid out in When Orbital and Underwater Data Centres Become an Infrastructure Planning Factor. If you want the engineering foundation first, start with the physics of cooling. If you want the proof that this is happening, start with what Axiom Space launched in January 2026.
Spec-Driven Development and the End of Vibe Coding — What Engineering Leaders Need to KnowIn April 2026, a production disruption at Amazon — linked by analysts to an agentic coding session that misconfigured access controls — pushed AI coding governance onto engineering leadership’s agenda. Agentic AI coding tools had become powerful enough to do real damage without formal constraints. The response that has gained the most traction is spec-driven development (SDD): a methodology where structured specification documents, written before any code is generated, serve as the binding contract for AI agents.
This page answers the broad questions in plain terms and points you to the dedicated articles for the depth you need.
In this series:
Spec-driven development is a methodology where structured specification documents — written before any code — serve as the source of truth for AI agents that then generate, validate, and iterate on the implementation. Unlike vibe coding, where prompts generate code with minimal formal constraints, SDD enforces scope boundaries, architectural decisions, and verification criteria from the outset. It gained commercial traction in 2025–2026 as autonomous AI agents became powerful enough that undirected prompting started producing costly failures in production.
Its intellectual lineage runs through formal methods (Hoare, Meyer) and industrial practitioners, but the urgency is new — Thoughtworks placed it in the Assess ring of their 2025 Tech Radar as a genuine maturation phase, not a rebranding. The methodology sits in direct lineage with TDD and BDD: specs govern AI agents the way tests govern interfaces.
For the full diagnostic case — why the shift is happening now and what the documented failure modes look like — see the vibe coding failure-mode analysis.
Vibe coding — coined by Andrej Karpathy in February 2025 — describes the practice of using natural language prompts to generate complete application code with minimal structured constraints or review. SDD is the counter-pattern: it front-loads the definition of outcomes, scope boundaries, and verification criteria in a formal specification before any code is generated. The spec acts as a persistent contract the agent must satisfy; vibe coding provides no such contract.
Karpathy was candid about what vibe coding was designed for: “I ‘Accept All’ always, I don’t read the diffs anymore” — and he flagged it explicitly as “not too bad for throwaway weekend projects.” The problems emerged when teams applied the same approach to production systems. Hallucinated APIs, mixed library versions, and unintended side effects followed. The distinction is not about tools — you can run a vibe coding session and an SDD session in the same IDE. It is whether a formalised spec governs the agent’s work.
The full failure-mode breakdown covers why production deployments diverge from prompt intent.
In April 2026, a 13-hour production disruption at Amazon was linked — by The Register (29 April) and Aragon Research — to an agentic coding session that misconfigured access controls. Amazon officially classified the event as “user error” and denied direct involvement by its Kiro IDE, but the incident prompted an internal mandate: all AI-generated code must be reviewed by an engineer before it is accepted. Amazon’s official position and the analysts’ framing remain in tension.
Aragon Research’s assessment was direct: “The primary driver behind these incidents was the deployment of agentic AI tools… granted broad permissions that allowed autonomous actions to bypass traditional human-in-the-loop safeguards.” The outcome was Amazon’s mandatory review policy: “Nothing ships without someone looking at it and validating it. Spec-driven development helps reduce how much time that takes” (Steve Tarcza, Amazon Stores).
The full timeline, with sourcing, is in Amazon’s Internal Probe — What AI Coding Outages Reveal About Production Risk.
AWS Kiro is Amazon’s agentic IDE — built on Code OSS, the VS Code base — that enforces a three-phase spec workflow before any code is generated: requirements.md (user stories in EARS notation), design.md (architecture decisions), and tasks.md (testable implementation units). Agent Hooks extend the IDE with event-driven automations that fire on file save, handling tasks such as test updates and security scans without manual prompting. Kiro replaced Amazon Q Developer (EOL announced April 30, 2026) as AWS’s primary AI coding product.
EARS (Easy Approach to Requirements Syntax) is the structured format Kiro uses for acceptance criteria — it produces machine-parseable requirements that cover edge cases by default. Steering Files embed compliance standards and architectural non-negotiables as persistent context the agent always references. Kiro does not require an AWS account, is built on VS Code so the environment is familiar, and has GovCloud availability for regulated verticals.
For the full three-phase workflow, Agent Hooks configuration, and a Kiro-versus-Cursor evaluation, see AWS Kiro — Amazon’s Spec-First Bet on Agentic Development.
GitHub SpecKit is an IDE-agnostic, open-source Python CLI framework with 93,000+ GitHub stars (v0.8.7, May 2026) that runs a four-phase workflow: Specify, Plan, Tasks, Implement. Its key differentiator is the “constitution” — a persistent, project-wide principles document that governs every agent session across tools, comparable to an ADR or RFC in function. Kiro mandates its three-phase workflow inside a VS Code environment; SpecKit’s governance layer works with any compatible agent, including Claude Code, Gemini CLI, and GitHub Copilot.
The choice between them often resolves on stack. Microsoft-ecosystem teams — Copilot, Azure DevOps — align naturally with SpecKit. AWS-native teams lean toward Kiro. SpecKit’s IDE-agnostic design is its portability argument; Kiro’s deeper IDE integration enables Agent Hooks that SpecKit cannot replicate natively. Both enforce spec-first discipline; neither is objectively superior — they suit different organisational contexts.
The constitution concept, SpecKit’s four-phase workflow in practice, and a full Kiro comparison are all covered in GitHub SpecKit and the Microsoft Approach to AI Coding Governance.
The primary evaluation axis is brownfield versus greenfield. For new projects, AWS Kiro and GitHub SpecKit are the vendor-backed starting points. For existing codebases, OpenSpec‘s delta-marker workflow (ADDED/MODIFIED/REMOVED) is designed specifically for change-scoped specs. BMAD-METHOD (46,700+ GitHub stars) suits complex multi-agent orchestration; GSD (61,000+ GitHub stars) is a leaner alternative for Claude Code users who want meta-prompting without ceremony. Cursor Plan Mode is a low-friction entry point for teams not yet ready for a full framework.
Three tiers organise the landscape: vendor-backed (Kiro, SpecKit), community-led (BMAD, GSD, Cursor Plan Mode), and niche-optimised (OpenSpec for brownfield, Tessl for API hallucination prevention). Per-feature cost signals from RanTheBuilder (February 2026): BMAD Full at ~200, OpenSpecat 95, SpecKit at ~$75. Most teams need to assess only the 2–3 frameworks that match their codebase type and existing toolchain.
The three-tier comparison with per-feature cost data and the brownfield/greenfield decision guide are in The 30-Plus Framework Landscape — Navigating Spec-Driven Development Options in 2026.
The principle — articulated most clearly by Prezi engineers and the specdriven.com community — holds that when a specification is detailed enough to constrain an AI agent’s output completely, it is functionally equivalent to code. Code becomes a generated artifact; the spec is the deliverable. This is the spec-as-source end of Martin Fowler’s three-level taxonomy (spec-first, spec-anchored, spec-as-source) and represents the philosophical north star of the SDD movement.
Spec Drift — the divergence between a spec and the actual codebase over time — is the failure mode the principle is designed to prevent. Living specs, which auto-update as agents complete work, are the practical response. See A Sufficiently Detailed Spec Is Code — The Community Principle Behind Spec-Driven Development for the TDD/BDD/MDD lineage and an honest account of where the current frontier sits.
No — but the concern is legitimate and worth addressing directly. Waterfall front-loads all specification work before any execution begins and treats the spec as a fixed contract. SDD treats the spec as a living document that evolves with the project; implementation begins incrementally from task-level specs, not a completed requirements freeze. The key structural difference: SDD specs govern AI agents continuously, not human developers once at the start of a project.
The “big upfront specification” critique applies to the spec-as-source end of the spectrum — the most radical position. Most practitioners operate at spec-first or spec-anchored, where the process is iterative within a feature or change scope. The TDD parallel is useful: tests drive development iteratively; specs do the same at the architecture and scope level.
A Sufficiently Detailed Spec Is Code addresses the lineage and the antipattern critique in full.
The EU AI Act‘s full enforcement deadline is August 2, 2026. For organisations deploying high-risk AI systems — which includes many AI-assisted development workflows in FinTech, HealthTech, and government — Articles 9–17 (provider obligations), Article 26 (deployer obligations), and Article 50 (AI content disclosure) create documentation and traceability requirements. Spec-driven workflows produce the compliance artifacts these articles require: a structured audit trail, human-oversight records at each review checkpoint, and AI authorship attribution in version control.
The AugmentCode compliance evaluation (May 2026) ranks tools by EU AI Act posture: Intent (Augment Code) and Claude Code at Tier 1; Kiro at Tier 2 (partial); Cursor at Tier 3. ISO/IEC 42001 and SOC 2 Type II certification are the credibility signals to look for when evaluating tools for regulated environments. The April 2026 AWS incident has elevated this from a compliance checkbox to a board-level accountability question.
EU AI Act article citations, the full compliance matrix, and an August 2026 action checklist are in Spec-Driven Development in Regulated Industries — Governance, Compliance, and Audit Trails.
At minimum: establish a human-in-the-loop review policy for all AI-generated code before it is merged or deployed. Amazon’s internal mandate after the April 2026 incident is the operational baseline — “nothing ships without someone looking at it.” Beyond that, introduce a specification layer (even a lightweight CLAUDE.md or project rules file is a starting point) and select a framework matched to your codebase type and team size before scaling agentic workflows.
Human-in-the-loop (HITL) governance is not just best practice — EU AI Act Article 14 mandates it for high-risk AI systems. Start there regardless of which framework you adopt. A full framework adoption — Kiro, SpecKit, BMAD — is the next step once your team has validated the spec-review loop on a contained project.
For tool evaluation, see The 30-Plus Framework Landscape. For governance and compliance specifics, see Spec-Driven Development in Regulated Industries. For the incident that drove Amazon’s policy, see Amazon’s Internal Probe.
An agentic IDE is a development environment where the AI model operates as an autonomous agent — planning, implementing, and iterating across multi-step tasks with minimal mid-task prompting, rather than responding to individual queries. AWS Kiro is the highest-profile current example. For a full evaluation, see Kiro’s three-phase spec workflow and Agent Hooks.
TDD uses unit tests to drive interface design at the code level. SDD operates at a higher architectural layer — the spec defines outcomes, scope, and constraints before any tests or code are written. The two are complementary: an SDD workflow typically produces tests as part of the task list, which are then driven by TDD at implementation. A Sufficiently Detailed Spec Is Code traces the full TDD/BDD/MDD lineage.
Context engineering is the discipline of curating which information AI agents receive — providing precise, task-relevant context rather than exposing them to a full repository. Thoughtworks identifies it as the operational complement to SDD: the specification defines what the agent must achieve; context engineering defines what the agent is allowed to see. It is distinct from prompt engineering, which optimises human-to-LLM interaction.
For teams below about five engineers on a greenfield project with a contained scope, a lightweight approach — a project constitution file (CLAUDE.md or equivalent) plus a structured task list — captures most of the benefit without the overhead of a full framework. The overhead of a framework like BMAD or Kiro pays off when multiple agents run in parallel, when the codebase is large, or when compliance requirements mandate an audit trail.
BMAD-METHOD (Build More Architect Dreams) is an open-source multi-agent orchestration framework with 12+ specialised agent roles and 46,700+ GitHub stars. OpenSpec is a proposal-centred workflow designed for brownfield codebases, using delta markers (ADDED/MODIFIED/REMOVED) to scope specs to the change rather than the full system. GSD (Get Shit Done) is a lean, low-ceremony meta-prompting framework built primarily for Claude Code. All three are compared in The 30-Plus Framework Landscape.
Kiro’s official documentation and download are at kiro.dev. For an independent technical walkthrough of the three-phase spec workflow, Agent Hooks, and Steering Files — without the marketing framing — see the independent Kiro technical review.
Whether your starting point is a lightweight project constitution or a full framework adoption, the spec-review loop is the minimum viable governance layer for any team running AI agents in production.