Computing Among the Stars: When Orbital Datacentres Make Sense

I learned long ago that space and cloud computing attract different breeds of engineers. Space people understand that physics will kill you if you’re careless. Cloud people know that operational reality will destroy your economics at scale. Orbital datacentres demand both kinds of thinking at once, which is precisely why most proposals fall apart. This is my attempt to separate what might actually work from what sounds impressive in a pitch deck.

Three Different Ideas Hiding Behind One Phrase

“Orbital datacentres” gets thrown around like everyone means the same thing. They don’t. Sometimes the conversation is about processing Earth observation (EO) data right where it gets collected, reducing the flood of images pouring down to ground stations. Other times it is about a general-purpose cloud service floating above Earth that competes directly with Amazon or Microsoft on price and performance. Sometimes it is purely about backup storage, keeping critical data off-planet for resilience.

These are not equally viable. Processing data in space where sensors already live? That is genuinely credible in the near term. A full cloud service in orbit that undercuts terrestrial giants? That is a much harder story to make the numbers work on. The difference matters before you invest time or capital in any of these ideas.

Why This Conversation Became Real

Five years ago, this was pure speculation. Today it is becoming testable. Two things collided simultaneously.

On one side, artificial intelligence (AI) demand is consuming datacentre capacity at rates that shock even the most aggressive planners. Electricity grids cannot expand fast enough. Water for cooling is becoming scarcer in critical regions. Getting planning permission for new facilities takes years. Bandwidth and power are the new scarcity. When every terrestrial option hits a wall, people start wondering if space offers something different.

On the other side, space itself changed. Launch vehicles now fly on predictable schedules instead of rare occasions. Manufacturing timelines have compressed. Optical communication links between satellites, once exotic research, are now becoming standard. Governments and major companies started publicly exploring this seriously. The conversation shifted from “is this theoretically possible?” to “what would it actually take?”

Where It Makes Sense Today

Start by looking at problems that are already biting. The patterns emerge quickly.

Earth observation is the clearest case. Satellites image the same areas constantly, capturing the same empty landscape, the same clouds, the same unchanging terrain. Most of that data is worthless. Ground stations get flooded. Downlink bandwidth becomes the limiting factor, not the sensors. Process the images in orbit, filter out the noise, and send only the interesting insights down to Earth. You shrink the bandwidth problem, you speed up the time between observation and action, and you make yourself less dependent on having perfect communication links home. That last point matters more than it sounds. Bandwidth to ground stations is limited. Those stations themselves can be jammed or denied. A spacecraft that does its own thinking becomes more resilient.

Compute services for other spacecraft is another pattern that works. Think of it as edge computing, except the edge is in a vacuum and 400 kilometers up. Instead of every satellite carrying its own processors for every task, nearby spacecraft dial into a compute node when they need processing power. It is a way to distribute capability without distributing all the weight and complexity. The spacecraft that buys the service gets lighter and simpler. The compute provider builds a revenue model around utilization.

Then there is resilience. Keeping important data off-planet for disaster recovery or regulatory compliance is a real use case, but only if you actually integrate it into your disaster playbooks. Backup data sitting in orbit is useless if you have not built the systems to restore from it when everything on the ground catches fire. Done properly, though, it solves a genuine problem for certain high-value information.

The Constraint That Stops Everything Cold

This is where most orbital datacentre pitches die, usually without the presenter realizing it.

People hear “space is cold” and imagine unlimited cooling for free. That is not how it works. In a vacuum, there is no air to move heat around. Your only way to shed heat is through conduction inside your hardware and radiation out into space. Modern processors consume enormous power, and every single watt becomes waste heat you have to get rid of. On Earth, you have options: fans, water loops, evaporative cooling, vast thermal reservoirs in the air and oceans. In orbit, you have radiators.

Radiators are not decoration. They are both area and mass. They determine how the entire spacecraft must be shaped and oriented. They limit how much compute you can run continuously versus short bursts. The International Space Station (ISS) manages relatively modest heat loads, and thermal management is still one of its most elaborate subsystems. It has dedicated radiators, complex fluid loops, active control systems. If the ISS struggles with cooling, imagine what a compute-intensive platform faces.

I have seen concept decks that conveniently skip this section. Those decks are wrong.

Power, Radiation, and Reliability

Power in space is not free. It is solar panel area, conversion losses, time spent in Earth’s shadow, battery storage, and power conditioning circuits. An orbit in permanent sunlight gives you more power, but it might be farther from Earth, forcing bigger antennas and longer latencies. An orbit that keeps you near the ground gives you better links, but you spend part of every 90-minute revolution in darkness. Workload matters too. If your customers want continuous compute, your power requirements are constant. If they can tolerate bursty processing, your power challenge is different.

Radiation becomes a serious consideration if you want anything like the reliability customers expect from cloud providers. Space is not a friendlier environment than Earth when it comes to faults. Cosmic rays flip bits. High-energy particles degrade electronics. You cannot just install a server and walk away. Your plan might involve shielding, redundancy, error correction with checkpoints, or rapid replacement of broken nodes. That plan signals your business model. Are you selling special-purpose compute for space applications, where customers understand the constraints? Or are you selling cloud services where customers expect the same service level agreements (SLAs) they get from terrestrial providers? Those are completely different propositions.

Networking adds more physics. Latency cannot be beaten. It is the speed of light, nothing more, nothing less. Bandwidth depends on spectrum allocation and antenna performance. Coverage requires ground stations. In-orbit compute helps when your downlink is the bottleneck, but it does not eliminate the need for good network design. Optical links between satellites are impressive, but they bring their own complexity. Acquiring the signal, maintaining pointing, routing data across a dynamic network. It is solvable, but it is not trivial.

Finally, the human element. On Earth, you win through discipline: change management, monitoring, spare parts, engineers visiting sites to fix things in person. In orbit, every operation is remote. Software is your only tool. You need fault detection that works even with intermittent communication windows. Patches must be safe enough to deploy without human eyes on the hardware. Your monitoring systems must be more reliable than the things they monitor. That is a high bar.

Designing for Feasibility, Not Just Feasibility Studies

Most concept decks avoid this section, which is exactly why they fail.

Orbit class shapes everything. Low Earth orbit (LEO) gives you short latency and easier communication with ground stations, but you deal with satellite congestion, debris risk, and frequent eclipses as you plunge through Earth’s shadow. Higher orbits give you longer coverage periods and fewer debris encounters, but latency gets worse and replacing hardware becomes a logistics nightmare. There is no perfect choice.

Constellation topology forces hard trade-offs. Concentrate everything onto a few large platforms, and you get efficient thermal management and centralized power systems, but you also create tempting targets and single points of catastrophic failure. Spread compute across many small nodes, and you gain resilience, but building and operating a constellation of satellites is a different order of complexity entirely.

Serviceability becomes a fundamental business question. Do you treat compute nodes as disposable? Then your replacement rate is your core cost driver. That works if launch and manufacturing are cheap enough and predictable enough. Do you want to upgrade and repair hardware? Then you are betting on orbital robotics, standardized interfaces, and a servicing ecosystem that barely exists at scale today. Choose one. Both is not an option.

The Economics Without Fantasy

Here is the useful frame I return to repeatedly. Your cost per delivered compute hour is launch and spacecraft capital, amortized over platform lifetime, plus operations and ground segment, plus replacement and spares costs, divided by the actual compute you deliver at acceptable reliability.

That simple equation explains why orbital compute only wins in specific scenarios. Either it solves a problem that is more expensive to solve on Earth, like reducing Earth observation downlink volume. Or it creates a revenue opportunity that does not exist terrestrially, like selling compute to other spacecraft that cannot carry all their own processors. Going head-to-head with terrestrial cloud on general-purpose workloads is the hardest case. Even the giants who own those clouds have publicly said it is not economically viable near term.

Security Is Not About Altitude

Being in orbit does not automatically make you secure. Your threats are still cyber compromise, supply chain compromise, jamming, spoofing, physical attack. Governance questions that sound boring actually matter. Who holds the encryption keys? Who is authorized to patch systems? Who can issue commands? What is your procedure if an orbital node dies unexpectedly? Sovereignty pitches often sound compelling in board presentations. In practice, sovereignty is about control, assurance, and auditability. It is not about the romantic idea of being far away from everyone else.

The SpaceX Signal

If you are following this space in 2026, SpaceX is the reference point. They have demonstrated launch cadence that others said was impossible. They have manufacturing speed. They have actual track records of taking ambitious timelines and delivering working hardware at scale.

This does not mean every ambitious space idea becomes feasible just because SpaceX exists. But when they file regulatory paperwork or announce intent, it shifts what other organizations think is worth exploring seriously. Right now, credible reporting suggests SpaceX is seeking approval for a very large orbital datacentre constellation, explicitly positioned as solar-powered compute for AI (Reuters). There are also reports connecting this to closer integration with xAI (Reuters).

Stay grounded. Ask hard questions. Three specific ones matter most. Where does the heat go when you operate at the compute densities you actually need? What is your failure model, and how do you replace hardware without bankrupting yourself? What happens to orbital debris and congestion if this actually scales to the numbers being discussed?

If SpaceX can demonstrate a working thermal architecture and a viable replacement model, the conversation shifts fundamentally. Those are the cruxes.

What Actually Exists Versus What People Claim

The gap between announced plans and demonstrated hardware matters enormously. Axiom Space has positioned orbital nodes as steps toward on-orbit infrastructure. They report their first two nodes launched to low Earth orbit on January 11, 2026 (axiomspace.com). Starcloud launched a demonstrator satellite carrying an NVIDIA H100 graphics processing unit (GPU) with the explicit goal of running meaningful AI workloads in orbit (NVIDIA Blog).

This is early. But it is exactly right. Take the unknowns and make them measurable. Put hardware in orbit. Publish real data. That is how you separate engineering from storytelling.

What Would Change My Mind

If you want to know whether this is becoming real or staying theoretical, watch for four specific signals over the next 12 to 24 months. Sustained operation of serious compute on orbit with published reliability and fault rates. Demonstrable heat rejection at meaningful compute densities, not short bursts in perfect conditions. A repeatable, economical replacement process that does not require rescue missions. A paying customer running a real workload, not a proof-of-concept or press release.

If those materialise, compute in orbit becomes a category worth serious investigation. If they do not, this remains what it has been: a thought experiment with some interesting engineering.

The Shape of What Actually Works

Orbital datacentres are plausible, but only for specific problems. Space-native compute is the credible starting point. It solves a real friction: reducing the data flood from sensors to decisions, cutting latency, and making operations less dependent on perfect communications from the ground.

General-purpose cloud in orbit is much tougher. It runs into hard walls: heat rejection at the density you need, reliability expectations that match terrestrial cloud, cost structures that do not pencil out against established competitors.

The useful part is that we have moved past pure speculation. We can build things, launch them, and measure what actually happens. That is where rigorous space thinking and datacentre thinking converge best. Build something real, measure the results, and scale only when physics and economics both say yes. Everything else is just selling a story.

References

• Reuters: SpaceX seeks FCC nod for solar-powered satellite data centers for AI
• Reuters: Musk’s mega-merger: SpaceX and xAI bet sci-fi future on data centers in space
• Reuters: Amazon’s AWS CEO says orbital data centers pretty far from reality
• Space.com: China joins race to develop space-based data centers with 5-year plan
• TechRadar: SpaceX has applied to launch another million satellites into orbit, all to power AI