Supported targets

A target profile records the facts needed to assemble and run a release on one class of computer. The target record adds the node identity, signing key, and ground route.

How to read the last column

Yes means the target works today: a profile ships in the catalog, repeatable evidence exercises what that profile claims, and space target connect resolves it by name. A row marked WIP does not work today. It is on this page because it is where the platform is going, and it says which of two things it is: demonstrated, SpaceOS has run on that hardware on a test bench and no profile ships for it; or planned, the bring-up is designed and not finished. Nothing on this page turns a marked row into a working one.

space embeds the catalog snapshot released with the CLI, and space target catalog sync updates a managed checkout of it from the public parsimoni-labs/targets repository. A project can carry a profile under profiles/; that project profile takes precedence over the managed and embedded catalogs. Every connection stores the resolved profile’s exact content digest.

Two scales, and they answer different questions

A target is described on two independent axes, and a board needs both.

How SpaceOS is deployed. Either it is the operating system, assembled as a flashable or bootable image and owning the boot path, or it is a daemon set installed onto an operating system the board’s vendor ships.

How applications run. A service runs under an isolation backend: a container under runc, or a unikernel under a Solo5 tender, Firecracker, or QEMU. Which backends a target offers is a fact of its profile, and Substrates gives the matrix.

Target matrix

Target	Architecture	Integration	Isolation backends	Ready today
Development VM (macOS on Apple silicon)	arm64	System image on the host VMM	runc	Yes
Raspberry Pi CM5	arm64	System image, flashed	hvt, runc	Yes
Hosted Linux	arm64	Daemon	runc	Yes
Provider instance (Scaleway)	arm64	System image, UEFI	runc	Yes
Xilinx VCK190	arm64	Daemon	qemu, firecracker, hvt	WIP demonstrated, accelerated
NVIDIA Jetson TX2i	arm64	Daemon	qemu, firecracker, hvt	WIP demonstrated, accelerated
NXP LX2160A	arm64	Daemon	qemu, firecracker, hvt	WIP demonstrated, minimal
Raspberry Pi 4B	arm64	Daemon	qemu, firecracker, hvt	WIP demonstrated, minimal
Kalray Coolidge V1	amd64	Daemon	qemu, hvt	WIP demonstrated, minimal
Innoflight CFC-400XS	arm64	Daemon	Xen	WIP planned

Ready today: four targets

Four profiles ship in the catalog. Each names the exact boot contract, runtime backends, and ceilings that a connection pins by digest, and each is something you can connect and deploy to now.

• Development VM. A macOS host on Apple silicon boots the system image through Apple’s Virtualization.framework. This is what space run uses, and the profile admits runc workloads.
• Raspberry Pi CM5. SpaceOS is assembled as a flashable image with the Raspberry Pi firmware partition first, verified by the board’s own signed boot and a command-line-pinned dm-verity root. Two profiles ship: a bench profile with reversible signature enrolment, and a locked profile that requires OTP enrolment and a discrete TPM.
• Hosted Linux. Any operator-owned host with cgroup v2 and systemd v229 or newer. The signed daemon bundle installs under a prefix, the host keeps its own trust boundary, and nothing is flashed.
• Provider instance. An arm64 cloud instance booting UEFI from a block volume created from an imported, content-addressed image. The provider’s hypervisor is the boot trust anchor.

WIP five demonstrated boards

SpaceOS has run on five further boards on a test bench. No profile ships for any of them, so space target connect resolves none of them by name today and deploying to one is bring-up work. They are listed because each is a target the platform is being built toward. The grade below records what has run on the bench.

Each is graded on the four-level scale the platform’s hardware evaluation uses:

• None, the combination has not been tested or does not work.
• Prototype, unikernels run in static partitions with CPU and memory isolation and at least serial access. There is no dynamic orchestration and no access to storage or acceleration.
• Minimal, the local orchestrator schedules unikernels dynamically and talks to ground software over the network. Unikernels reach local storage, downlink data, and request input from the local manager.
• Accelerated, the same, and unikernels also drive an on-board GPU or FPGA without interfering with each other. A board with no accelerator tops out at minimal, so accelerated on this page always means a device was in use.

What each board reached:

• Xilinx VCK190. Accelerated under qemu and firecracker, minimal under hvt. FPGA work runs through the board’s own acceleration API, delegated from the unikernel to the host.
• NVIDIA Jetson TX2i. Accelerated under qemu and firecracker, minimal under hvt. Unikernels made full use of the on-board GPU.
• NXP LX2160A. Minimal under every isolation platform tried, including Xen with Linux as dom0. The board carries no accelerator, so minimal is its ceiling.
• Raspberry Pi 4B. Minimal under every isolation platform tried, including Xen. It is also the board where a seL4 prototype ran: unikernels partitioned by the microkernel with serial access only and no Linux involved.
• Kalray Coolidge V1. Minimal under qemu and hvt. Acceleration through the board’s OpenCL path is in progress.

WIP one planned board

• Innoflight CFC-400XS. SpaceOS is planned as a daemon set on the board’s stock distribution, with Xen as the tenant isolation. Neither the Xen boot path nor the Xen runner backend exists yet, so nothing on this board runs today.

Connect an existing target

Create targets/cm5-demo.yaml:

schema: space.target
version: "1"
profile: cm5-dev
connection:
  signing_key: keys/cm5-demo.pem
  endpoint: ipn:7.1
  cla_address: cm5-demo.local:4556
  always_reachable: true

The profile names the computer class. The connection section holds this node’s key custody and the route that carries its releases.

$ space target connect cm5-demo
Generated acknowledgement key: /tmp/space-docs/config/keys/target-cm5-demo-ack.pem
target/cm5-demo connected
$ space target ls
   NAME      PROFILE  BOARD            ENDPOINT  CONTACT
   cm5-demo  cm5-dev  raspberrypi-cm5  ipn:7.1   always
$ space target show cm5-demo
name         : cm5-demo
context      : local
profile      : cm5-dev@sha256:...
board        : raspberrypi-cm5
signing-key  : keys/cm5-demo.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)

The RSA key signs the CM5 boot image, which is the signature the Raspberry Pi firmware verifies. The generated Ed25519 key authenticates deployment acknowledgements from this node. In production, set ack_key to a key-management system path. When it is left out, the CLI generates a local bring-up key.

A target reached over scheduled contacts needs --tle with --station, or a fixed --contact-start and --contact-stop.

space target connect records a provider VM, Linux host, edge computer, or satellite that is already up. It binds the resource to an exact target profile, identity, signing custody, and transport. It allocates nothing.

Use space target apply when Space should create or reconcile the resource and connect it in one operation. It acts by default; --plan prints the plan and stops.

Inspect connected targets

The session above runs space target ls for the targets connected to the current context, then space target show cm5-demo for the profile and node-specific settings a deploy resolves. space target ls marks the target a command with no --target acts on.

space target show prints the registry record for every target. It also prints what the provider holds against that spec for a target whose manifest declares provision: resources. That half covers the server, the routed IP, the data volume, the security group, the registry namespace, and any outstanding plan. Without provider credentials it reports the provider half unavailable. A bench board has no provider half at all.

space deploy --plan copies the resolved facts into the release descriptor. --target is optional. It defaults to the single target declared in targets/, else the single target connected to the current context.