# Mender, an over-the-air updater built around a dual A/B root filesystem

> Mender is an open source OTA update manager for IoT and embedded Linux devices, and this repository is its client. The design decision that everything else follows from is the A/B root filesystem partition layout, which makes an update atomic and makes a power cut survivable. The server side is a set of microservices that live in other repositories.

**mendersoftware/mender** — Mender over-the-air software updater client.

- Repository: https://github.com/mendersoftware/mender
- Website: https://mender.io
- Stars: 1,239 · Forks: 239
- Language: C++
- License: NOASSERTION
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/mendersoftware-mender

## A client that ships on the device

Mender is an open source over-the-air update manager for IoT and embedded Linux devices, and the client-server architecture is what makes it a fleet tool rather than a script. The client runs on the device, the back end and the user interface manage deployments centrally, and between them they cover the things a product team needs after shipping. Those include dynamic grouping, phased deployments so that an update reaches a slice of the fleet before the whole fleet, and delta updates so a small change does not mean a full image download. The README also points at the extension side, the ability to configure, monitor and troubleshoot devices, with remote terminal access, port forwarding and file transfer among the features. It integrates with Azure IoT Hub and AWS IoT core, which matters if a device already has one of those in its data path. The audience is an embedded product team with devices in the field, and the primary language of this repository is C++.

## The A/B partition layout is the design, not a feature

The mission section explains why the project exists, and the reasoning is more useful than the feature list. Embedded product teams often create homegrown updaters at the last minute because they need to fix bugs on devices that are already deployed, and the essential requirement for such an updater is that it survives reality. The example given is blunt, that a loss of power at any time should not brick a device, and that is a hard requirement to meet with a homegrown script. Mender's answer is that robustness is ensured with atomic image-based deployments using a dual A/B rootfs partition layout, so it is always possible to roll back to a working state even if power is lost during the update. Automatic rollback upon update failure follows from the same mechanism, and the update types covered are a full root file system, application, files, and containerized updates. Everything else in the client, including the state scripts in the examples directory, exists to make that scheme work on real hardware.

## Rollback needs a bootloader and a partition layout

There is a dependency in the documentation that is easy to miss and expensive to discover late. For rollback functionality, the Mender client requires an integration with the boot loader and a partition layout, and the support for it is most easily built as part of your Yocto Project image by using the meta layer for the Yocto Project. In other words, the safety property is not a setting in the client, it is a property of the image you build. If your bootloader does not support selecting between two root filesystems, or your partition layout has no room for a second rootfs, then the atomic deployment story does not apply to you as written, and you have to solve that first. This is the single most important compatibility question for anyone evaluating the project, and it is also the reason the Yocto integration is the recommended starting point rather than an optional extra. For teams that already build images with Yocto, the meta layer is a short path. For everyone else, it is an image engineering project before it is an updater project.

## Standalone mode for devices with no server

This repository contains the Mender client updater, and it can be run in two modes. In standalone mode the client is triggered manually through its command line interface, and the README describes this as standalone deployment support triggered at the device level, with no server needed, aimed at unconnected or USB delivered software updates. In managed mode the same client is connected to the Mender server and participates in central deployment management. The standalone path is the one that gets overlooked, and it is the more interesting engineering, because a device that has never been on a network still needs to receive an image, verify it and switch partitions, and the client has to do that without the server's help. It is also the mode a security researcher or a field engineer would use to reproduce a problem on a single unit without provisioning fleet infrastructure.

## The server is microservices behind a gateway

The architecture diagram in the README is described in enough detail to be useful. The back end and the user interface together are the Mender product, and all communication between devices, users and the back end goes through an API gateway, with Traefik used for the gateway, which routes requests from the clients to the right micro-service. Some micro-services use NATS as a message broker to support device update troubleshooting and the orchestration inside the system. MongoDB is the persistent database for the back end micro-services, the storage layer for artefacts is an AWS S3 bucket, or an S3 API-compatible store, or an Azure Storage Account, in both the hosted and the on-premise versions, and Redis is the in-memory cache that allows device management at scale. The server is designed as a microservices architecture and spans several repositories, so this repository is the device side of a system rather than the system itself.

## Open source and hosted, with a visible feature difference

The README puts the two editions side by side in a table, and the differences are about operations rather than about the updater itself. The commercial version lets you connect devices to a hosted, enterprise grade, multi-region backend, and adds advanced fleet management, top-tier security, regulatory compliance features, role-based access control, dynamic groups, delta updates and mutual TLS support, and it is free for twelve months up to ten devices. The open source version lets you start updating devices yourself, in a quick, secure and robust method, and the documentation points at the getting started material. The complete comparison is on the product features page. The practical reading for an evaluator is that the client is the same in both cases, so the decision is about who runs the fleet service, and the open source route means you also run the gateway, the broker, the database, the artefact store and the cache.

## Building the client, and the licensing picture

The repository is a CMake project with the usual embedded layout, with a CMakeLists.txt, a main.cmake, a cmake/ directory, the sources in src/, the test suite in tests/, support/ for packaging material, and an examples/ directory with a demo configuration, a production configuration and state-scripts/. The build badge points at a GitLab pipeline, so the continuous integration lives on GitLab while the mirror and the coverage reporting live on GitHub, and renovate.json5 handles dependency updates. The licence situation needs attention. The repository carries a LICENSE file that GitHub could not classify, and there is a LIC_FILES_CHKSUM.sha256 file, which is the convention for projects that ship several third-party licence texts and need to detect when one of them changes. The release history has two recent tags, 5.1.0 on 2026-05-12 and a QNX preview v1 on 2026-06-09, which is a useful signal about where the platform support is heading, and the last push was on 2026-10-18. Anyone shipping this in a product should read the licence file rather than the badge.

## Conclusion

Mender fits a team shipping field devices that need security fixes and feature updates after the product ships, and it fits an organisation that already builds its image with Yocto, since the meta layer is the shortest route to the partition layout and bootloader integration the client expects. It does not fit a maker with a handful of devices, since the server side is a microservices system with a database, a broker and an object store, and it does not fit a project that cannot change the partition layout of the image, because the A/B scheme is a prerequisite for the rollback behaviour rather than an optional extra. Verify three things first: that your bootloader and image can be adapted to the dual rootfs layout, whether you want the open source server or the hosted one, since the feature sets differ, and that your devices can reach the API gateway, since all client traffic goes through it.

## FAQ

### What is Mender?

Mender is an open source over-the-air update manager for IoT and embedded Linux devices, with a client-server architecture for managing software deployments. It supports dynamic grouping, phased deployments, delta updates, and extensions for configuring, monitoring and troubleshooting devices.

### What does the Mender client need for rollback to work?

The client requires an integration with the boot loader and a partition layout, and the documentation says support for rollback is most easily built as part of a Yocto Project image using the meta-mender meta layer. The A/B rootfs layout is what makes the atomic deployment and automatic rollback possible.

### Can Mender update a device with no server?

Yes. This repository contains the client updater, which can run in standalone mode, triggered manually through its command line interface, for unconnected or USB delivered software updates, or in managed mode when connected to the Mender server.

### What are the differences between the open source and commercial Mender?

The open source version lets you run the update service yourself, while the commercial version offers a hosted, multi-region backend with advanced fleet management, role-based access control, dynamic groups, delta updates, mutual TLS and regulatory compliance features, free for twelve months up to ten devices.

## Sources

- [Issues](https://github.com/mendersoftware/mender/issues)
- [mendersoftware/mender on GitHub](https://github.com/mendersoftware/mender)
- [Project website](https://mender.io)
- [README](https://github.com/mendersoftware/mender/blob/master/README.md)
- [Releases](https://github.com/mendersoftware/mender/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/mendersoftware-mender