Platform architecture

The Parsimoni Platform builds payload applications, moves them to the spacecraft, and runs them there. The same application can run on a developer laptop and on flight hardware without changing its identity.

Each stage belongs to a different component. Space CLI builds, Space Store publishes, Space CCSDS carries software across the link, and SpaceOS runs it on the node.

The platform components

The Parsimoni Platform has four product components:

Component	Stage	Role
Space CLI	Build	Builds application artifacts and signed system compositions.
Space Store	Share	Publishes applications to the run.space marketplace, accepts orders, schedules work, and delivers results.
Space CCSDS	Share and run	Carries releases and results across intermittent space links.
SpaceOS	Run	Checks, starts, and watches payload workloads on one node.

The components use standard formats and protocols rather than proprietary ones. OCI, the container-image format, packages both applications and complete system compositions. CCSDS and DTN protocols move data over the space link. Solo5 provides a small host interface for unikernels.

You can use each component on its own. For example, you can keep an existing registry and ground system while adopting SpaceOS on the payload computer. You can also use run.space for the complete workflow.

Follow a release

Build a composition, run it locally, publish it, and prepare a release for a connected target:

space build . -t ghcr.io/<your-org>/cloud-mask:1
space run ghcr.io/<your-org>/cloud-mask:1 --runtime run.yaml
space push ghcr.io/<your-org>/cloud-mask:1
space deploy ghcr.io/<your-org>/cloud-mask:1 --target sat-42 --plan
space deploy ghcr.io/<your-org>/cloud-mask:1 --target sat-42

space build creates the signed composition. space run boots it through the local runner. space push copies it to an OCI registry. The first deploy command prints the resolved release without sending it. The second queues that release for the target.

Build the software

An application enters the build stage through an app.yaml file or a Dockerfile. The output is an OCI artifact. A MirageOS or Unikraft binary uses the same registry format as a Linux root filesystem.

build.yaml combines those artifacts into a composition. It names each service and its interfaces. It also defines storage and service dependencies. It does not select a board.

run.yaml says where services run and what resources they receive. It assigns memory and CPU sets. It also selects an isolation backend and routes telemetry frames. The connected target supplies the CPU architecture, boot files, available devices, and signing keys.

Application identity remains stable across targets. One OCI index can contain builds for several CPU architectures. Space CLI selects the right build for the target and assembles its boot image without changing the composition.

Move software to the spacecraft

The Platform stores applications and compositions as OCI artifacts. You can keep them in any compatible registry. The artifacts include signatures and a record of how they were built. space push publishes an artifact but does not start it on a target.

Spacecraft links exist for minutes at a time, drop mid-transfer, and cannot be retried on demand. Space CCSDS therefore uses four CCSDS and DTN protocols instead of ordinary TCP transport:

• CFDP transfers objects and resumes incomplete delivery.
• BPv7 stores and forwards objects across contact windows.
• BPSec protects objects end to end.
• SDLS protects each CCSDS data-link hop.

The ground service queues and routes signed artifacts. The spacecraft checks each artifact against its trusted keys before accepting it. A network connection alone cannot launch software or send an authorized command.

Keep applications separate from SpaceOS

On Linux targets, SpaceOS uses a small control domain called dom0, a name borrowed from Xen’s domain 0. Application code never runs there. dom0 holds a fixed set of SpaceOS services, referred to by name throughout:

Service	Role
space-init	PID 1 in dom0. Verifies the launch plan, brings up the other services, and drives the node to safe mode on a control-plane fault.
space-runner	Admits and supervises workloads: checks signatures, starts each service in its isolation backend, runs healthchecks, and owns the host half of the supervision page.
space-net	The isolated network switch. Assigns addresses on the service IP LAN and forwards only the connections the signed release allows.
space-secret	Key custody. Turns a key identifier into key bytes; nothing else on the node can.

Log, metric, and device brokers sit beside them on the same pattern: each owns one privileged host resource, and each hands out only the access named in the signed release. Before starting a service, space-runner checks that the target actually has the memory, CPU, and devices the service asked for, then starts it with the selected isolation backend.

Under static dom0less Xen the hypervisor starts each domain itself from the device tree, with no dom0 and no toolstack on the running system. The partition layout is fixed before the board boots, and nothing can add a domain afterwards.

Library operating systems

A library operating system links an application with the operating-system libraries it uses. The result is a sealed machine image rather than a process installed into a general-purpose guest.

The Platform supports two unikernel families:

• MirageOS builds OCaml applications against the small Solo5 host ABI.
• Unikraft packages C, C++, Rust, and POSIX-oriented applications.

Each unikernel runs in its own virtual machine or separation-kernel partition. It has no package manager, shell, or dynamic linker, so there is nothing inside to reconfigure at runtime. The host interface is set at build time.

Linux containers remain part of the model. They share the dom0 kernel and use runc namespaces, seccomp, and cgroups. This path runs existing OCI software without a unikernel port.

The flight domain stays separate

SpaceOS owns the payload domain. It does not replace the flight controller, which is hard-real-time software: a missed deadline there is a spacecraft event, not a latency spike. SpaceOS makes no such timing guarantee.

The flight computer boots and recovers on its own. Its watchdog, the hardware timer that resets the board when software stops refreshing it, does not depend on SpaceOS. SpaceOS exchanges fixed-size telemetry and command messages with the flight computer over the mission bus. The flight computer checks every command signature before acting.

The same boundary works when the domains use separate computers or share a separation kernel.

Verify software before it starts

Every build produces signed, content-addressed artifacts, named by the digest of their bytes rather than by a mutable tag. Target assembly adds the board-specific boot signature. At launch, the node checks the TUF trust bundle against a root key pinned into the device image, then matches each service digest to the bytes it runs.

Different keys approve different actions:

Key	What it approves
Build key	Applications and the composition
Target boot key	Board-specific boot image
Release key	Kernel, runner, application set, and security version
Mission command key	Commands that change spacecraft state
Link keys	Data sent over the ground link

The ground service can move these objects. It cannot sign a release or command for the node.