Integration models

SpaceOS admits and runs isolated workloads through the same minimal Linux control plane on every target. What differs is how much of the host computer that control plane owns. There are two integration models.

Inspect the integration model

Show the profile attached to a connected target:

$ space target connect cm5-demo --profile cm5-dev \
>   --endpoint ipn:7.1 --cla-address cm5-demo.local:4556 --always-reachable
Generated signing key: /tmp/space-docs/config/keys/target-cm5-demo-boot.pem
Generated acknowledgement key: /tmp/space-docs/config/keys/target-cm5-demo-ack.pem
target/cm5-demo connected
$ space target show cm5-demo
name         : cm5-demo
context      : local
profile      : cm5-dev@sha256:4d9ea311b399dc777b09e846f1c637dbf04e49d579a79cc42a7a2cfa00181828
board        : raspberrypi-cm5
signing-key  : /tmp/space-docs/config/keys/target-cm5-demo-boot.pem
dtb          : (firmware stock)
kernel       : (composition default)
state-key    : (none: unauthenticated boot-state)
ack-key      : /tmp/space-docs/config/keys/target-cm5-demo-ack.pem
recipient-key: (none: whole-bundle delivery only)
recipient-id : (none)
endpoint     : ipn:7.1
cla-address  : cm5-demo.local:4556
contact      : always (a node on a network)
rate         : 1e+06 B/s (default)

A system-image target’s output names the kernel, device tree, firmware, boot layout, and secure-boot policy. A daemon target leaves those fields to the vendor image, and its profile names the available runtime backends. When the target’s manifest declares provision: resources, space target show follows the record with the provider state and any outstanding plan.

Check the resolved model before deployment:

space deploy payload:release --target <target> --plan

The release plan says whether Space CLI assembles a boot image or sends a workload release to an enrolled runner.

Provision and connect a target

Cloud instances and satellites are the same kind of target. Each has an exact profile, a node identity, and a transport. Bring-up differs between them because different systems own the hardware boundary.

Stage	Cloud or provider VM	Physical satellite or edge computer
Provision	Create the boot image, instance, data volume, address, and firewall through the provider API.	Flash a system image or install the SpaceOS daemon through the board-specific bring-up procedure.
Connect	Bind the running node to its profile, identity, signing custody, and always-reachable IP transport.	Bind the node to its profile, identity, signing custody, DTN endpoint, and convergence-layer route, with an orbit-derived or fixed contact window.
Operate	Deliver routine signed releases with space deploy.	Deliver routine signed releases with space deploy.

Space CLI manages cloud resources because they are the cloud equivalent of physical boot media, power-on state, storage, and network attachment. A VM created from an unpinned image, or attached to the wrong volume, is not the target its profile describes.

Provisioning and connection use separate authorities even when one command converges them. space target apply uses provider or hardware custody to create the resource, then records the platform identity, signing custody, and transport. It acts as soon as you run it, and it may start billable cloud resources or change physical media. --plan rehearses the same reconciliation and stops without touching anything. space target connect performs only the second stage for a resource that already exists.

space target apply names its target positionally, as space target connect and space target rm do: the target is what the verb acts on. --target is still accepted. The name is optional either way. Given none, the command acts on the single target declared in the project’s targets/ directory, or on the single target connected to the current context. Two candidates is an error that names both, and space target ls marks the target a bare command would act on.

Provider resources outlive the target

space target rm NAME removes the target from the context registry. It does not release anything at the provider. The registry namespace, security group, data volume, routed IPv4, and instance that space target apply created keep running and keep billing until you delete them in the provider’s own console or API.

A resource created by a provider API, a board flashed at a bench, and a daemon installed on vendor Linux all connect through the same target record. Once connected, a node in a data centre and a node in orbit take the same deployment path. Only the profile and the transport differ.

Ground DTN node

The selected context owns the ground DTN node, its durable bundle store, and the routes to connected targets. The target record supplies the spacecraft endpoint and contact plan. Its convergence-layer address names either a direct bench listener or the station gateway that can reach the spacecraft. Ground infrastructure therefore stays out of the target definition.

The built-in local context runs the ground node on your laptop for bench and direct-contact work. A run.space context gives you a managed ground node in cloud infrastructure; a station gateway next to the modem joins that node to the RF link. A private or partner context names its own scheduler and ground endpoints with space context create.

space target apply installs the route in the context while it creates and connects a new target. space target connect installs the same route for an existing target. You provision ground services once with their context, and every satellite in that context uses them.

System image

The image Space CLI assembles in the system-image model is the operating system on the target. space build emits a target-agnostic composition. space run and space deploy assemble it into a bootable image for one target, taking the board kernel, device tree, and firmware from the connected target profile.

SpaceOS then owns the boot path end to end: the signed boot object, the read-only root protected by dm-verity, the content store holding the release history, and every service above them. Two targets take the system image:

• Development VM. One dom0 VM on your laptop (Apple Virtualization framework on macOS, QEMU/KVM on Linux) runs the control plane; workloads run inside it through the signed admission path.
• Raspberry Pi CM5. The same logical image assembled as a flashable cm5.img behind the board’s native secure boot.

Choose the system image whenever you control the board. It gives you verified boot, measured launch, health-gated updates, and rollback protection.

Daemon install

The daemon model runs SpaceOS on a Linux image owned by the platform vendor, built and shipped as that board’s board support package. Images assembled with the Yocto build system are common, including PetaLinux on the VCK190 and NXP LSDK on the LX2160A. The host keeps the boot path, kernel, and device drivers. You install space-runner as a systemd unit, and it launches workloads with the isolation the host kernel offers: runc containers for Linux services, and for unikernels either hvt micro-VMs where /dev/kvm exists or the spt seccomp tender where it does not.

Every target except the CM5 and the development VM is a daemon install: a hosted Linux host, and the Raspberry Pi 4B, VCK190, LX2160A, Jetson TX2i, Kalray Coolidge V1, and Innoflight CFC-400 boards, all of which keep their vendor Linux and run SpaceOS on top. Each node enrolls into a ground context as a runner and joins the same control plane, where it accepts the same signed workloads as any other node. The target matrix gives the release each profile ships in.

Connect the node to your context as a target once the SpaceOS services are installed on the vendor Linux. space target connect performs that step for a node that already exists, and a daemon install reaches the control plane through the same target record as any other node.

Confirm the node and start a signed workload through the selected context:

space target show <node-name>
space run --name payload payload:release --runtime run.yaml
space status payload

A daemon install keeps workload admission and update security. Admission is the same signed, offline path that refuses to launch when anything fails to verify, checking the pinned root and the committed launch digests. Workload updates roll out blue/green with health-gated promotion and rollback. The SpaceOS runtime updates itself through the same signed release path and keeps the previous version for rollback.

SpaceOS does not own verified boot of the vendor OS in this model, and there is no whole-OS release rollback. Isolation evidence reaches as far as the vendor kernel supports. Runtime status reports the evidence available for the selected integration model.

Ownership comparison

SpaceOS owns	System image	Daemon install
Boot path and bootloader	Yes	Host
Host kernel	Yes	Host
Verified boot (dm-verity, signed boot object)	Yes	No
Whole-OS system releases (trial/confirm/rollback)	Yes	No
Workload admission (signed, offline, refuses on any failure)	Yes	Yes
Workload updates (signed, blue/green, health-gated)	Yes	Yes
Runtime self-update (signed, previous retained)	Yes	Yes
Workload isolation backends (hvt, spt, runc)	Yes	Kernel-dependent
Partition and service lifecycle	Yes	Yes
Telemetry, logs, metrics collection	Yes	Yes
Ground-link stack (CFDP/BPv7/BPSec, SDLS)	Yes	Shared with host

Both models run the same signed compositions. Moving a workload from a daemon-install bench to a system-image target changes only the target registration. The application is unchanged.

Wire formats

The protocol stack does not change with the integration model:

• Ground-bound traffic is CCSDS. SDLS protects each data link; CFDP Class 2 over BPv7 with BPSec carries objects end to end across contact windows. In a daemon install the host’s flight software may own the final radio, in which case SpaceOS hands off the framed stream at the host boundary.
• On-board application traffic is IP. Services talk to each other on a policy-gated IP LAN switched by space-net.
• Telemetry and command frames use the frame bus. It is the CCSDS-native on-board path between partitions, the flight domain, and the ground edge.
• The local control plane is a Unix socket. The CLI commands the runner over a local socket with authenticated peer credentials. Remote commands require signed command envelopes; network connectivity alone grants no authority.

Picking a model

If the target is…	Model
A development laptop	System image (the dev VM)
A Raspberry Pi CM5	System image
An operator-owned Linux host	Daemon install
Any other board in the target matrix (vendor Linux stays)	Daemon install
A flight computer with a fixed vendor BSP	Daemon install

A fleet can mix models. A CM5 bench node on the system image and a vendor flight computer on a daemon install enroll in the same context and receive the same releases.