Highlights | Mender Orchestrator for component orchestration is now generally available. Mender Orchestrator coordinates software updates across every component in a system — a Linux gateway, microcontrollers, peripherals (e.g., CAN bus or I2C), and the applications running on each — as one atomic operation. Declare the system in a Topology and the desired software state in a Manifest; Mender Orchestrator applies the changes in a user-defined order. If any component fails to update, Mender Orchestrator rolls back the entire system to an operable state. Mender Orchestrator introduces a new System device tier, available exclusively on the Mender Enterprise plan.
Rarely are connected products a single device anymore. A vehicle combines a telematics unit with dozens of electronic control units (ECUs); a surgical robot pairs an application processor with motor controllers and an imaging module; an industrial line runs gateways, programmable logic controllers (PLCs), and vision systems side by side. Each of these components has its own firmware, update mechanism, and failure modes — but the product only operates when all components run compatible versions between each other.
Until now, keeping components within a product in sync required building and maintaining custom wrapper logic around single-device updates. Mender Orchestrator replaces that custom code and manual process with a declarative, system-level software update model built on the same secure and robust foundations as single-device updates.
According to Northern.tech’s annual OEM research, 90% of OEMs report managing products with multiple devices and internal components, and 85% expect that internal complexity to grow over the next 12 months. Three in five expect their current device management approach to become inadequate within three years.
Embedded engineers know this looming failure mode well from updating single devices. Updating a device package by package works — until a package update fails halfway through or power drops mid-install, leaving the device with a mix of old and new software that was never tested together. Mismatched software states are precisely why robust embedded update strategies moved to full A/B image updates; the new image is installed to an inactive partition, verified on boot, and committed only if it works. Otherwise, the device boots back into the previous, known-good image. A/B image updates eliminate the possibility of a mismatched software state altogether.
The same problem exists for a multi-component product, one level up. Updating a single component is a partial update of the system. If the gateway moves to a new protocol version but a downstream controller fails to update, the product is left in an inconsistent state — every component may be healthy on its own, yet the system as a whole runs an unvalidated and untested combination.
Mender Orchestrator brings robust updates to the system, the way A/B image updates brought robust updates to a single device. The system — not the individual component — becomes the unit to update and the unit to roll back: either every component reaches the new Manifest state, or the system returns to the previous one.
A System device is defined for each multi-component product or system; the System device is a Linux-based component within the system that communicates with the Mender Server and can reach every other component. Mender Orchestrator runs on the System device it inspects the System’s current state, reads the desired state, and applies the changes needed.
Three concepts define the component orchestration model.
The Topology is a YAML file, provisioned with the system, that lists which components are present and which Interface updates each of them. Component types and IDs present on a system are reported to the Mender Server as inventory, so the Server knows the shape of every system in the fleet.
api_version: "mender/v1"
kind: "topology"
system_type: "electric-vehicle-2026"
components:
- component_type: telematics_control_unit
interface: rootfs-image
- component_type: ecu_brake_controller
interface: canbus
interface_args: ["front", "15:22:aa:33:ff"]
- component_type: seat_heating
interface: i2c
interface_args: ["--bus=1", "--address=0x48"]
The components list can also live in a separate file. A separate components file is useful when the hardware configuration is generated during manufacturing, and the system type stays fixed in the image.
The Manifest defines the exact combination of Artifacts that should run on each component type, and the order in which components are updated. Because it describes a target state, components that already provide the requested Artifact are left untouched.
api_version: "mender/v1"
kind: "manifest"
name: "electric-vehicle-software-v3.2.1"
system_types_compatible: ["electric-vehicle-2026"]
component_types:
ecu_brake_controller:
artifact_name: brake-ecu-firmware-v1.8.3
update_strategy:
order: 10
seat_heating:
artifact_name: seat-heating-fw-v1.2.0
update_strategy:
order: 20
telematics_control_unit:
artifact_name: tcu-v2.4.1
update_strategy:
order: 30Components are updated in ascending order; components that share an order value are updated in parallel. A Manifest is packaged as a regular Mender Artifact with the mender-orchestrator-manifest payload type, so it can be uploaded, versioned, and deployed like any other Artifact.
An Interface is a command-line executable that translates between Mender Orchestrator and a specific component type — such as, CAN bus, I2C, MQTT, a serial line, or a proprietary protocol. Interfaces are modeled on Mender Update Modules and leverage similar states, including: Download, ArtifactInstall, ArtifactReboot, ArtifactVerifyReboot, ArtifactCommit, and Cleanup, as well as rollback and failure states.
Interfaces also answer queries such as Provides, which reports the software version currently installed on the component, Identity, which returns a unique Component ID, and Inventory which reports any other relevant attributes about the component. An Interface for the System device itself (rootfs-image) ships out of the box.
# /usr/share/mender-orchestrator/interfaces/v1/canbus
canbus ArtifactInstall /data/mender/modules/0000 ecu_brake_controller front 15:22:aa:33:ffMender Orchestrator executes an update in phases — all components that share the same order value.
Starting with the lowest order group:
If any component fails before commit, Mender Orchestrator reverses direction.
Starting from the highest order group already processed, Mender Orchestrator rolls back each component whose Interface reports SupportsRollback, returning the system to the previous Manifest state — its last known good state. Reboots can also be grouped; Interfaces that answer Automatic to NeedsArtifactReboot share a single reboot of the system device instead of one each.
Note: System-wide rollback depends on each component’s Interface implementing rollback. Components whose Interface does not support rollback cannot be reverted automatically.
For fleet-wide operations, the Mender Client on the System device receives a Manifest Artifact from the Mender Server. The Mender Orchestrator then handles reboots and state transitions. Artifacts referenced by artifact_name are downloaded from the Mender Server as each component is updated.
On System tier devices, the Mender Client uses the System type from the Topology when polling for deployments and installing Manifest Artifacts.
For air gapped networks, service-technician workflows, or factory provisioning, Mender Orchestrator can run without a Mender Server. A Manifest can reference local Artifacts with artifact_path, which takes precedence over artifact_name, and falls back to artifact_name if the file is not present.
ecu_brake_controller:
artifact_path: /artifacts/brake-ecu-firmware-v1.8.3.mender
artifact_name: brake-ecu-firmware-v1.8.3
update_strategy:
order: 10Mender Orchestrator and its support files — the mender-orchestrator-manifest Update Module and the System-device Interface — are delivered through the mender-orchestrator-support Yocto recipe and Debian package. Existing Mender devices can be upgraded to the System device tier without reprovisioning.
Mender Orchestrator is available today with the Mender Enterprise plan. Devices running Mender Orchestrator use the System device tier (designed for devices that coordinate updates across multiple components), which carries its own device limit. This device tier is separate from the Standard and Micro device tiers.
Note: System tier devices are not included in the Mender free trial. To evaluate Mender Orchestrator, start a free trial and contact us — our customer engineering team will set up an Enterprise evaluation tenant with System tier devices so you can install Mender Orchestrator on your own hardware.
The Orchestrate updates chapter in the Mender documentation covers the full Topology, Manifest, and Interface Protocols. Three provided examples are also available to try the model before integrating components:
Share your feedback about Mender Orchestrator and suggestions for future improvements in the Mender Hub General Discussions forum. If you encounter any issues, please report them in the Mender JIRA issue tracker with detailed reproduction steps and system information.