Overview

RAUC, Mender, and OSTree are all popular solutions for over-the-air (OTA) embedded system software updates. They differ in terms of their features, architecture, and performance, making it important to choose the right solution based on the requirements of a particular project.

RAUC is a flexible and efficient tool for OTA updates that uses a bundle concept to package and distribute updates. It is a simple, but powerful tool that provides a reliable way to update embedded systems.

Mender, on the other hand, is a fully featured OTA solution that provides a comprehensive set of tools for updating embedded systems. It offers a complete OTA update process, including server-side and client-side components, as well as management tools for deploying and monitoring updates.

OSTree is an OTA update solution that is designed to provide fast and secure updates for embedded systems. It uses a Git-like system to manage software versions, which allows for easy rollback in case of problems with an update. Additionally, OSTree provides a flexible and efficient system for distributing updates that can be tailored to specific requirements.

Each of these solutions has its own strengths and weaknesses, and it is important to choose the right one based on the needs of a specific project. This document will provide a detailed comparison from different aspects to help in making an informed decision about which solution is best for a project.

Comparison of the three solutions

This section will have a horizontal comparison between the three update projects from a few major aspects we usually use to evaluate an update technology of embedded systems, followed by an evaluation of the pros and cons of each system.

Device Layout Scheme

RAUC:

Supports both “Symmetric A/B” (dual image update framework) or “Asymmetric A/Recovery” (Single image update framework).

Mender:

Supports “Symmetric A/B” (dual image update framework) only.

OSTree:

Unlike the traditional schemes (Symmetric A/B or Asymmetric A/Recovery), OSTree has no concept in a dual or single layout but uses a git-like object repository to record and deploy complete file system trees.

Notes:

RAUC is more flexible than Mender with support on both Symmetric/Asymmetric schemes.

OSTree is the most flexible one since it is able to have multiple file system trees within one repository, only constraint is the storage size.

Filesystem Types

RAUC:

EXT4 for block devices.

UBIFS, UBIMG for MTD devices.

Mender:

No dependencies on a specific file system type, but depends on whether it is supported by the bootloader.[1]

OSTree:

EXT4, BTRFS, XFS for block devices.

No preferred filesystems for MTD devices.

Notes:

Mender shows less dependencies on certain filesystems.

OSTree claims that it supports MTD devices, but no specific implementation on a certain type of the filesystems on them.

Deploy Mechanism

RAUC:

Pull/push packages via the network (HTTPS) or locally from a media e.g. USB.

Supports streaming through built-in HTTPS or via casync, no intermedia storage is required.

Supports delta updates.

Mender:

Pull/push packages via the network (HTTPS) or locally from a media e.g. USB.

Distributed devices must connect to server through Mender Gateway [2]

Two modes are implemented.

managed mode: client is a daemon and will poll the server for updates

standalone mode: updates are triggered locally from physical media or pulling from network

Supports HTTPS streaming, no intermedia storage is required.

Layer meta-mender-commercial is required for delta updates, but it is in commercial plan. [2]

OSTree:

Pre-deploy process (migration from bare repository to archive repository) is required after the images or packages are generated by the build system: Commit the packages output from a build system into a bare repository, and then export content into the archive repository for use by the clients.

Update through pulling from a remote repository for a specific commit (“refs”) into the local OSTree repository via HTTPS if the commit does not exist locally or update a commit (“refs”) from the local OSTree repository.

Supports HTTPS streaming, no intermedia storage is required.

For delta updates, when performing a pull for a specific commit, just fetching each individual object that we do not have - only download changed files (gzip-compressed)

Notes:

Mender needs commercial plans (Mender Enterprise and/or Mender Professional) to support some advanced features like delta update and allowing distributed devices to connect with Mender update server.

OSTree supports delta update by its git-like nature.

Artifacts Management And Packaging

Artifact Format & Compression

RAUC:

The RAUC artifacts are managed in image-based “bundles” (filesystems+manifest), followed by a signature plus signer’s certificate (signature+certificate, in CMS[3] format).

Different bundle types are available: Clear, Verity or Crypt.

File system is a SquashFS image that supports mounting without unpacking.

Mender:

Mender uses a specific file format - Mender Artefact (*.mender), contains software images and metadata.

Mender Artefact is not compressed, but filesystem image and metadata inside are gzip-compressed.

OSTree:

OSTree artifacts are managed in git-like objects.

commit object: contains metadata of history of binary builds.

dirtree object: contains subdirectory metadata of a directory.

dirmeta object: contains metadata of a directory.

content object: header with uid, gid, mode, symlinks, extended attributes + the file content + hash (SHA256).

xattrs objects: for repository type bare-split-xattrs to carry xattrs in separate objects.

Content object is gzip-compresses. Metadata objects are stored uncompressed.

Notes:

Three solutions have their own proprietary formats for artifact management.

Mender/OSTree needs to unpack the gzip while RAUC can mount the SquashFS directly.

Signing/Verifying

RAUC:

The signer’s certificate (X.509 PEM) location is defined in the system conf file [4].

Before installation, verify the signer’s certificate against the linux keyring and then parse the public key to verify the bundle signature.

Signature algorithm can be RSA 4096 or ECDSA 256.

Mender:

The signer’s public key location is defined in the system conf file [4].

Before installation, Mender uses the public key to verify the signature of artifacts (No linux keyring is involved to verify the public key before that)

Signature algorithm can be RSA >3072 or ECDSA 256.

mender-artifact tool supports Google Cloud Key Management, to sign artifacts using keys in Cloud Key Management, allowing developers to sign artifacts without accessing the private signing key.

OSTree:

OSTree signs each of the commits using GPG.

Client verifies the signature of the commit before deploying it.

However, the provisioning of the public key is not considered by OSTree.

Notes:

RAUC verifies the public key against Linux keyring before using it to verify the signature.

Mender supports cloud key management.

OSTree is using GPG without PKI for signatures and the way to provision the public key is the integrator’s responsibility.

Integrity Checks

RAUC:

Type Verity bundles provide additional filesystem integrity checks leveraging dm-verity, a dm-verity hash tree over the SquashFS image and manifest is contained in CMS[3], integrity checks are applied via dm-verity.

Mender:

N/A.

Mender does not have built-in support for filesystem integrity checks.

OSTree:

Each OSTree content object has a checksum (SHA256) that includes the file content and metadata (uid, gid, mode and extended attributes).

An extension with IMA signatures and policies to provide additional integrity checks (not working with EVM due to its extended attributes causing object corruption).

Notes:

RAUC provides options for filesystem integrity checks based on dm-verity while Mender does not.

OSTree provides SHA256 checksum includes file content and metadata, plus IMA with additional file content integrity check and file content plus metadata signature check.

Encrypt/Decrypt

RAUC:

Type Crypt bundles provide bundle payload encrypt/decrypt leveraging dm-crypt to encrypt/decrypt bundle payload (symmetric key is a plain text in manifest, AES-256) while manifest is encrypted by recipient’s public key (RSA 4096, ECC 256).

Mender:

N/A

Mender does not have built-in support for encrypting artifacts.

OSTree:

N/A

OSTree does not have built-in support for encrypting repo/commit/package.

Notes:

RAUC provides options for file system encryption based on dm-crypt while Mender/OSTree does not.

Installation

RAUC:

Both system/application updates are applied according to slot definitions.

Slot is an abstraction to reflect a device, partition, volume or file by various slot types.

Slot grouping for deactivating/updating/reactive a group of slots, the operation within a slot group is atomic.

Slot configuration described in system config file [4].

RAUC handles a mapping between slot type and image type and looks for the pre-defined method to install the bundles.

Mender:

System update depends on combinations of OS and hardware platform which Mender supports (This is called a “Mender Board Integration”).

Mender officially supports the most common Linux OSes, and has reference implementations for specific devices [5].

Application update is extended per specific software package types (apps, packages, containers or proxy deployment for peripherals via e.g. USB-DFU) by Update Modules, which are independent scripts and can be customized and installed separately.

OSTree:

For system update, OSTree supports recording and deploying complete (bootable) filesystem trees

Atomic updates are guaranteed by atomically swapping a /boot symlink to a new deployment /ostree/boot.foo directory.

For application update, installing a package, rather than changing the currently running filesystem, it is possible to use OSTree underneath a package system, the package manager could assemble a new filesystem tree that layers the new packages on top of a base tree, record it in the local OSTree repository, and then set it up for the next boot.

rpm-ostree is an example project for a package system that works with OSTree.

Notes:

For a system update, Mender provides reference support for most of the popular OSes and hardwares and is easy to start with. However, it looks that RAUC is more flexible by introducing the abstraction of “slot”. OSTree has a fast and efficient update mechanism, due to its unique design of using atomic commits and hard links. This allows OSTree to perform updates quickly by only updating the necessary files, rather than copying an entire new image to the device.

For an application update, Mender is more flexible with the Update Modules that like an add-on for creating a new or extending an existing package type, while RAUS only supports installation method pre-defined for each combination of slot types and image types. OSTree provides a similar principle as Mender does, however it needs an integration with a specific package system to support it.

Bootloader Integration

RAUC:

RAUC provides different interfaces to access the boot configuration and environment variables.

Scripts for U-boot and GRUB, or boot chooser framework for Barebox

Mender:

Mender is built-in supported by GRUB, no patch is needed.

For U-boot, Mender provides special integration points for U-boot to hook into so that Mender can be a part of the normal boot process.

OSTree:

OSTree provides both commands and APIs to manage the bootloader configuration files and environment variables.

Notes:

Less integration work with GRUB and U-boot is required for Mender than RAUC.

OSTree has less dependencies on specific bootloaders.

Update Rollback

RAUC:

Rollback from a full backup in the inactive slot is supported (Symmetric A/B scheme only).

Mender:

Rollback from a full backup in the inactive slot is supported.

OSTree:

When OSTree performs an update, it creates a new hard link for the new version it downloaded. The hard link points to the actual data of the new version, but gives it a new name in the file system. This way, the new version is treated as a separate entity. When OSTree needs to perform a rollback, it simply updates the boot configuration to point to the previous version of the operating system. This is achieved by changing the hard link to point to the desired snapshot. Because the data is shared between hard links, the rollback is done in a matter of milliseconds, and the system immediately boots into the previous version.

Notes:

There is no significant difference between RAUC and Mender in terms of a rollback from the inactive slot under the Symmetric A/B scheme.

System snapshots implemented by hard links allows OSTree to perform rollbacks in a fast and efficient manner with minimal overhead and risk of data loss.

Backend Update System Compatibility

RAUC:

RAUC supports both Eclipse hawkBit / AWS with integration with relevant connect clients.

rauc-hawkbit client for hawkBit.

Upparat client for AWS IoT jobs.

Both are separate projects, Python-based apps and libraries.

D-Bus is used between RAUC and the integrated connect client.

Mender:

Mender is tied to Mender update server (built-in support with features like Device Group, Phased rollout deployment, RBAC, Device Authentication [2])

Connect client “Mender Connect” is ready for use with Mender update service.

D-Bus is used between Mender Client and Mender Connect.

OSTree:

OSTree has a reference design for Uptane.

aktualizr: C++ implementation of Uptane OTA update client.

HERE OTA Connect: Uptane-compatible OTA server.

Notes:

Mender has its own connect client which is ready for and firmly tied to Mender update service. The web-interface of Mender update service which controls the backend update server is well-designed and easy to use. Setting it up is done via Docker, which makes initial set-up straightforward. But some of the advanced features require a Mender Enterprise or Mender Professional plan which means “not free”.

RAUC can support both hawkBit or AWS and needs integration with external connect client projects (rauc-hawkbit or Upparat).

Similarly, OSTree needs integration with external clients to access a specific backend service. aktualizr with HERE OTA Connect can be a reference.

For a demo with a backend service, Mender is ready-to-go, while RAUC/OSTree needs an integration.

Developer API & Command-Line Tool

RAUC:

For device-side, D-Bus interface is available.

RAUC has no server-side API.

The command-line tool “rauc” is to generate/sign/verify/install/fallback for both device-side and server-side.

Mender:

For device-side, D-Bus interface for Mender client. Good documents for API sets and example applications are available.

For server-side, Mender provides REST API for Mender server. The command-line tool “mender-artifact” is to view, create, modify, sign and verify artifacts for both device-side and server-side.

OSTree:

For device-side, D-Bus interface for updates, rollbacks, and repository management.

Server-side APIs for a set of functions that can be used to implement an OSTree repository server.

The command-line tool “ostree” is for updates, rollbacks, and repository management.

Notes:

Mender has APIs for both device-side and server-side with the best API reference guide.

RAUC has no API for server-side.

OSTree’s server-side APIs are for repository management only, not for general OTA management.

Cryptographic API

RAUC:

OpenSSL, PKCS#11.

Mender:

OpenSSL, PKCS#11.

OSTree:

GPG, OpenSSL.

Notes:

OSTree is using GPG for commit signature instead of PKI.

CI/CD Pipeline For Deployment

RAUC:

N/A

Mender:

Ready for GitHub Actions, GitLab CI/CD, Azure DevOps.

OSTree:

OSTree defines a model that allows to have different branches in a “dev” repository to indicate different development stages and support promoting commits from one to another through the CI/CD pipeline and finally promotes to the “prod” repository for deployment.

However, this is just a concept of model (with some supporting scripts) but integration with a CI/CD tool is required.

Notes:

Mender is ready for demo on deploying via CI/CD pipeline, OSTree provides a prototype while RAUC has nothing for it.

Footprints

RAUC:

The main binary is only approx. 512K.

Mender:

The main binary is about 6M.

OSTree:

Main library is less than 1M.

Notes:

All three systems are designed to be efficient and lightweight but RAUC looks to have the smaller size. [6]

For OSTree, the size of the repository is more critical due to it may contain multiple trees.

Documentation & Guidelines

RAUC:

Usage guide, examples, scenarios and integration guide for Yocto, PTXdist and buildroot.

An example for local update (Symmetric A/B) is ready for testing with QEMU (with GRUB).

Mender:

Easy to get started with as there is good, clear and step-by-step documentation on how to set up and integrate.

Provides reference implementations and demos on Raspberry Pi (3 Model B/B+, 4 Model B), BeagleBone Black and QEMU.

Examples for deploying application/system/container update via web-interface are ready for testing with QEMU.

OSTree:

Official website provides the concepts on how OSTree works and prototypes on how to integrate with a build system and how to manage the repositories, as well as an API reference and manual.

Notes:

Mender has the best documentation among the three and is easy to start with an end-to-end OTA demo, while RAUC only provides some certain examples to show a local update.

OSTree website tends to provide ideas, prototypes on integrations with a steep learning curve, not user-friendly for beginners.

Customization

RAUC:

Part of runtime behaviors of device-side clients can be configured via parameters of the system config file [4].

Handles (scripts) for pre-install or post-install can be defined in the system config file [4].

Hooks (scripts) can be defined in a bundle’s manifest to add/replace some functionalities during installation for a specific bundle.

Lack of documents for customization.

Mender:

Built-in customerization options are available through classes for both update image features and Mender Client behaviors with good documentation.

Supporting customized State Scripts (root file system script or artifact script) which are able to be executed during transition of states (e.g. Idle, Sync, Download, ArtifactInstall, ArtifactReboot, ArtifactCommit, ArtifactRollback, ArtifactRollbackReboot, ArtifactFailure).

OSTree:

OSTree is not a full update client, instead a library focused on git-like repository management.

It is fully flexible for customization with an update client (e.g. aktualizr).

Notes:

Mender has more flexibility with options/classes for both update image and client behaviors.

State Scripts are more general and useful than pre/post-install scripts that RAUC is using because they can be run between any state transition, not just (before/after) the install state.

OSTree normally works with an external update client, itself doesn’t provide more functionalities than repository management. It is fully customized from this perspective.

Version Compatibility

RAUC:

Compatibility to old versions is limited to “a reasonable level”, but no clear document on it.

Mender:

The compatibility between different versions of below components is well documented:

Mender client and Yocto Project version

Mender client/server and Artifact format

Mender server and client API

Mender client and Mender connect

OSTree:

OSTree supports backward compatibility for older versions, but it is the responsibility of the developer to ensure any deprecated features or changes in behavior via the release notes.

Notes:

Mender has a clear picture on the compatibility between different versions while RAUC/OSTree does not.

Summary

This section summarizes the factors we discussed in the previous comparison.

Below is a table for a quick review of the differences between RAUC, Mender and OSTree.

Table Of Comparison For Review

Factors	RAUC	Mender	OSTree	Notes
Programming Language	C	Go	C	Go is not common for embedded systems
License	MIT	Apache 2.0	GNU LGPLv2+	-
OpenEmbedded Layer	meta-rauc	meta-mender	meta-updater	-
Footprints	Main binary is only approx. 512K	Main binary is about 6M	Main library is less than 1M	RAUC has a smaller size. [6]
Device Layout Scheme	Symmetric A/B or Asymmetric A/Recovery	Symmetric A/B only	Git-like object repository to record and deploy complete file system trees	RAUC is more flexible than Mender OSTree is the most flexible one
Filesystem Types	block devices: EXT4 MTD devices: UBIFS, UBIMG	No dependencies on a specific filesystem type, but depends on whether it is supported by the bootloader [1]	block devices: EXT4, BTRFS, XFS MTD devices: supported but no implementation for a specified filesystem	Mender: less dependencies to certain filesystems than RAUC and OSTree
Deploy Mechanism	Pre-Deploy Process	N/A	N/A	Bare repository to archive repository migration is required	Mender needs commercial plans[2] to support some of the advanced features: delta update, gateway for distributed devices OStree needs a migration from bare to archive repository before the packages are ready for clients OSTree supports delta update naturally by its git-like repository
	Packages Fetching	Remote update: pull/push via HTTPS Local update: from local media e.g. USB	Remote update: pull/push via HTTPS Distributed devices require Mender Gateway [2] to connect to the server Local update: from local media e.g. USB	Remote update: pull from a remote repository for a specific commit Local update: a commit from the local repository
	Streaming	YES	YES	YES
	Delta Update	YES	Commercial plan is required [2]	YES
Artifacts Management and Packaging	Artifact Format	bundles (filesystem+manifest), followed by a signature plus signer's certificate (in CMS[4] format). bundle types: Clear, Verity or Crypt	Mender Artifact (*.mender): software image+metadata	Git-like objects: metadata objects (commit objects, dirtree objects, dirmeta objects and xattrs objects) and content objects	-
	Compression	SquashFS image that supports mounting without unpacking	Artifact is not compressed, but filesystem image and metadata inside are gzip-compressed	Content objects are gzip-compressed. Metadata objects are uncompressed.	Mender/OSTree needs to unpack the gzip while RAUC can mount the SquashFS directly.
	Signing/ Verifying	Signer's certificate (X.509 PEM) is defined in the system conf file [4]. Verify the signer's certificate against the linux keyring and then parse the public key to verify the bundle signature. Signature algorithm: RSA 4096 or ECDSA 256	Signer's public key is defined in the system conf file [4]. Use the public key to verify the signature of artifacts. Signature algorithm: RSA >3072 or ECDSA 256. Supports Google Cloud Key Management	Sign each of the commits using GPG. Verifies the signature before deploying it. The provisioning of the public key requires integration	RAUC verifies the public key against Linux keyring before using it to verify the signature while Mender has the support for cloud key management OSTree is using GPG for signature without PKI but provision of the public key is the integrator's responsibility
	Integrity Checks	For type Verity, additional integrity check can be applied via dm-verity	N/A	Each content object has a checksum (SHA256) that includes the file content and metadata (uid, gid, mode and extended attributes). An extension with IMA signatures and policies to provide additional integrity checks	RAUC provides options for filesystem encryption and integrity checks based on dm-crypt and dm-verity while Mender does not. OSTree provides SHA256 checksum includes file content and metadata, plus IMA with additional file content integrity check and file content+metadata signature check, but without consideration on encryption
	Encrypt/ Decrypt	For type Crypt, use dm-crypt to encrypt/decrypt bundle payload (symmetric key is a plain text in manifest, AES-256) Manifest is encrypted by recipient's public key (RSA 4096, ECC 256)	N/A	N/A OSTree does not have built-in support for encrypting repo/commit/package
Installation	System Update	Slot is an abstraction to reflect a device, partition, volume or file Slot grouping for deactivating/updating/reactive a group of slots, the operation within a slot group is atomic Slot configuration described in system config file [4]. RAUC handles a mapping between slot type and image type with predefined methods for installation the bundles	Supports based on combinations of OS and hardware platforms. Mender officially supports the most common Linux OSes, and has reference implementations for specific devices [5]	Supports recording and deploying complete (bootable) filesystem trees Atomic updates are guaranteed by hard links	Mender: reference support for most of the popular OSes and hardwares and is easy to start with RAUC: is more flexible by introducing the abstraction of "slot" OSTree: has a fast and efficient update mechanism, due to its unique design of using atomic commits and hard links
	Application Update		Extended per specific software package types by Update Modules, can be customized and installed separately	Need to integrate with a package system. rpm-ostree is an example project	Mender: more flexible with the Update Modules RAUS: only supports the installation method pre-defined OSTree: similar principle as Mender, however integration with a package system is required
Bootloader Integration	U-boot: script GRUB: script Barebox: boot chooser framework	GRUB: built-in supported by GRUB, no patch is needed U-boot: Hooks	Commands and APIs to manage the bootloader configuration files and environment variables	Less integration work with GRUB and U-boot is required for Mender than RAUC OSTree has less dependencies on specific bootloaders
Update Rollback	YES for Symmetric A/B	YES	YES. Quick and atomic rockback	System snapshots implemented by hard links allows OSTree to perform rollbacks in a fast and efficient manner with minimal overhead and risk of data loss
Backend Update System Compatibility	rauc-hawkbit client for hawkBit Upparat client for AWS IoT jobs Both are separate projects ( Python apps and libraries) D-Bus between RAUC and connect client	Tied to Mender Update server with features like Device Group, Phased Rollout Deployment, RBAC, Device Authentication [2] Mender Connect client is ready for Mender Update Service. D-Bus between Mender Client and Mender Connect	Reference design for Uptane: aktualizr: C++ implementation of Uptane OTA update client HERE OTA Connect: Uptane-compatible OTA server	For a demo with a backend service, Mender is ready-to-go, while RAUC/OSTree needs an integration with a specific connect client.
Developer API	Device-Side	D-Bus APIs	D-Bus APIs	D-Bus APIs	Mender: APIs for both device-side and server-side with the best API reference guide RAUC: no reference implementation on server-side OSTree: server-side APIs are for repository management only, not for general OTA management
	Server-Side	N/A	REST API for Mender server	Functions that can be used to implement an OSTree repository server
Cryptographic API	OpenSSL, PKCS#11	OpenSSL, PKCS#11	GPG, OpenSSL	OSTree is not using PKI
Command-Line Tool Availability	YES	YES	YES	-
CI/CD Pipeline Support For Deployment	N/A	Ready for GitHub Actions, GitLab CI/CD, Azure DevOps	A prototype (with some supporting scripts) to promote commits from “dev” to “prod” through CI/CD pipeline	Mender is ready for demo on deploying via CI/CD pipeline while OSTree just provides a prototype for it
Documentation	Usage guide, examples and integration guide for Yocto, PTXdist and buildroot Example for local update (Symmetric A/B) is ready for testing with QEMU (with GRUB)	Good, clear and step-by-step documentation Implementations and demos on Raspberry Pi, BeagleBone Black and QEMU Examples for deploying updates via web-interface are ready for testing with QEMU	Concepts and prototypes on how to integrate with a build system and how to manage the repositories API reference and manual	Mender: with the best documentation and is easy to start with an E2E OTA demo with backend RAUC: only provides some certain examples to show a local update OSTree: tends to provide ideas, prototypes on integration but with a steep learning curve, not user-friendly for beginners
Version Compatibility	Compatibility to old versions is limited to "a reasonable level"	The compatibility between different versions is well documented	Supports backward compatibility for older versions, but it is the responsibility of the developer to compare release notes	Mender has a clear picture on the compatibility between different versions while RAUC/OSTree does not
Customization	Part of runtime behaviors of device-side clients can be configured via parameters of the system config file [4] Handles (scripts) for pre-install or post-install can be defined in the system config file [4] Hooks (scripts) can be defined in a bundle's manifest	Built-in customerization options are available through classes for both update image and Mender Client behaviors Support customized State Scripts (root file system script or artifact script) which are able to be executed during transition of states.	OSTree is not a full update client, instead a library focused on git-like repository management It is fully flexible for customization with an update client (e.g. aktualizr).	Mender has more flexibility with options/classes for both update image and client behaviors, State Scripts are more general and useful than pre/post-install scripts that RAUC is using OSTree normally works with an external update client, itself doesn't provide more functionalities than repository management

Summary Of Major Pros & Cons

Mender

Advantages:

Ready for connecting with OTA backend service with an easy-to-use web-interface, ready for an end-to-end OTA demo with image management, update monitoring and deployment via CI/CD pipeline.
Less dependencies to certain filesystems than RAUC and OSTree.
Reference implementation with most of the popular OSes and hardwares, good documentation and is easy to start with.
APIs for both device-side and server-side with clear API reference guide.
Easy for customization with options and classes for adjusting both update image and client behaviors; State Scripts are more general and useful than pre/post-install scripts which RAUC is using; Update Modules provide more flexibility to extend installation methods of different package types for application updates.
Supports Google Cloud Key Management, allowing developers to sign artifacts without accessing the private signing key.

Disadvantages:

Firmly tied to Mender Update Service and advanced features (e.g. delta update, gateway for connection of distributed devices) may require purchasing a commercial plan.
Layout scheme supports “Symmetric A/B” only.
No consideration on filesystem encryption and integrity checks.
Mainly written in Go which is not common for embedded systems.

RAUC

Advantages:

Flexible with different bundle types for different business requirements.
Relatively small binary size compared with Mender and OSTree.
Supports both “Symmetric A/B” and “Asymmetric A/Recovery” layout schemes.
Verifies the public key against Linux keyring before using it to verify the signature.
Provides options for filesystem encryption and integrity checks based on dm-crypt and dm-verity.
Easy for customization. Part of runtime behaviors of device-side clients can be configured. Hooks for pre/post-install or specific bundles can be defined.

Disadvantages:

Only supports pre-defined installation methods. Difficult to create a new installation method for a new package type or extend an existing one.
Needs to integrate with a specific connect client to work with an OTA backend service (e.g. rauc-hawkbit for hawkBit, Upparat for AWS).
No reference implementation on server-side.
Less customization flexibility compared with Mender.

OSTree

Advantages:

Git-like object store allows to record and deploy multiple file system trees using binary deltas. It is designed to parallel-install multiple versions of multiple independent operating systems.
Each deployment is primarily composed of a set of hard links into the repository. This means each version is deduplicated; an upgrade process only costs disk space proportional to the new files, plus some constant overhead.
Quick and efficient update and rollback mechanism via system snapshots implemented by hard links allows OSTree to perform atomic updates/rollbacks in a fast and efficient manner with minimal overhead and risk of data loss.
SHA256 checksum includes file content and metadata, plus IMA with additional file content integrity check and file content plus metadata signature check.
Adopted by Uptane (Securing Software Updates for Automobiles) framework. A reference design for Uptane is available with aktualizr and HERE OTA Connect.

Disadvantages:

Steep learning curve, not user-friendly for beginners.
Not a full functioning update client, instead, a library focused on git-like repository management without additionally OTA management functions.
Needs to integrate with a specific connect client to work with an OTA backend service (e.g. aktualizr for HERE OTA Connect).
Needs to integrate with a package system (e.g. rpm-ostree).
No consideration on filesystem encryption.
Uses GPG for signature without PKI but provision of the public key is the integrator’s responsibility.
Server-side APIs are for repository management only, not for general OTA management.

Conclusion

In conclusion, RAUC, Mender, and OSTree are all software update solutions that are widely used in the embedded systems world. They all have their own strengths and weaknesses and the choice of which one to use depends on the specific requirements of a project. If ease to start with and a full functioning end-to-end OTA update management are required, Mender may be a good choice. If quick atomic upgrades/rollbacks and reliable version management are required, OSTree may be more suitable. If a trade-off between flexibility and integration effort is considered, RAUC may be a good selection.

References

U-Boot only supports UBI for raw flash.
Mender Gateway, RBAC is available for Mender Enterprise plan only; Delta update is available for Mender Enterprise or Mender Professional plan only.
Cryptographic Message Syntax.
RAUC system config file is /etc/rauc/system.conf; Mender system config file is etc/mender/mender.conf.
OS: Debian, Ubuntu and Raspberry Pi OS; Boards: Raspberry Pi 3 Model B and B+, Raspberry Pi 4 Model B, Nvidia Jetson L4T, QEMU x86_64+GRUB.
These are rough calculations based on output from Yocto, and do not take into account dependencies, different build targets, etc.