The European orbital compute thesis

Why the next data centre is in orbit, why it has to be European, and what we're building. ~6 minutes.

Why this

The physics, the latency, the energy, the regulatory window

The opportunity is not "build another data centre". It's "build the data centre in the only place the physics, the economics, and the regulation all point to."

The physics

Above the atmosphere, three things change at once.

  • ☀️ Solar is roughly 8× more productive than at ground. No clouds, no night, no seasonal swing. A solar array in LEO delivers, per square metre, what a desert ground array delivers in a few minutes of clear noon — averaged over 24 hours.
  • 🌡️ Heat sheds by radiation. No chillers, no water, no fans. A black radiator panel pointed at deep space is a passive heatsink. The thermal bottleneck on the ground (water rights, chillers, hot-aisle containment) is gone.
  • 🛰️ Vacuum is free insulation. No convective losses, no humidity, no corrosion. Hardware that lasts 5 years on the ground can last 15+ in orbit (radiation is the new limit, not heat).

The binding constraint on the ground — power, cooling, density — is not the binding constraint in space. The binding constraint in space is energy delivered to compute. That's a different problem, and it's a better one.

graph LR
  A["☀️ Solar
(8× ground yield)"] -->|"photovoltaics"| B["⚡ DC bus
(battery for eclipse)"] B -->|"regulated rails"| C["🧠 Compute
(GPU / accelerator)"] C -->|"waste heat"| D["🌌 Radiator
(deep-space sink)"] D -.->|"passive cooling"| C classDef src fill:#0f172a,stroke:#34d399,color:#e2e8f0; classDef sink fill:#0f172a,stroke:#38bdf8,color:#e2e8f0; class A,B,C src; class D sink;

The latency

Ground compute is far from space data. Earth-observation, space-situational-awareness, and in-orbit telecom produce data at the speed of light in vacuum. The bottleneck is the last hop — downlink to a ground station, ingest into a ground data centre, then up again to a user. The downlink is the slowest leg, and it gates the whole pipeline.

Orbital compute collapses that last hop. Process the data on-board, push only the answer (or the relevant slice) to the ground. The math: LEO is roughly 4–12 ms RTT; MEO is ~50–80 ms; GEO is ~600 ms; a ground round-trip to a ground data centre from a remote site is ~150–400 ms plus the downlink. The orbital tier is faster than the ground tier, for space data, by an order of magnitude.

The energy arithmetic

A modern data-centre GPU draws 700–1,200 W at full load. A satellite's solar array delivers 2–10 kW continuous in LEO, 15–30 kW in MEO, >50 kW in GEO (more always-sun). A single LEO node can host 2–8 accelerators at full duty-cycle. A MEO node can host 10–20. The energy budget is the design constraint, not the GPU.

The regulatory window

The International Telecommunication Union (ITU) is ratifying in-orbit compute as a new service category in the 2027 World Radiocommunication Conference cycle. The European Union's EU Space Law (adopted 2024, in force 2025) is the first jurisdictional framework that treats orbital compute as a sovereign infrastructure — not a satellite operator, not a data-centre operator, but a new class with its own licensing, its own data-residency rules, and its own export-control regime. The standards are being written right now. A European operator that is at the table when the standards land will own the lane for the next decade.

The deep dive on each of these — satellite bus design, compute inference at the edge, EU Space Law mechanics — is on the tech page.

Why now

The 2025–2027 phase shift, and the 18-month window

The orbital-data-centre thesis is no longer a thought experiment. The phase shift happened between late 2025 and early 2026. The architectures are being designed right now. The window for Europe to pick a lane is the next 18 months.

What changed in the last 12 months

  • 🚀 Starcloud trained an LLM in space (December 2025, NVIDIA H100 in orbit, published peer-reviewed paper in Nature Electronics, October 2025).
  • 🛰️ Axiom Space launched the first two orbital data-centre nodes to the ISS (January 11, 2026).
  • 🌐 Kepler Communications put up the first commercial orbital-compute cluster.
  • 🛰️ Google "Project Suncatcher" announced an 81-satellite TPUs-in-LEO constellation for early 2027.
  • 🇪🇺 ESA and the European Commission started publishing position papers on "orbital compute" as a sovereign infrastructure category.

In twelve months, orbital compute has gone from a slide in an ESA briefing to a product with customers, revenue, and a launch manifest. The first movers are locking in their architectures, their spectrum, and their launch slots.

The timing curve

Three curves are converging. The first is the cost per kilogram to LEO (SpaceX Falcon 9 + Starship driving a 10× reduction over five years, with no sign of slowing). The second is AI model size and inference demand (the compute bill for state-of-the-art models roughly doubling every 9 months). The third is the regulatory window (the EU Space Law + ITU 2027 cycle defining the lanes for the next decade).

graph TD
  T1["💸 Launch cost
(−10× in 5y)"] --> WINDOW T2["🧠 AI demand
(×2 every 9 months)"] --> WINDOW T3["⚖️ Regulatory window
(EU Space Law + ITU 2027)"] --> WINDOW WINDOW["🎯 18-month window
(2026 → mid-2027)
architectures lock in"] classDef inf fill:#0f172a,stroke:#fbbf24,color:#e2e8f0; classDef win fill:#0f172a,stroke:#34d399,color:#0a0e1a; class T1,T2,T3 inf; class WINDOW win;

The cost curve has flipped: the marginal cost of putting a GPU in orbit is now below the marginal cost of building a new ground data-centre hall (once you price the grid hookup, the water, the cooling, and the 5-year permitting). The demand curve has not slowed: if anything, the inference-side explosion (Sora-class video, real-time speech, agentic workloads) is accelerating the need for compute that sits next to the data, not on the other side of a fibre hop.

The regulatory window is the shortest of the three. Once the ITU and the EU ratify the standards, the orbital lanes, the spectrum, and the licensing are fixed for a generation. A European operator that is at the table in 2026 owns the European lane in 2030.

Why Europe, specifically

The US operators (Google, Starcloud, Axiom) are moving fast on the US side. There is no equivalent European operator. The European industrial base (OHB, Airbus Defence and Space, EnduroSat, Thales Alenia) is the supply chain — the bus builders, the launch integrators, the ground-segment vendors. The operator layer, the customer-facing tier, the sovereign contract tier, is open. That is the lane.

Why us

Why a young solo founder can win the lane that the primes don't want

The natural investor question. OHB has a 40-year track record, Airbus Defence and Space launches sovereign constellations, EnduroSat has the smallsat supply chain locked, Thales Alenia owns the European ISS modules. They could do orbital compute. Why are we the team that wins this lane?

The honest answer is: the primes are not our competitors for this opportunity. They are our potential customers. And that is the unfair advantage.

1. Focus, not capability

For OHB or Airbus, orbital compute is a one-percent line item in a portfolio of bus-builders, payload-integrators, and defence primes. For us, orbital compute is 100% of the mission. A prime cannot allocate its best engineers, its fastest decision cycles, and its regulatory attention to a market segment that is one line in a 12-segment annual report. We can — and we do.

2. Speed of cycle

Primes run 5–10 year mission cycles. Architecture review in year 1, prime-contract selection in year 2, bus build in years 3–5, launch in year 6, operations in years 7–10. The orbital-compute opportunity is an 18-month window (2026 → mid-2027, before the ITU + EU Space Law standards lock in). The primes cannot move at the speed this market requires even if they wanted to. Their process is the wrong shape for the opportunity.

3. AI-native methodology — the actual unfair advantage

This is the one the primes cannot copy. It is not the hardware (any integrator can buy a GPU); it is not the bus (we will buy the bus from a European prime, and that is fine); it is the methodology. The PhD research at AI4CE — applied to this project as the core design loop — is a deep reinforcement-learning system that explores thousands of mission architectures per hour and converges on designs a human engineering team would not have found. That is what a 30-year engineering culture cannot replicate. A human team without ML in the design loop is the bottleneck; a team with ML in the design loop is the moat.

4. Cost basis

A cubesat-class orbital-compute node delivered to LEO today costs roughly €1.5–3 M all-in (bus + compute payload + launch + ground segment + 1 year of operations). A traditional Eurostar-class GEO platform costs €150–300 M. We are not building a cheaper Airbus; we are building a fundamentally different category of asset at a fundamentally different cost basis. The unit economics of a 50-node LEO constellation are better than a single GEO platform for 80% of the inference workloads that the market is starting to ask for.

5. Honest reframing

The primes are not our competitors. They are our potential integrators (bus vendors, launch brokers, ground-segment operators) or our potential acquirers (if the European sovereign tier consolidates around one operator, the primes will want to own that operator). The market is too small and too new for them to focus on. They will not move on this until a customer contracts it.

We get the market because the primes wait for proven demand. The 18-month window is for venture-funded startups to define the architecture — which orbit altitudes, which SLA profiles, which regulatory lane, which anchor workload. Whoever locks the architecture by mid-2027 sets the standards that incumbents will have to comply with. We are racing for the standard, not the compute market. The compute market follows the standard. That is the position we are playing for.

The credibility stack

What we have already shipped, before raising:

graph TD
  A["🤖 AI4CE PhD research
(deep RL for system generation)
the methodology"] --> US B["🛰️ 11 verified competitor profiles
(primary-source cited)
the landscape"] --> US C["🌐 38-US shipped production site
(this site, live, containerised)
the execution"] --> US D["🛰️ 6-satellite orbital-data-centre
3D simulation
the product"] --> US US["🪪 high machines
(the operator)"] classDef a fill:#0f172a,stroke:#34d399,color:#e2e8f0; classDef b fill:#0f172a,stroke:#38bdf8,color:#e2e8f0; classDef c fill:#0f172a,stroke:#fbbf24,color:#0a0e1a; classDef d fill:#0f172a,stroke:#f472b6,color:#0a0e1a; class A a; class B b; class C c; class D d;

The team is one person today, and the research is the credibility signal. The investor is not buying a payroll — they are buying a methodology, a market map, an execution track record, and a 12-month lead on a window the primes will not enter until a customer contracts it.

"We're not building a cheaper Airbus. We're building a category that didn't exist, and the primes are the supply chain, not the competitor."

The two-layer problem

Why "build another data centre" is not an answer

The constraint is not compute. GPUs are getting cheaper. The constraint is where the compute can physically sit.

Layer 1 — Technical (universal). AI compute scales with power, cooling, and density. On the ground, all three are bounded: power grids by 2030 capacity, water for cooling by regional drought cycles, and physical land by planning permission queues. In space, none of these are bounded. Solar is 8× more productive above the atmosphere (Google's Project Suncatcher data). Heat sheds by radiation — no water, no chillers, no fans.

Layer 2 — Sovereignty (European-specific). Europe's grid is projected to be exhausted for new data centre hookups by 2027–2028. New permitting takes 5+ years. The "build more boxes in Frankfurt" path is closed at the rate the AI build-out needs. And even if space solves the technical layer, a US company in orbit is still under US jurisdiction — CLOUD Act, US corporate decisions, US strategic interests.

The only answer for Europe is a European company, in European law, for European customers, in orbit.

Want the underlying tech? See Satellite hardware and AI hardware on the tech page.

The latency story

Orbital compute is close to the data

The headline of this site — and the reason an orbital data centre matters — is latency. Where the compute sits, relative to where the data is, defines what it can do.

Ground compute is far from space data. Earth-observation, SSA, and in-orbit telecom produce data at the speed of light in vacuum. The bottleneck is the last hop — downlink to a ground station, ingest into a ground data centre, then up again to a user. The downlink is the slowest leg, and it gates the whole pipeline.

Orbital compute collapses that last hop. Process the data on-board, push only the answer (or the relevant slice) to the ground. The chart on this page shows the round-trip latency to the eight reference orbits we'd actually deploy to. The LEO band is fast enough to feel "real-time". The Lagrange points are minutes away — fine for batch, training, and synthesis.

The number to internalise: LEO is ~150× faster than GEO, and ~2 500× faster than the Moon. The further out the orbit, the worse the latency, but the bigger the energy + cooling advantage. The right answer is a tiered architecture: LEO for the latency-sensitive edge, MEO/GEO for the bulk-training tier, L1/L4/L5 for the always-sun, always-cool deep-storage tier.

"The LEO tier is the edge. The Lagrange tier is the data centre. We're building both."

Our approach

European ownership, European law, tiered orbits

We are building a European-owned orbital data centre operator. Three differentiators, each defensible:

  • Ownership. We sit outside the CLOUD Act, outside any state-investor structure, and inside the European regulatory perimeter our customers actually want. Our headline is: a European compute contract stays European, even if the silicon is in orbit.
  • Tiered architecture. One orbit doesn't fit every workload. We design for the workload first, then pick the orbit: LEO edge for real-time, MEO/GEO bulk for training, Sun–Earth Lagrange for the always-sun, always-cool deep tier. The four-tier stack is the IP, not any single satellite.
  • Power-by-design. Solar + radiative cooling is the business model. The first question on every customer call is "what's your power budget?" — because the answer sets the orbit, the constellation size, and the unit economics.

What we're asking for

The 18-month window

The company is at the post-research, pre-architecture stage. The deep-dive is done. The competitive landscape is mapped (11 verified competitor profiles in our research repo). The regulatory path is sketched. The engineering trade-offs are understood.

What we need next:

  • Capital — €2–5M seed to lock the architecture, file the orbital-spectrum applications, and stand up the simulation stack (the "digital twin" of the four-tier orbit constellation). We are not raising for hardware yet.
  • Anchor customer(s) — one European hyperscaler or sovereign-AI programme to underwrite the first-constellation use case. The anchor defines the orbit and the SLA, not the other way around.
  • EU / ESA partnership — for the regulatory, launch, and spectrum-permission work. The technical thesis is European; the regulatory thesis is also European; they should ship together.

The window is the next 18 months. After that, the architectures are standardised, the US players are entrenched, and the sovereignty case becomes harder to make. The reason to move now is the same reason it was the right time for Arianespace in 1980: the technology has matured, the market is forming, and the policy is open.