The Missing Layer in the Orbital Datacenter

Always Another Announcement

Every week seems to bring another announcement from the orbital compute sector. GPU clusters in low Earth orbit. On-orbit AI inference. Edge intelligence at the edge of the atmosphere. Hundreds of millions have been committed in 2025 and 2026 alone. The engineering is serious. Companies have put working hardware in orbit and trained AI models in space.

But almost every announcement stops at the same point. The hardware exists, or soon will. What nobody is announcing is the commercial motion: the repeatable path from orbital GPU capacity to an enterprise workload that a procurement team can put on a purchase order, an operations team can depend on, and a finance team can plan around.

In December 2025, Nvidia-backed Starcloud successfully trained an AI model in orbit. In October 2025, Crusoe, a vertically integrated AI infrastructure provider, announced it would deploy its cloud platform on a Starcloud satellite planned for late 2026, with limited GPU capacity expected to become accessible from orbit in early 2027.

That is the leading edge of the commercial motion. Everything behind it is still largely infrastructure. Between a GPU in orbit and a repeatable enterprise workload, there is a value chain. Much of it still has no clear owner.

The Stack, Mapped Honestly

The orbital compute value chain has seven layers. Most analysis stops at three.

Compute silicon. NVIDIA has established an important early position. Starcloud’s first satellite carried an H100 into orbit and used it for AI workloads, including model training. NVIDIA-powered compute is also appearing elsewhere in the emerging orbital-compute ecosystem. AMD and Intel remain relevant in the broader AI infrastructure market, while Google’s TPU architecture is now directly relevant through Project Suncatcher.

The important point is no longer whether serious AI compute can operate in orbit. It can.

Orbital compute infrastructure. Companies including Starcloud, Kepler Communications, Axiom Space, Lonestar and Orbital are approaching the problem from different directions. Their architectural bets vary across satellite form factor, power, thermal management, networking and orbital environment.

And some of this has moved beyond PowerPoint. Starcloud has operated an H100 in orbit. Kepler has commissioned distributed on-orbit computing as part of its optical relay constellation. Axiom has deployed space-based compute hardware and launched dedicated orbital data-center nodes.

The infrastructure is starting to exist. What remains much less developed is the enterprise service model around it.

Space and network infrastructure. Satellite buses, optical inter-satellite links, RF and optical downlinks, ground stations, launch vehicles, power generation and thermal systems make orbital compute accessible.

This layer is maturing quickly. Optical inter-satellite networking is operational. Launch economics continue to improve. Future heavy-lift systems such as Starship could change the mass-to-orbit equation significantly if their targeted economics and reuse model are achieved. The plumbing is getting built.

Cloud and orchestration. Google’s Project Suncatcher is the clearest hyperscaler move toward orbital AI compute. Google is exploring constellations of solar-powered satellites equipped with TPUs, with prototype satellites planned for 2027.

AWS has already demonstrated another piece of the puzzle. Working with Axiom, it operated AWS Snowcone hardware and machine-learning workloads aboard the International Space Station. NVIDIA, meanwhile, is increasingly embedded in the emerging orbital-compute ecosystem through companies such as Starcloud and Kepler.

These are meaningful developments, but none of the major hyperscalers currently offers orbital compute as a managed enterprise service at scale.

Then there is the orchestration layer itself: the software that schedules workloads, enforces isolation and manages resources across distributed orbital infrastructure. It appears in market maps but remains commercially immature. OrbitalCloud.co identifies Orchestration & Metering as a distinct required layer, covering resource scheduling, isolation, metering and billing.

It is on the map… a mature multi-provider implementation is not yet on the market.

Commercial middleware. This is the layer almost nobody is talking about, and it is the subject of this article.

It sits between cloud orchestration and the customer and does not yet exist in any complete form. Someone needs to abstract orbital complexity away from the buyer. Someone needs to create an SLA framework expressed in application terms rather than link-budget terms. There needs to be a pricing model that fits enterprise capital and opex planning cycles, a procurement interface a purchasing team can actually use, and a remediation framework for when the service fails.

Loft Orbital’s Cockpit environment, with APIs and tooling for mission tasking, resource management and data delivery, is probably the closest operational analogue. But it is satellite-operator tooling, not an enterprise service wrapper for orbital compute. The gap between those two things is large.

Connectivity. The path from orbit to the enterprise edge can involve satellite networks, ground infrastructure and terrestrial carrier networks. Each individual segment can have a commercial owner.

What I have not found is someone offering an end-to-end enterprise SLA across the entire path from orbital compute resource to enterprise application. Who guarantees performance when the workload crosses orbital compute, space networking, a ground station, terrestrial connectivity and finally the enterprise edge? That commercial interface still appears to be open.

Customers. Government and defence are important early anchor markets, particularly where resilience, sovereignty and mission requirements justify the cost and technical maturity of the infrastructure. But they are not the whole market.

Commercial activity has already begun. Kepler reports commercial as well as government customers using its infrastructure, while Axiom is targeting commercial, civil and national-security workloads. Earth observation and space-based data processing are also obvious early demand areas.

The broader enterprise market in sectors such as mining, energy, maritime and telecoms remains much more forward-looking. That distinction matters. A stack this deep, with this many interfaces still commercially immature, is not simply a technology problem. It is a market architecture problem.

We Have Seen This Before

This is not the first time a technology infrastructure layer has arrived before the commercial architecture existed to deliver it. I’ve seen versions of this problem more than once over the last twenty-five years.

MEO satellite capacity and the O3b model. I saw this firsthand at SES and O3b. The satellite capacity was real. The coverage was real. The harder problem was turning that capacity into something an enterprise could actually buy.

The answer was not one single channel. O3b developed through a mixture of telecom operators, mobility, enterprise, government and distribution partners. Over time, carrier offerings, systems integrator relationships and managed services helped turn MEO capacity into something customers could procure as part of a broader service.

The technology was only part of the problem. Distribution and commercial packaging mattered too.

SDN and NFV. Between 2013 and 2016, every major networking vendor shipped software-defined networking and network functions virtualisation technology. The architecture was sound and the business case was well documented. Enterprise adoption still didn’t scale as quickly as many expected.

Technology wasn’t the only issue. Enterprises also needed orchestration, operational integration and, in many cases, managed-service providers capable of turning the underlying capability into something a CIO could consume without building an entirely new specialist organisation. The commercial wrapper mattered.

Private 5G. The spectrum was allocated. Radios were shipping. Core networks became containerised and deployable. Yet adoption developed more slowly than much of the early industry enthusiasm suggested.

Procurement complexity was part of that. So were integration, spectrum, devices, skills, ROI and the difficulty of translating technically interesting capabilities into compelling operational use cases. System integrators and hyperscalers began building managed private 5G propositions to reduce some of that complexity, but adoption remains uneven across verticals.

Different technologies. Very similar problem. A technology can be technically viable long before the surrounding commercial model becomes easy to consume.

There is another pattern worth noting. Government and defence often play an outsized role in the early development of infrastructure markets because they can tolerate technical immaturity, fund capability ahead of commercial scale, and place a premium on resilience that commercial buyers may not initially justify.

But they are not always the first or only market. O3b itself developed through a mixture of telecom, mobility, enterprise and government demand. The useful lesson isn’t that government always comes first. It is that infrastructure markets rarely arrive fully formed.

Orbital compute appears to be following that pattern. The question is no longer just whether the hardware can work. The more interesting question is who builds the market around it.

Who Owns Each Interface?

This is where the orbital compute market gets interesting, because once you start looking interface by interface, ownership becomes surprisingly difficult to find.

Orbital infrastructure to cloud orchestration. Starcloud, Kepler, Axiom and others are building operational infrastructure. Google is pursuing its own research architecture through Project Suncatcher, while Crusoe has taken a different route by partnering directly with Starcloud.

Cloud orchestration to connectivity. Who guarantees end-to-end performance when the workload crosses an orbital compute node, an optical inter-satellite link, a ground station downlink, a terrestrial carrier network and finally the enterprise edge?

I have not found an operator offering an enterprise SLA across that entire chain. Individual pieces increasingly exist, but the commercial abstraction across all of them does not appear to.

Early cloud connectivity had a version of this problem too. Cloud-adjacent networking specialists and carrier agreements eventually helped resolve it. Orbital compute adds another level of difficulty because the service crosses orbital and terrestrial infrastructure.

Connectivity to customer. Who holds the enterprise relationship and owns the commercial risk?

In the O3b model, telcos, distributors and systems integrators often played that role. They had enterprise contracts, account teams and the commercial credibility required to attach a new capability to an existing customer relationship.

The equivalent role in orbital compute is much less obvious. Commercial customers are already appearing around space-based data processing and communications infrastructure, but the broader enterprise relationships required to move orbital compute into mining, energy, maritime and telecom environments do not yet exist at scale.

Then there is the procurement interface itself.

What does an enterprise buyer actually put on a purchase order? This is where the technology conversation runs into commercial reality.

I have not found a generally available orbital-GPU rate card built around enterprise consumption, nor a commercially published end-to-end SLA expressed in terms such as application availability, throughput and latency to the enterprise edge. I have also not found a standard enterprise remediation or service-credit framework for orbital compute.

Those may sound like mundane details compared with putting GPUs into orbit. They’re not. They’re what turns infrastructure into a service.

SpaceX’s own pre-IPO filing makes the maturity question unusually explicit. The company warns that orbital AI compute involves significant technical complexity and unproven technologies, and that the business may not achieve commercial viability. That’s from one of the companies making the strongest public cases for computing in space.

The companies that eventually define this market may not be the ones with the best hardware. Someone still has to figure out who the customer actually is, what that customer needs in order to buy the service, and how the whole thing becomes repeatable at scale.

That’s not really an engineering problem. And right now, it’s largely unsolved.

What the Enterprise Buyer Actually Needs

This is where I think much of the orbital compute discussion is looking in the wrong direction. We keep starting with what can be built in orbit. Start instead with the person who eventually has to buy it.

They need an SLA expressed in application terms. Orbital altitude, ground station coverage maps and link margin calculations may matter to the operator, but the customer needs uptime measured at the application layer, throughput expressed in operational terms, and latency to the enterprise edge. They need to know what failure costs them and what happens when it occurs.

Pricing has to fit the way enterprises actually buy infrastructure. That might mean capital expenditure with a depreciation schedule or operational expenditure on a consumption model, depending on the vertical, CFO and regulatory environment. Orbital launch costs and satellite mission life are the operator’s cost structure. They are not the customer’s planning framework.

Then there is remediation. What happens when the service fails? Who is responsible? What’s the credit mechanism? Who gets called? What is the escalation path?

These clauses are standard in enterprise infrastructure contracts. Orbital compute will not somehow escape them because the infrastructure happens to be in space.

Finally, it has to fit into commercial relationships that already exist. An enterprise considering orbital compute probably already has a cloud contract, connectivity contracts, managed services agreements and an IT organisation built around existing vendors.

Orbital compute has to enter that environment both technically and commercially. Otherwise procurement stalls before it starts.

Where the demand really lives

These requirements become more meaningful when mapped against industries that could eventually benefit from orbital compute and, importantly, have little tolerance for an incomplete commercial architecture.

Mining. Large-scale mining operations moving toward autonomous haulage, remote drilling and real-time geological modelling are generating increasingly large volumes of operational data, often in locations where terrestrial infrastructure is limited.

Orbital compute potentially offers something interesting here: processing remote data without complete dependence on terrestrial fibre routes that may not exist or may cross jurisdictions that introduce their own risks. The potential use case is real. The commercial path to procure it isn’t yet.

Energy. Offshore platforms, remote pipeline monitoring and LNG operations in frontier jurisdictions have relied on satellite connectivity for decades. The industry already understands both its value and its limitations.

AI-driven predictive maintenance and real-time asset optimisation increase demand for distributed compute. An orbital compute layer capable of processing large sensor datasets, running inference on equipment behaviour and returning useful output rather than all of the underlying data could address a real operational problem.

But again, who sells it to them, and on what terms?

Maritime. A container vessel crossing the Pacific generates continuous data from navigation, cargo monitoring, engine management and crew systems.

Processing some of that data in orbit could change the connectivity equation. Filter what matters, run inference on anomalies, and return decisions rather than pushing every piece of raw data back to a terrestrial data centre.

But maritime operators already buy through established relationships with ship managers, satellite service providers and system integrators. Orbital compute doesn’t yet have those distribution relationships at scale.

Telecoms. Network operators are under permanent pressure to move intelligence closer to the edge, reduce backhaul costs and process data nearer to the point of generation.

Orbital compute could eventually extend edge processing beyond the reach of terrestrial infrastructure. That becomes interesting for rural coverage, remote network infrastructure and the longer-term integration of non-terrestrial networks with 5G and 6G architectures.

Telecom operators are also an obvious potential distribution channel into other enterprise verticals. They already have enterprise relationships, commercial infrastructure and regulatory experience. Whether any of them moves early enough to own that position is another question.

Government and Defence. These remain important early markets for capabilities such as surveillance, signals intelligence, resilient edge compute and sovereign data processing outside terrestrial infrastructure.

The requirements are different from those of mainstream enterprise customers, but government and defence can help fund and mature capabilities before broader commercial demand develops. The commercial market does not necessarily come second in every case, but it usually needs a different wrapper.

The Market Creation Question

So if the commercial architecture is missing, who builds it?

I see three plausible paths from where the market sits today.

A hyperscaler absorbs the stack. Google’s Project Suncatcher shows that hyperscalers are taking orbital compute seriously. AWS has already demonstrated in-space cloud hardware and machine-learning workloads with Axiom, although it has not announced an orbital AI-compute architecture comparable to Suncatcher.

Commercially, hyperscaler ownership would be a clean route. Extend an existing managed-service wrapper into orbital compute, much as cloud providers have extended their platforms into enterprise edge environments, then distribute it through relationships and procurement structures that already exist.

That could get the market functioning quickly, but there is an obvious trade-off. If a hyperscaler owns the commercial middleware layer, it also owns the interface between orbital compute and the enterprise buyer. Orbital compute operators risk becoming infrastructure vendors inside someone else’s stack.

A systems integrator builds the intermediation layer. Think of this as one lesson from the O3b experience applied to orbital compute.

An entity with relationships across hardware, connectivity, cloud and enterprise accounts builds the wrapper around the service. SLA framework. Pricing. Procurement. Account management.

Crusoe is an interesting early candidate because it has some of the right instincts. It has a cloud platform, an orbital hardware partner in Starcloud and an energy-first AI strategy that connects naturally to industries with an acute need for distributed infrastructure.

But Crusoe is a neocloud, not a traditional systems integrator. It doesn’t yet appear to have the depth of enterprise account relationships across mining, energy, maritime and telecoms that this role would ultimately require.

The job description exists… I’m not convinced the occupant does.

Established satellite and telecom operators already have customer relationships and commercial infrastructure. Large systems integrators have enterprise reach. I have not yet seen any of them assemble all the pieces into a mature orbital-compute enterprise proposition.

There’s a window here.

The orbital compute operators can (should?) build enterprise sales themselves.

I wouldn’t bet on this path. Hardware companies rarely become service companies by accident. Building extraordinary orbital infrastructure and building an organisation capable of selling, contracting and supporting enterprise services are very different jobs.

The sales motion is different. So is the commercial risk, the support model and, frankly, much of the organisational culture required to do it well.

Starcloud, Kepler, Axiom and others could decide to build serious enterprise service organisations around their infrastructure. Some are already moving further up the stack than a simple “hardware company” description suggests.

But building the infrastructure does not automatically solve the enterprise service problem. The intermediation opportunity exists now, before the distribution architecture hardens around a small number of platforms.

That window won’t remain open forever.

So….Who?

The infrastructure is starting to exist. Starcloud has operated serious AI hardware in orbit. Kepler has commissioned distributed on-orbit compute alongside optical networking. Axiom has deployed space-based compute infrastructure. Google has a serious research programme. Significant capital is flowing into the sector.

What hasn’t emerged is a mature enterprise service model connecting those capabilities to a procurement team on the ground. That distinction matters.

The companies that define this market may not be the ones that launched first, raised the most capital or put the most powerful silicon into orbit. Someone still has to solve the interfaces: who the customer is, what they need to procure the service, what SLA they require, what pricing model fits their planning cycle, and what commercial relationship makes the stack repeatable at enterprise scale.

Those are market creation questions. In my experience, they can be harder than the engineering.

We’ve seen versions of this before. MEO satellite capacity needed distribution and commercial packaging. SDN needed orchestration and operational integration. Private 5G has had to work through procurement, integration and business-case complexity.

The details were different, but the lesson is useful. Technology can be ready long before the market around it is. Orbital compute looks like it is approaching that point now.

SpaceX’s own pre-IPO filing captures the tension particularly well. The company warns investors that orbital AI compute involves significant technical complexity and unproven technologies, and may not achieve commercial viability.

At roughly the same stage of market development, Elon Musk has publicly described AI in space as a “no-brainer.” I don’t see those positions as contradictory. They capture the two sides of this market rather well.

The technology is becoming real. The commercial path is not yet built… and the distance between those two things is where the opportunity lives.

The missing layer in the orbital data center is not another technology. It is a business model.

The organisations that recognise that now, and start building the commercial architecture before someone else absorbs that layer, are the ones most likely to have a meaningful position when the market matures.

That work starts at the interfaces………Not in orbit.