SpaceTech 101: How Possible Is It to Put the Cloud in Space?

In June 2026, in the same week it staged the largest IPO in Wall Street history, SpaceX showed the world a satellite called AI1 — a solar-winged machine broader than a Boeing 747, built not to beam internet or take photographs but to think. It is a rack of AI chips designed to run in orbit. Google is building its own version. So are Amazon, Nvidia, a Chinese state-backed constellation, and a scrappy layer of startups with names like Starcloud and Cowboy Space.

The idea underneath all of it is deceptively simple: stop building data centres on the ground, and start building them in the sky.

What is an orbital data centre?

A data centre is just a warehouse of computers — the unglamorous machinery behind everything we call “the cloud.” An orbital data centre is that same rack of computers, lifted into low Earth orbit a few hundred kilometres up, drawing power from solar panels and dumping its heat into the vacuum instead of relying on the grid, the mains water supply, and rows of humming fans.

Before going further, one distinction matters more than any other, because it quietly separates the reasonable version of this idea from the fantasy version:

• Edge compute means processing data that is already in space — satellite imagery, sensor feeds, Earth-observation data — right where it’s generated, and sending down only the useful conclusions rather than the raw torrent. This works today. It earns money today.

• The orbital hyperscale cloud means putting general-purpose racks in orbit to serve customers on the ground, competing directly with the data centre off the motorway. This is the trillion-dollar leap, and it is what the eye-watering valuations are actually betting on.

Almost every heated argument about orbital data centres is really an argument about the second thing while gesturing at the proven success of the first. Hold the two apart and the fog clears.

Why now? The constraint that forced the question

Nobody wakes up wanting to run computers in space. The industry arrived here because it walked into a wall on Earth.

Modern AI is spectacularly power-hungry. The binding constraint on new data centres is no longer chips or capital — it is electricity, delivered fast enough. Grid hook-ups now carry multi-year queues. Substations and transmission lines take longer to build than the data centres that need them. Water for cooling is contested. And communities are increasingly unwilling to host a power-guzzling shed next door. The scarce ingredient is energy, and Earth is rationing it.

A solar panel on a rooftop is a part-timer: night switches it off, clouds interrupt it, and the atmosphere skims off a portion of the light before it lands. Averaged across a year, that panel yields only a fifth or so of its rated output. Put the identical panel in the right orbit and it stares at the Sun almost without pause — no weather, no atmosphere, barely any night. By Google’s own reckoning, an orbital panel can be up to eight times more productive than the same panel on the ground.

Although the AI build-out is happening now, the power squeeze is biting now; Orbital hardware, by contrast, won’t reach meaningful scale until the back half of this decade at the earliest. So this is not an emergency fix. It’s a wager that the energy crunch will still be acute several years out — a safe bet — and that space will prove the cheapest way to escape it, which is the part worth arguing about.

Does the physics cooperate? A ledger of one asset and four liabilities

The cleanest way to judge any orbital-compute plan is to treat it as a balance sheet. There is exactly one genuine asset — energy — and it has to be rich enough to pay off four stubborn liabilities: cooling, launch, real estate, and mortality. Whether a given company’s numbers work comes down to whether the asset covers the liabilities. Let’s price each.

The asset: energy

Covered above, and it is real. Up to eight times the solar yield per panel, running nearly around the clock. This is the physics-backed reason the whole sector exists. Everything that follows is the invoice for collecting it.

Liability 1: cooling — the counter-intuitive killer

Here is the fact that catches almost everyone out: space is terrible for cooling.

A vacuum is one of the best insulators we know. That is why a thermos keeps your coffee hot for hours. On Earth, data centres dump heat through air, water, liquid cooling, chillers, and the surrounding environment. In orbit, there is no outside air or water to carry heat away. The final escape route is radiation: waste heat has to leave the spacecraft as infrared light.

That is slow physics.

Every watt a chip consumes becomes a watt of heat, and that heat still has to go somewhere. The largest radiator ever flown — the ISS — sheds about 70 kilowatts across 422 square metres: roughly 166 watts per square metre. AI1's own published numbers imply about 1,360 watts per square metre — eight times denser than anything humanity has actually put in orbit. Scale that mismatch to a gigawatt-class data centre and the radiator area needed starts to look like square kilometres.

This is why heat, not power, is the true ceiling. You can run chips hotter to radiate heat faster, but “hotter” is exactly what silicon hates. Unlike launch cost, radiator physics does not simply fall with scale.

How builders are trying to make this survivable: the answer is not one magic radiator. It is a stack of compromises.

Larger deployable radiators give the system more surface area. High-emissivity coatings help those surfaces shed heat more efficiently. Liquid loops and heat pipes move heat away from chips toward the radiator panels. Wider spacing between satellites or compute modules prevents them from warming each other. And software can help too: thermal-aware scheduling can shift workloads to the coolest available nodes instead of treating every orbital server as identical.

That last point matters because cooling capacity in orbit is not constant. It changes with geometry, sunlight, radiator angle, and neighbouring satellites. So orbital compute may need to schedule around temperature as much as power.

But none of this repeals the physics. It only makes the cooling problem less ugly. At small and medium scale, this is engineerable. At hyperscale, cooling remains the hardest liability in the whole model.

Liability 2: launch — the price of the ticket

Every gram has to be flown up, and rockets bill by the kilogram.

Today, reaching low Earth orbit costs roughly $2,700–3,000 per kilogram. SpaceX’s AI1 is described as squeezing around 70 kilowatts of compute per tonne. At that density, a single gigawatt of orbital compute would require launching roughly 14,000 tonnes — close to $40 billion in freight alone, before paying for the chips, radiators, solar arrays, batteries, shielding, structure, or operations.

That is why orbital data centres are, underneath the vision statements, a leveraged bet on the price of rockets.

Google’s own analysis is unusually candid: the economics only start to close if launch costs fall toward roughly $200/kg, probably around the mid-2030s, and probably only if Starship achieves cheap, frequent, fully reusable launch. At that price, the same gigawatt costs under $3 billion to ship, and the conversation changes completely.

Until then, launch cost is the cell every spreadsheet keeps pointing back to.

How builders are trying to make this survivable: the obvious answer is reusable heavy launch, especially Starship. The less obvious answer is mass discipline.

Every kilogram has to justify itself: solar array, radiator, shield, battery, structure, chip, antenna, and thermal system. That pushes designs toward modular satellites instead of one giant orbital data centre. Smaller units can be launched, tested, replaced, and scaled gradually. It also pushes builders toward lighter thermal systems, compact accelerators, and better compute per kilogram.

Longer term, autonomous assembly may matter too. Very large solar or radiator structures may eventually be assembled in orbit instead of launched as one enormous finished object.

This liability is different from cooling because it can fall with scale, reusability, manufacturing learning curves, and launch cadence. But until it does, every orbital cloud model is still mostly a rocket-cost model.

Liability 3: real estate — free sunlight is beachfront property

Near-continuous sunlight is not available everywhere in orbit.

The most attractive zone is a dawn–dusk sun-synchronous orbit, where a satellite rides near the permanent line between day and night, so its solar panels almost never fall into Earth’s shadow. That is the “beachfront property” of orbital compute: the place where the energy argument is strongest.

But beachfront is limited.

Crowd that ring with satellites and the problems compound. Each spacecraft needs propellant to hold position and avoid neighbours. Collision avoidance gets harder as the numbers rise. Orbital debris risk increases. And the thermal problem gets worse in a counter-intuitive way: densely packed satellites can start radiating heat at each other instead of into cold space.

Realistically, the favourable band may top out in the low single-digit gigawatts before congestion starts to bite. Earth, meanwhile, is building hundreds of gigawatts of data-centre capacity, with individual campuses already reaching the 1–5GW range. Move outside the sweet spot for more elbow room, and you start giving back the sunlight advantage that justified going to space in the first place.

How builders are trying to make this survivable: the serious proposals do not imagine one giant orbital server farm. They imagine clusters.

Many satellites fly close enough to behave like one distributed data centre, linked by lasers, but far enough apart to reduce collision risk and avoid immediately heating each other. This requires formation flying, autonomous station-keeping, precise constellation management, and workload routing across moving nodes.

In that model, traffic, routing, collision avoidance, thermal management, and workload placement all become software problems. Compute jobs may move between satellites depending on position, temperature, power, and connectivity. Google’s Suncatcher-style architecture — small TPU satellites, close formation, and laser links — is the cleanest version of this idea so far.

But clustering is not a cheat code. It helps coordination, but it does not create infinite orbital beachfront. At real hyperscale, space traffic management becomes part of the product.

Liability 4: mortality — the number nobody puts on the slide

This one is quietly brutal.

A cutting-edge AI chip is economically current for maybe three to four years. The satellite carrying it may be designed to last five to seven. On Earth, that mismatch is manageable. An ageing GPU can be demoted from training to inference, sold into a second-hand market, reused internally, or replaced during a normal upgrade cycle.

In orbit, an obsolete or dead chip is different. It is mass you already paid to launch, still flying around the planet, with no repair van at 600 kilometres and no real salvage market in the vacuum. A terrestrial data centre depreciates onto a resale floor. An orbital data centre, for now, risks becoming a consumable you can never bring home.

How builders are trying to make this survivable: the first step is proving the chips survive space at all. Google’s Trillium TPU radiation testing matters because it directly asks whether modern AI accelerators can tolerate multi-year low Earth orbit conditions.

After that, the playbook is resilience. Orbital compute systems need redundancy, spare capacity, fault-tolerant software, error correction, workload migration, and graceful degradation. If one chip, node, link, or satellite starts failing, the system should shift work elsewhere and lose capacity gradually rather than collapsing all at once.

The better long-term answer is modularity. Separate the satellite bus, power system, and communications layer from the compute payload, so the chip layer can be refreshed more often than the entire spacecraft. On-orbit servicing — repair, replacement, refuelling, or payload swaps — would help even more.

But those fixes depend on cheaper launch, standardised interfaces, and a servicing market that is still early. Until replacement becomes cheap, mortality remains the most awkward business-model problem: the chips age faster than the satellite.

The related bottleneck: downlink

There is one more liability worth naming: the downlink.

Orbital servers may talk to each other through laser links, but serving customers on Earth still means moving data between space and the ground. That path is not unlimited. It depends on bandwidth, ground-station access, weather, line of sight, spectrum rules, latency, and cost.

This is why orbital cloud is awkward for ordinary Earth-based workloads. If the data starts on Earth, you may have to upload it to orbit, process it there, then send the result back down. For many use cases, that is slower and more complex than using a normal terrestrial data centre.

But the logic changes when the data is already born in space. Satellite imagery, Earth-observation feeds, radar data, and space-science sensor data do not need to be uploaded from Earth in the first place. They are already up there.

In that case, processing in orbit can reduce the downlink burden. Instead of sending every raw image or sensor feed back to Earth, the satellite can send smaller, more useful outputs: labels, alerts, compressed features, embeddings, selected imagery, or model results.

Who is actually building it?

The field is wider than “SpaceX versus Google.” It splits into vertically integrated giants, startups with flown or planned hardware, relay infrastructure, state-backed programmes, and sceptics defending the terrestrial buildout.

Two questions matter more than the press release:

1. Have they flown anything, or only filed something?
2. How much of the stack do they own?

So — how possible is it, really?

Near-certain

Edge compute — processing space-born data in space — keeps quietly working and quietly earning. Nobody even calls it a data centre; it’s just good satellite engineering.

Likely

Tens of megawatts of commercial orbital AI compute by the early 2030s. A real niche, anchored by defence, intelligence and “sovereignty” customers who will pay a premium to put data beyond any single government’s reach.

A genuine toss-up

Rough parity with Earth for batch AI training around 2035 — but only if Starship drags launch toward $200/kg. Note the cruel mismatch buried here: training tolerates delay but runs blisteringly hot (miserable to cool), while inference runs cool but hates latency (orbit’s worst attribute). The workload that fits the physics and the workload that fits the market are not the same workload.

The shape of this should feel familiar. The technology is real. One number in the physics — sunlight — is authentically favourable. And the timeline in the press release is borrowed from the funding cycle, not the engineering. Compute can move to orbit; that was never in doubt. The open question is whether anyone mistakes free sunlight for free infrastructure.

What I’m watching: SpaceX’s two 2027 prototypes and the Google–Planet twin-TPU demo — the first real data on the hyperscale version. Starship’s launch cost trending toward $200/kg, the hinge everything swings on. The first genuinely commercial edge-compute contracts. And whether anyone, anywhere, demonstrates radiator performance at the square-kilometre scale the dream demands. Watch the freight number and the heat number. Sunlight was always the easy part.

Glossary

Figures, company plans and milestones as reported through mid-2026. It’s a fast-moving, hype-prone sector.