Integration models

SpaceOS uses the same minimal Linux control plane to admit and run isolated workloads everywhere. Deployment determines how that architecture lands on the host computer. There are two integration models.

In the system-image model SpaceOS owns the boot files and Linux host. In the daemon model the vendor owns those layers while SpaceOS owns workload admission and supervision.

Inspect the integration model

Show the profile attached to a connected target:

space target show <target>

For a system-image target, the output names the kernel, device tree, firmware, boot layout, and secure-boot policy. For a daemon target, those fields belong to the vendor image and the profile names the available runtime backends.

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 deployment object: a target with an exact profile, node identity, and transport. Their initial bring-up differs 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 manages cloud resources because they are the cloud equivalent of the 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 described by its profile.

Provisioning and connection use separate authorities even when one command converges them. space target provision uses provider or hardware custody to create the resource, then records the platform identity, signing custody, and transport. It may start billable cloud resources or change physical media. space target connect performs only the second stage for a resource that already exists.

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, routine deployment depends on the profile and transport rather than on whether the node is in a data center or in orbit.

Where the ground DTN node runs

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. This keeps ground infrastructure out of every target definition.

The built-in local context runs the ground node on the developer’s laptop for bench and direct-contact work. A run.space context provides 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 provision 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. Ground services are provisioned once with their context, not once per satellite.

System image

In the system-image model, the image Space CLI assembles 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 a concrete target, with the board kernel, device tree, and firmware taken 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. Full OS support covers two targets:

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 provides verified boot, measured launch, health-gated updates, and rollback protection.

Daemon install

In the daemon model, SpaceOS runs 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. space-runner is installed as a systemd unit and launches workloads with the isolation the host kernel offers: Solo5 hvt micro-VMs where /dev/kvm exists, or the spt seccomp tender where it does not.

The system daemon support level covers every supported board except the CM5: the Raspberry Pi 4B, VCK190, LX2160A, Jetson TX2i, Kalray Coolidge V1, and Innoflight CFC-400 all keep their vendor Linux and run SpaceOS on top. The node enrolls into a ground context as a runner, joins the same control plane as any other node, and accepts the same signed workloads.

After installing the SpaceOS services on the vendor Linux, enroll the node as a runner:

space runner join run.space \
  --name <node-name> \
  --target-profile <profile>@sha256:<digest>

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 retains workload admission and update security. Admission is the same signed, offline path that refuses to launch when anything fails to verify (pinned root, committed launch digests). App updates roll out blue/green with health-gated promotion and rollback, and the SpaceOS runtime updates itself through the same signed release path, retaining the previous version for rollback. The daemon model does not provide SpaceOS-owned verified boot of the vendor OS or whole-OS release rollback, and its isolation evidence is limited to what the vendor kernel provides. Runtime status reports the available evidence 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 the target registration, not the application.

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. 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
Any other supported board (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 can enroll in the same context and receive the same releases.