OrchestraOS Specification¶

Release Cycles and Distribution¶

Public release of OrchestraOS on GitHub: 2026 Q1.
Major releases are based on the Yocto release cycle and use only Long-Term Support releases.
Feature releases are based on the feature roadmap.
Minor releases are based on detected CVEs and bug fixes to official meta-layers.

OrchestraOS is distributed through a dedicated Gitea instance. After the public release, the public parts will also be available on GitHub.

All on-demand features and integrations are available only through Gitea. Customers receive dedicated access to Gitea and to all meta-layers included in their agreement.

Essential Information¶

Kernel version	6.6+
U-Boot version	2023.04 / 2024.04 (depends on Gateway type)
Yocto version	5.0+ (Scarthgap - LTS)

OS Features¶

System	Base lean system which supports a wide hardware portfolio (CLI or GUI)
Native Orchestra Daemon support	Containerized deployments of applications using Orchestra CALM Certificates/Keys provisioning Remote device management Data collection
Base system features (included in vanilla OrchestraOS)	Read-only rootfs Update System (RDFM + Mender - test/prototype pipeline) Update System (RAUC + hawkBit - production-grade pipelines) Dedicated RW data partition Dedicated App partitions with A/B partitioning Rootfs with A/B partitioning Bootloader (U-Boot) with A/B partitioning Docker support SSH access Out-of-the-box support for CTHINGS.CO Edge IoT Connectivity Cards, including host software such as Wirepas Gateway Application, BlueZ for Bluetooth applications, and ModemManager support for modems TPM2 support
On-demand example features	Delta Updates Update System of your choice (RAUC, Mender, others also possible on demand) Package Management (.rpm, .opkg) Custom FS types and overlays, e.g. btrfs Kiosk mode for GUI distributions Locally hosted configuration UI GUI Applications Custom Network configuration Custom meta-layer integrations Industrial Hardening: Disabling HW interfaces Disabling console/logging, etc. Factory Reset Service
On-demand example security features	TPM2 custom bindings Secure Boot (boot chain-of-trust) Encrypted Boot (U-Boot only) DM-Crypt (encrypted FS for LVM partition only) DM-Verity (read-only FS protected on block device level) Firewall configuration Software Bill of Materials (build-time and run-time) System Software Supervisor NPU Support GPU Support

Support Models¶

Support model	CTHINGS.CO	Customer
Fully outsourced	CTHINGS.CO provides the BSP and image generation infrastructure, Customer’s application integration, logistics, and delivery.	Customer provides the application to be integrated. Provisioning information, certificates, keys, etc. are provided by the Customer, or provisioning can be performed using the Customer’s application on boot (preferred).
BSP handover	CTHINGS.CO provides the BSP in the form of shared code with placeholder software and provides the necessary tooling for the Customer to build an image in the Customer’s infrastructure. CTHINGS.CO manufactures the final gateway using images provided by the Customer and handles logistics.	Customer fills in the placeholder software delivered by CTHINGS.CO and generates an image. Images are handed over to CTHINGS.CO for final manufacturing along with the relevant provisioning information, certificates, keys, etc. Alternatively, provisioning can be performed using the Customer’s application on boot (preferred).
Layers handover	CTHINGS.CO shares meta-layers with the Customer. Some of them might be public. Relevant on-demand features are implemented and shared through an isolated Git service.	BSP build and Customer application integration are performed on the Customer’s side. CTHINGS.CO only handles manufacturing and logistics. The Customer must provide the final image and relevant provisioning information. Alternatively, provisioning can be performed using the Customer’s application on boot (preferred).

Support model

CTHINGS.CO

Customer

Fully outsourced

CTHINGS.CO provides the BSP and image generation infrastructure, Customer’s application integration, logistics, and delivery.

Customer provides the application to be integrated. Provisioning information, certificates, keys, etc. are provided by the Customer, or provisioning can be performed using the Customer’s application on boot (preferred).

BSP handover

CTHINGS.CO provides the BSP in the form of shared code with placeholder software and provides the necessary tooling for the Customer to build an image in the Customer’s infrastructure.

CTHINGS.CO manufactures the final gateway using images provided by the Customer and handles logistics.

Customer fills in the placeholder software delivered by CTHINGS.CO and generates an image.

Images are handed over to CTHINGS.CO for final manufacturing along with the relevant provisioning information, certificates, keys, etc. Alternatively, provisioning can be performed using the Customer’s application on boot (preferred).

Layers handover

CTHINGS.CO shares meta-layers with the Customer. Some of them might be public. Relevant on-demand features are implemented and shared through an isolated Git service.

BSP build and Customer application integration are performed on the Customer’s side. CTHINGS.CO only handles manufacturing and logistics.

The Customer must provide the final image and relevant provisioning information. Alternatively, provisioning can be performed using the Customer’s application on boot (preferred).