This section is a preview of Mender's support for Orchestrated updates using mender-orchestrator. It is not yet recommended for production use. Also, expect the APIs and configurations to evolve as the implementation matures.
Mender Orchestrator is the software responsible for updating the Components in a System. It is responsible for inspecting the System's current state, such as the software versions running on the Components. The System's architecture is defined by the Topology, which specifies what Components are present and how they can be updated. Mender Orchestrator reads the System's desired state from a Manifest, which defines the exact combination of Artifacts that should be deployed to each Component type and controls the update strategy. Mender Orchestrator then applies the changes to the different Components to reach the state described in the Manifest. If this is not possible, Mender Orchestrator may roll back to the previously known working state, in other words, the previous version of the Manifest.
Mender Orchestrator uses a manifest-based deployment strategy where you define the desired end state in two YAML files:
Mender Orchestrator supports both full System updates and partial updates with granular component-level control. It downloads required Artifacts and coordinates the update process across all Components. If any Component fails, it rolls back the entire System to maintain a healthy end state.
A System is a collection of interdependent Components that work together. Components can run on the same hardware device or across multiple devices that need to maintain version compatibility.
Examples of a System:
For the purpose of introducing the Orchestrator, the example System will consist of the following Components:
Telematic Control Unit:
ECU brake controller:
Seat heating:
A Component is a logical unit that can be updated independently. Components are categorized by Component type and updated through Interfaces. Each Component is defined in the Topology.
We also define a System device
as the Component that runs Mender Orchestrator and communicates with the Mender Server.
A System can only ever have exactly one Device in this taxonomy. In the context of this introduction, the Telematic Control
Unit functions as the System device.
Components are updated sequentially by order value, ascending, as defined in the Manifest. Components with the same
order are updated in parallel (see ordering). It is up to a Component Type's Interface to implement rollback.
If an update to any Component fails, Mender Orchestrator will query the Interface with SupportsRollback
and handle the rollback accordingly.
See the ArtifactRollback state for more details.
Mender Orchestrator obtains Artifacts as specified in the Manifest, either from a local path or by downloading the Artifact from the Mender Server when updating a Component. See the documentation on Manifests for more details.
An Interface is a command line application that serves as a translator between the updatable Component and Mender Orchestrator. This decoupled design allows Mender Orchestrator to work with any custom set of steps or local network protocols a Component needs to be updated.
See the Interface protocol documentation for more information.
In most cases we want to manage a fleet of Mender Orchestrator instances with the Mender Server.
To do this, we use the Mender Client to deploy an Artifact with the mender-orchestrator-manifest
Update Module.
The Update Module can be found in mender-orchestrator-support, and is provided by
the mender-orchestrator-support Yocto recipe and the mender-orchestrator-support Debian package, see the installation section for more information.
mender-orchestrator-manifest
is a regular Update Module that invokes Mender Orchestrator.
The Update Module enables the following update flow:
mender-orchestrator-manifest
In order to run Mender Orchestrator with the Mender Client, you must configure the Device with the system
tier (see the Installation section).
Once that is set, Mender Client will read the System type set in Mender Orchestrator's Topology.
The Mender Client will use the System type as its Type in two specific cases:
mender-orchestrator-manifest
The regular Device type will be used in all other cases. This allows a System device to receive and install Manifests by checking the System type compatibility when needed. It also allows a System device to receive regular rootfs Updates.
© 2025 Northern.tech AS