From Onboard Computer to Orbital Data Center: How the Space Software Market Is Changing
From radiation-hardened chips to AI data centers in orbit — how space software is finally catching up to Earth, and where the money's moving
Issue 176. Subscribers: 90 398
While capital in space chases rockets and satellites, a less visible but growing part of the market is the software without which the entire fleet is useless. The number of spacecraft in orbit has grown by an order of magnitude, and with it, demand for onboard computers, ground control systems, and data processing. Yet space software as an industry has always lagged a good decade behind its terrestrial counterpart: weak hardware, radiation shielding, and strict mass constraints left no room for the luxury of modern architectures. That’s changing now — and in this article, we’ll break down what’s happened with space software in recent years: from onboard computers to the cybersecurity of orbital data centers.
We provide consultancy services for stakeholders in the SpaceTech and DeepTech sectors. Whether you’re an investor, corporation, aerospace agency, accelerator, incubator, ecosystem builder, startup founder, or planning to launch a SpaceTech or DeepTech business, we can help.
Contact us at denis@spaceambition.org—we’d be happy to assist. Good luck with your future endeavors!
I began my career at Mission Control as a developer. We were building a system that uses ground-based instruments (telescopes) to monitor outer space and predict dangerous close approaches and collisions between satellites. I was responsible for forecasting the trajectories of spacecraft and debris, translating the physical equations of spacecraft flight dynamics into code.
That experience gave me a front-row seat to how space software actually works under the hood. So let’s start with the basics: all space software can be divided into the following categories:
The “Onboard” and “Ground” categories are essentially about infrastructure, “Development and Testing” is about building and testing that infrastructure, “Data Processing” is about operating the infrastructure and the results it produces, and “Space Services” is the product itself.
Let’s go through each of these in more detail.
Onboard — Hardware and Software
Here we mean the spacecraft itself, the vehicle carrying the payload. The key component of a satellite is the onboard computer — the brain of the spacecraft, which issues commands to all subsystems and oversees their operation.
Interestingly, your smartphone is more powerful than a satellite’s onboard computer. The reason is that in space, the main enemy of electronics — beyond the cold and the vacuum — is radiation. Charged particles can flip a single bit in the processor’s memory (a “bit flip,” 1 instead of 0 or vice versa) or knock a chip out entirely — and while on Earth such an error would at worst freeze an app, in orbit it can mean the satellite losing its orientation or breaking down with no chance of repair.
That’s why the industry trades performance for reliability. Instead of the latest process nodes used to make chips for iPhones, satellites fly on components based on architectures that were used on Earth 10-15 years ago, but have been extensively tested for radiation resistance.
On top of that come strict constraints on mass and power consumption: every watt on a satellite has to be harvested by solar panels and somehow dissipated as heat, and every extra gram is a line item in the launch cost. As a result, a typical satellite onboard computer is comparable in processing power to an early-2000s smartphone — and that’s not the industry falling behind, but a deliberate trade-off between “fast” and “will survive 15 years in orbit with no tech support.”
Ground — Satellite Control
Here we’re talking about the software behind Mission Control — and this is where some of the most interesting changes are happening right now.
When I worked at Mission Control five years ago, we had strict procedures for controlling the spacecraft. Operators worked in shifts, 24/7, with a scripted scenario for every communication session, manual confirmation of every command, a log recording everything down to the second, and a separate team standing by to analyze telemetry. And that was all for a single satellite.
Now we’ve entered the era of multi-satellite constellations — and that old model simply doesn’t work anymore. I shudder to think how many operators it would take to manage 10,000 Starlink satellites without automation. So the operator’s role itself has changed — they no longer fly a specific spacecraft, but instead oversee an automated system that manages entire clusters of satellites on its own. Routine procedures are automated, maneuvers are calculated without human involvement, and AI monitors the health of all systems in real time.
Another key change tied to the growing number of satellites is the massive increase in the volume of data transmitted from space. There are more images, and the images themselves are larger. Meanwhile, a ground station only sees a given satellite passing overhead for about ten minutes per session — and physically pushing that much data through such a narrow window is difficult. Building your own global network of ground stations to solve this isn’t something every company can afford — it’s expensive.
Two solutions have emerged from this. The first is ground stations as a service: instead of building your own network, you plug into a provider that already operates a global network of ground stations — they pick up the data from your spacecraft and deliver it straight to you on the ground. Speaking as someone who’s launched a satellite myself, it’s a genuinely convenient option.
The second is onboard data processing. Since you can’t push the entire volume through such a narrow communication window anyway, part of the work shifts to the satellite itself: AI and increasingly powerful onboard computers make it possible to compress and pre-process data right in orbit, so what comes down isn’t a raw stream, but an already refined result.
What’s more, satellites have learned to exchange data with each other directly — via laser communication (we’ve covered this in more detail in a separate article). This makes it possible to distribute the load across the constellation more evenly: an overloaded satellite can hand off part of its data to a less busy neighbor, which then sends it down to Earth during its own communication window.
Satellites Development and Testing
Naturally, as the number of satellites grows, so does the need for their development — and with it, the need for software. This area includes some very specific tasks, such as supporting the testing of low-thrust engines and similar work.
Since I worked on calculating satellite trajectories myself, let me tell you what’s going on here. There are, of course, ready-made commercial solutions for this kind of task — AGI STK, for example. But an enterprise license can cost several hundred thousand dollars, and even then it doesn’t always cover the full range of functionality you need — so you end up building custom solutions on top of it anyway. On top of that, many companies deliberately choose to develop this kind of software in-house, for the sake of reliability and information security, rather than relying on an external closed-source product. This is where open-source libraries come in: the Orekit library, for instance, is used by ESA, CNES, and other agencies, covers nearly the entire spectrum of orbital mechanics (gravitational harmonics, atmospheric drag, solar radiation pressure), and is free. The learning curve and software development is steeper than with commercial alternatives, but for a team with strong engineering expertise, it’s a viable alternative to STK. But, of course, developing the software in-house—even when using off-the-shelf libraries—is also expensive and quite time-consuming. Even so, you often still end up doing manual work on top of it.
Payload Data Processing
A satellite can be roughly split into two parts: the BUS — all the supporting systems (onboard computer, data transmission channels, power system) — and the payload, the actual reason the spacecraft exists in the first place. And even if every component of the satellite is bought ready-made from suppliers, you still have to develop software specific to each payload — software that makes it work exactly the way your particular mission needs it to.
When we were developing our satellite, one of the biggest challenges turned out to be getting our payload software to talk to the software of components bought from suppliers — the onboard computer above all. Interfaces, data exchange protocols, timing — none of this tends to line up smoothly on the first try, and without support from the supplier, you can end up chasing down these mismatches for weeks. Supplier tech support really saved us here. So if you ever have a choice — don’t skimp on tech support :)
This is where a key economic feature of payload software comes in — one that sets it apart from almost any other industry: it’s hard to reuse across missions.
In regular IT, you write software once and sell it a thousand times — that’s the whole economic logic behind SaaS. In space, it’s the opposite: every new payload, even one tackling a similar task to the last, needs software built almost from scratch — different sensors, different interfaces, different precision requirements. That’s why the industry doesn’t have, an “app store for satellites” the way it has an App Store on Earth — and that’s one of the reasons satellite development stays so expensive and slow: every time, you’re paying not just for the hardware, but for software written from scratch for that one specific job.
You’d think the obvious fix would be standardization — common standards that universal software could be built around, like USB or HTTP on Earth, where a single protocol works across billions of devices. There have been attempts at this — the CCSDS (Consultative Committee for Space Data Systems) standards for data formats and communication protocols, for instance — but in practice the industry never fully standardized, and each company and mission still writes much of its own software. And this, too, ultimately comes down to economics: payload tasks are so varied and unique that no single standard can cover them all. Unlike USB, which solves the same simple problem — “move data between two devices” — payload software solves hundreds of fundamentally different problems that have no common denominator.
Space Services
It’s probably no surprise to you that as the number of satellites grows, a huge range of space services has sprung up around them:
Earth observation data as a service (EO-as-a-Service)
Connectivity as a service
Ground Station as a Service (already mentioned in the Ground section)
Launch as a Service / rideshare brokering
And on the more forward-looking side:
In-orbit servicing
Debris monitoring and Space Situational Awareness
Taken together, these examples point to a broader pattern: the space market is following the same path that land-based IT walked about fifteen years ago — a shift from selling hardware to selling services. Buying a presence in space used to mean buying a satellite or a rocket. Today, more and more often, you can just buy the outcome — an image, a communications link, collision insurance — while all the infrastructure and physics stay on the provider’s side. It’s the same shift that happened on Earth with the move from “buy a server” to “rent the cloud” — space is just replaying it with a couple of decades’ delay.
What’s Changing? The Data Center Hype
AI is, of course, absolutely everywhere these days — we covered this in a separate article a year ago, links here (optical com), here (optical terminals) and here.
Beyond the market’s evolution from selling hardware (satellites, rockets) to selling services and subscriptions, there are other interesting shifts underway.
The industry is moving toward a point where computing power in orbit becomes a sellable resource in its own right, rather than just “a feature of the satellite.”
We’ve already talked about part of the data processing moving onboard. But there’s a more radical idea the industry has arrived at: what if computing power in orbit becomes a standalone product — not “a feature of a specific satellite,” but a resource you can sell the same way you sell cloud computing power on Earth?
It looks like we’ll see spacecraft whose actual payload is powerful computing hardware that can simply be rented.
And naturally, at the largest scale, data centers are impossible to ignore.
In November 2025, Google announced Project Suncatcher — a research moonshot aimed at putting data centers into space. The idea: a constellation of 81 satellites equipped with Google’s own TPU chips (the same ones used to train models like Gemini), linked by laser communication and powered by solar panels.
The startup Starcloud has already launched Starcloud-1, a satellite carrying an Nvidia H100 chip on board, and is aiming for a 5 GW data center built on a 4 km solar array.
At Space Ambition, we did an in-depth study on orbital data centers and worked out the costs and how the whole thing would actually operate. If you’d like to hear our take on space data centers — email us to ivan@spaceambition.org and we’ll send you our findings.
A Word on Security
Naturally, more and more data is being transmitted from space — and with computing moving into orbit, the stakes are only getting higher, making security an increasingly pressing issue.
There have already been cases of spacecraft being hacked, which you can easily find online. But there’s a telling pattern across these incidents: attackers most often go after not the satellite itself in orbit, but the ground control software or the communication link to it — the very link we discussed in the Ground section. And as more constellation-management functions get automated and shift into software, the attack surface only grows. That’s why cybersecurity is more relevant to space than ever.
This isn’t a uniquely space problem, by the way — Earth-based data centers and cloud services went through exactly the same thing. When businesses started moving to the cloud en masse in the 2000s, the industry ran into the very same pain points: researchers demonstrated that you could pinpoint where a specific client’s data was physically located within “the cloud” and use that for targeted attacks. There were also data losses caused by failures in the cloud infrastructure itself — not an attack, just the unreliability of a young technology. And there were plain old stories, too, like a small cloud service’s servers going down and permanently wiping out all its users’ data.
So the logic of “new infrastructure → new attack vectors nobody saw coming” repeats itself almost exactly. Back then, the industry responded with standardization — and there’s good reason to believe space will follow the same path, just with the couple-decade delay we’ve already talked about above.
The Bigger Picture
If you look at the whole arc — from an onboard computer weaker than a smartphone to data centers in orbit — the same logic shows up at every level. Space software isn’t behind Earth’s because the industry is slow-moving; it’s behind because every constraint (radiation, mass, power) demands its own, far more expensive solution to a problem that off-the-shelf software solved on Earth long ago. But wherever that constraint eases up — whether it’s onboard computing power, data transfer speed, or launch economics — space almost literally retraces the path IT already walked on Earth: from hardware to service, from manual control to automation, from closed systems to the same cybersecurity questions that were once new territory for the cloud, too.
The difference is that here, this path isn’t playing out over decades — it’s happening in front of us. And, importantly for us, there’s still time to get in on the parts of it that are just now taking shape: whether that’s software for orbital compute, tools for managing constellations, or services built on top of space data. That’s actually exactly what we do at Space Ambition — mapping out where in this transformation there’s room for new business.
If this topic resonated with you — we have a separate study on orbital data centers with a full cost breakdown, and we’re continuing to dig into these subjects. Text us to ivan@spaceambition.org and we will share our opinion and results.
And if you’re personally thinking about how to get into the space industry — as a strategist, investor, or entrepreneur — that’s exactly the kind of work we do in Space Ambition’s consulting practice: from market mapping to developing a concrete business concept. Get in touch with Denis via denis@spaceambition.org — let’s talk about what’s on your mind.
So the question is what are the major bottlenecks and what technologies can we use from open source and other sectors to reduce cost per MW and ensure system safety
Automation changes the failure unit: one operator mistake once affected one spacecraft, while a policy mistake in fleet software can propagate across a constellation. The scaling problem is governance as much as compute.