The software platform for space
Every computing revolution created a software platform.Space is next.
Parsimoni builds SpaceOS, the secure payload operating system that turns idle on-board compute into new revenue. Build, deploy, and update satellite apps the way cloud engineers ship to production.
How we fit
A payload platform, not a flight software replacement
Runs on the payload side
SpaceOS runs in its own partition on the payload computer. Bus software, attitude control and other real-time or safety-critical systems are left as they are.
Works with the hardware you fly
Validated on 8 on-board computers and several hypervisors. You do not need new flight-qualified avionics.
We share in the upside
A modest onboarding fee, then a share of the new revenue or the savings that SpaceOS brings.
How much value is sitting idle in orbit?
A satellite is only fully productive over the right area. For the rest of the orbit, its payload computer is mostly idle.
Idle on-board compute
On-board processors are sized for peak mission needs and then sit underused most of the orbit. NASA JPL data puts average in-orbit compute utilisation near 10%, which represents roughly $5B per year of capacity operators cannot currently monetise.
Frozen at launch
Payload software is written once, per satellite, before launch. Adding a new application afterwards is a custom integration that takes months, if it is possible at all. Missions built for one customer rarely adapt to the next.
Cyber risk blocks new revenue
Operators will not host someone else's code on a flight computer without isolation they trust, because a faulty or malicious app can cost them the satellite. Without that isolation, the spare capacity stays unused.
A payload OS in its own partition
SpaceOS boots in its own partition on the payload computer, where mission applications run. It does not touch bus management, attitude control or any other safety-critical, real-time system.
What SpaceOS does change is the bespoke, one-off payload code that makes every mission a custom integration. Applications are packaged once, run across fleets, updated safely, and isolated from each other on the same hardware.
Operators get a release pipeline and an app store for the satellites they already fly, with isolation strong enough to host third-party code.
On-board architecture
Two partitions on one payload computer
Bus partition
Your flight software, untouched
- ●Bus management, attitude, thermal, power
- ●Real-time control loops
- ●Your existing RTOS and flight code
- ●Safety-critical, mission-qualified
Payload partition
Where SpaceOS runs
- ●Mission applications, isolated from each other
- ●Update and rollback lifecycle (A/B partitions)
- ●App store for first- and third-party workloads
- ●Non-real-time by design
Built to run alongside flight software
SpaceOS runs next to the flight software, isolates applications from each other, updates them safely over intermittent links, and uses post-quantum cryptography.
Payload-only, non-real-time
SpaceOS boots in its own partition on the payload computer. Bus, attitude, thermal, and power control stay on your existing flight OS. Real-time loops are never interrupted by application workloads.
Hardware-backed isolation
Applications run as single-address-space VMs under KVM, Xen, or Muen. Hardware enforces separation between apps and between payload and bus. A radiation-induced memory upset, a crashing app, or a malicious workload stays contained in its own partition and cannot ripple through the rest of the system.
CI/CD lifecycle for orbit
Build, sign, push, deploy, monitor, and roll back the way cloud teams ship to production. A/B partition scheme and content-addressable updates make bad deployments safe to reverse, even over 4 kbit/s links.
20× smaller footprint
10 MB application images instead of 250 MB container stacks. Smaller images mean faster uplinks, cheaper hardware, and a far smaller attack surface. Validated bit-for-bit against Thales Alenia Space workloads.
What operators build with SpaceOS
On hardware already in orbit, operators use SpaceOS to process data on board, protect payloads against cyber attacks, and earn revenue from third-party apps.
On-board AI processing
Validated with Thales Alenia Space
Run inference on board and downlink results instead of raw images. The same AI model runs with a 20× smaller footprint and up to 37% faster.
Read more
Cyber-resilient payloads
Zero sandbox escapes in HACKSAT'25
Applications are isolated by the hardware, written in memory-safe code and protected by post-quantum cryptography. In HACKSAT'25, 34 participants tried for 8 weeks and none escaped the sandbox.
Read more
Satellite app store
ESA-backed, launching with OHB Hellas
Sell unused compute capacity. Third-party apps run isolated from your own software, so you earn new revenue without launching new hardware.
Read moreSpaceOS in practice
Developers build and ship apps from the command line. Operators rent out idle compute through a marketplace.
Build, test locally, then ship to orbit, much as cloud teams ship to production.
Draw your area of interest, pick an app, compare satellite runners. On-board processing cuts downlink costs by up to 7×.
Built with the people already running satellites
SpaceOS is developed and deployed with aerospace partners across Europe, the U.S. and Australia. SpaceOS reached orbit in March 2025 on Clustergate-1 and again in March 2026 on Clustergate-2.
Funded partnerships
EUR 1.5M+ in funded project commitments across ORCHIDE (Horizon Europe, with Thales Alenia Space), CEOS (BPI France 2030), and OSIP (ESA marketplace demonstration).
We are working with Innoflight to offer SpaceOS alongside their CFC-400XS flight computers. OHB Hellas provides the hardware platform for a joint satellite app store project.
Read about the Innoflight partnership →Flight path
First payload launched March 2025 on SpaceX Transporter-13. Clustergate-2 launched March 2026, demonstrating the CCSDS protocol stack with OTA rekeying in orbit.
Mission operators across Europe and the U.S. are evaluating SpaceOS as their payload platform. Parsimoni was selected for the Techstars Space Accelerator (Fall 2025) and the Starburst Paris accelerator. The company has offices in France and California, with further locations planned across the U.S. and Europe.
Read about our first launch →How we engage
Operators keep their satellites, hardware and flight software. After a small onboarding fee, we are paid from the new value SpaceOS creates.
A modest start, then we share the upside
A small onboarding fee gets SpaceOS integrated on your payload. Beyond that, we earn through a share of the new revenue it generates, so most of our return depends on your success.
Participation tied to value
We take a 10 to 15% platform fee on the revenue operators earn from third-party workloads, or on the savings from on-board processing.
Your hardware, your flight software
SpaceOS runs next to what you already operate. There is no bus software to migrate, no new flight-qualified avionics to buy, and no lock-in.
Technical resources
Documentation for technical evaluators. Contact us for early access.
SpaceOS Technical Overview
Coming soonArchitecture, Benchmarks, CCSDS Stack, Cryptography
SpaceOS internals: the unikernel runtime, a footprint up to 20× smaller than K3S, formally verified cryptography, and the CCSDS protocol stack with more than 60 fuzz targets.
SpaceOS and Docker
OCI Compatibility Guide
How the Docker workflow maps to satellites. What transfers, what doesn't. Migration guide for container teams.
Security Architecture
Formal Verification & PQC
Post-quantum cryptography, memory safety, hardware isolation. TCB analysis and threat model for security-critical missions.
Frequently asked questions
Common questions from operators, investors, and technical evaluators.
No. SpaceOS is a payload operating system. It runs in its own partition on the payload computer, where mission applications live. Bus management, attitude control, thermal, power, and any other safety-critical or real-time system stays exactly where it is today. SpaceOS is non-real-time by design.
It runs applications on the payload computer with hardware-backed isolation, so several apps, including third-party ones, can share the hardware safely. It handles the update cycle: build, sign, ship, monitor, and roll back if something misbehaves. And it powers an app store where operators sell idle compute to third-party workloads.
Payload computers capable of running a Type-1 hypervisor (KVM, Xen, or Muen). Validated on 8 on-board computers across ARM and x86 so far, including flight hardware. SpaceOS is hardware-agnostic by design: no new flight-qualified avionics are required to adopt it.
SpaceOS is at TRL 6: system prototype demonstrated in a relevant environment, with two payloads in orbit via DPhi Space's Clustergate missions. Formal qualification under ECSS-Q-ST-80C is typically led by a prime contractor and scoped to a specific mission. The components have production heritage: the network stack ships in Docker Desktop, and the cryptography ships in Chrome and Android via BoringSSL.
Payload applications run as single-address-space VMs under a Type-1 hypervisor, with separation enforced by the hardware rather than by kernel namespaces. In HACKSAT'25, an adversarial security challenge, 34 participants spent 8 weeks attempting to escape the sandbox and attack other applications, with roughly a thousand executions. None succeeded.
Put the compute you already fly to work
If you run a satellite fleet, build payload hardware or write space applications, we would like to hear from you.
Get in touchContact us
Tell us about your mission.