Overview

The Parsimoni Platform builds, ships, and runs spacecraft payload applications. It applies the workflow developers already know from Docker to the payload domain: you write a Dockerfile or an app manifest, boot the result in an isolated VM on your laptop, and later ship the same signed image to a satellite by connecting a target. Getting bytes to orbit means speaking CCSDS, the standards family every space agency and ground system uses; the deploy command handles that transport for you.

Workloads run one of two ways. Most ship as ordinary Linux containers: package your app with the tooling you already use for cloud. Workloads that need stronger isolation ship as unikernels: small, memory-safe binaries built on MirageOS (OCaml) or Unikraft (C, C++, Rust), with no Linux kernel inside the image. A single deployment can mix both.

Payload software here means earth-observation classifiers, software-defined-radio (SDR) signal processing, deep-space probe data reduction, store-and-forward IoT, on-board anomaly detection. SpaceOS does not run the spacecraft’s hard-real-time flight software (attitude control, command and data handling); that is a separate trust domain connected to SpaceOS over a bus. For payload software, the Platform covers the build, runtime, and deployment path.

The four components

The Platform is four components:

Component	Stage	What it does
Space CLI	Build	The space binary. Builds artifacts and signed compositions, runs them locally, and assembles a per-board release.
Space Store	Share	Publishes applications and accepts orders through the run.space marketplace.
Space CCSDS	Share and run	Carries releases and results across the space link.
SpaceOS	Run	The on-board runtime. Admits, isolates, and supervises workloads on one node.

Each component can be adopted independently or as part of the complete Platform.

Audience

• Developers build and test payload applications with the Space CLI (space).
• Operators connect targets, dry-run and approve releases, and watch deployments cross contact windows.
• Publishers make applications available through the run.space marketplace or a partner catalog.

Use the CLI for build and test work. Use run.space when you need account management, catalog publishing, fleet scheduling, or a managed ground-service endpoint. The hosted surface is run.space: create an account there, sign in once with space login run.space, and point the same verbs at the hosted backend with space context use run.space.

Configuration files

Space CLI reads three declarative files with separate responsibilities:

• app.yaml builds one application from source (kind: mirage, unikraft, or oci) and emits an OCI artifact. A raw Dockerfile is the generic equivalent.
• build.yaml composes a system: partitions, services, storage, and interfaces. It is target-agnostic and carries no board facts.
• run.yaml places a built composition: memory, CPUs, isolation backends, frame-flow policy, and the local ground endpoint.

Board facts (kernel, device tree, firmware, secure-boot keys, uplink transport) belong to a connected target, not to any manifest.

Scaffold, build, and run a project:

space init parsimoni-labs/hello-world
space build
space run

space run IMAGE also boots any OCI image directly, with no manifest, by synthesizing a one-partition composition around it.

Core concepts

Partition The unit of isolation, admission, and supervision: a Solo5 micro-VM for a unikernel service, or a runc sandbox for a Linux service. A fault in one partition cannot affect another, and resources are allocated per partition.

Service A workload that runs inside a partition. Each service is an OCI image; the partition supervisor starts services in dependency order and reports their health.

Isolation backend How a service executes: runc (any Linux app, shared kernel), hvt (Solo5 on KVM, hardware VM isolation), spt (Solo5 without KVM), and friends. The available backends and their support status vary by target.

Data planes Services get a standard IP LAN for application traffic, a CCSDS frame bus for telemetry and command, an optional bulk link for high-throughput data, and a supervision page for liveness. Authorization on every plane is keyed by service identity. The APID, the 11-bit CCSDS number that labels a telemetry or command stream, sorts frames at the edges the way a port number sorts packets; it grants nothing.

Target A connected node: a content-addressed board profile plus node identity, signing custody, and uplink transport. Provider-backed targets can be created with space target provision. Cloud, edge, and satellite nodes connect through space target connect and receive routine releases through space deploy; space run resolves the local development target.

Context A named binding of registry, scheduler, and ground-service endpoints. The built-in local context keeps the runner and ground DTN node on your laptop and has no credential. Hosted or partner contexts are added with space context create and selected with space context use.

Build and run separation

The build / run split separates what you ship from how it is placed. build.yaml describes the target-agnostic composition; run.yaml applies placement policy. The same built composition runs on a development laptop and on a constrained on-board computer with different memory, CPUs, and ground link, without rebuilding:

# run-dev.yaml (developer laptop)
schema: space.run
version: "1"
image: _build/spaceos

partitions:
  payload:
    memory: 1024
    apids: [0x010, 0x01F]
    send_to: [ground]
    services:
      - name: eo-classifier
        isolation: runc
        cpus: [2, 3]
      - name: sdls-downlink
        isolation: spt

relay:
  from: payload
  to: [ground]

ground:
  port: 8080

# run-flight.yaml (satellite OBC)
schema: space.run
version: "1"
image: _build/spaceos

partitions:
  payload:
    memory: 256
    apids: [0x010, 0x01F]
    send_to: [ground]
    services:
      - name: eo-classifier
        isolation: runc
        cpus: [1]
      - name: sdls-downlink
        isolation: hvt

relay:
  from: payload
  to: [ground]

ground:
  port: 8080

Both reference the same build.yaml and the same built image; only resource placement changes.

Deploy to orbit

Connect the target once, build a release, dry-run, then deploy:

space target connect cm5-demo --profile cm5-dev \
  --signing-key keys/cm5-demo.pem \
  --endpoint ipn:7.1 --cla-address cm5-demo.local:4556 --always-reachable
space build . -t north-sea-eo:release --release --signing-profile release
space deploy north-sea-eo:release --target cm5-demo --plan
space deploy north-sea-eo:release --target cm5-demo

space deploy --plan resolves the target, assembles and validates the per-board boot image, prints the release descriptor, and writes no target state. The deploy without --plan enqueues a durable record that survives the CLI exiting, because a contact window may be hours away. Use space status <deploy-id> to follow the pipeline checklist; use space ps for runtime state after activation.

--endpoint and --cla-address are the two halves of a target’s address. The endpoint is the node’s routing name in the delay-tolerant Bundle Protocol, so ipn:7.1 means service 1 on node 7. The convergence-layer adapter address is the concrete host and port that carries bundles to it. Both are explained under endpoint ID and convergence layer.

A remote target must also say when it can be heard: --always-reachable for a bench node on the local network; a TLE, the two-line element set describing an orbit, plus a ground station, for a node reached over real passes; or a pinned contact window. A target that names none is refused.

The --target flag names the node that receives the release. The target record supplies its contact plan and ground route.

Updates and rollback

Updates are health-gated and retain the last healthy state. Workload updates run blue/green: the new generation starts beside the old, must pass its declared healthchecks, and is promoted atomically or rolled back. System updates append to a content store of verified images and confirm after a trial reboot, with automatic fallback. A hardware-backed security-version floor prevents replaying old releases.

Security model

• Signed, offline admission. Every build signs a TUF trust bundle, the same signed-metadata model used for software updates on the ground. The bundle commits each service’s launch digest, and nodes verify launches against a pinned root with no network. No committed digest, no run.
• Verified boot. The read-only system root is protected by dm-verity, which re-checks every block against a signed hash tree as it is read; deploy targets add native board secure boot beneath it.
• Isolation. Unikernel services run as hardware-isolated micro-VMs with no Linux inside the image; Linux services run resource-capped under runc.
• Memory safety. The runtime, the CCSDS stack, and the protocol implementations are OCaml; verified cryptographic primitives come from libcrux.
• Supply-chain transparency. Every build produces a software bill of materials (SBOM): the machine-readable inventory of every package and layer that went into it.

Software bill of materials

space build generates an SBOM for every system image (SPDX 2.3 JSON). space sbom inspects or converts it:

space sbom _build/spaceos                              # SPDX JSON
space sbom --format cyclonedx _build/spaceos           # CycloneDX 1.6

The SBOM records package names, versions, suppliers, and content-addressed checksums. OCaml packages are exact to the package version and commit hash; OCI image layers are recorded by digest.

On-orbit processing use cases

The Platform is for workloads where processing near the sensor changes the mission outcome: less downlink, faster response, or both. These workloads include cloud masking, object detection, SDR preprocessing, anomaly detection, and compression or summarization before a contact window.

Workloads that need constant low-latency interaction with many users, such as serving a public website, belong on terrestrial infrastructure. Put computation in orbit when the raw data is too large to send down or when waiting for the next pass makes the result less valuable.

In Denby and Lucia’s “Orbital Edge Computing” (ASPLOS 2020), an on-orbit data-reduction architecture reduces ground infrastructure 24x and processing latency 617x versus a bent-pipe architecture (paper PDF).