Getting software onto an IoT device is the easy part. Keeping it updated safely across a fleet of thousands of devices spread across factories, substations, or remote sites — that’s where things get hard fast.

Over-the-air (OTA) updates for embedded Linux have a grim history. Custom update scripts that work fine in testing and brick devices in production. Update processes that leave devices in inconsistent states when the connection drops halfway through. No rollback mechanism, so a bad update that slips through testing results in a field trip to every affected device. These problems have cost companies a lot of time and money.

Mender.io exists specifically to fix this. It’s an open-source OTA update system for embedded Linux that handles the hard parts correctly — atomic updates with automatic rollback, cryptographically signed artifacts, and a management server that gives you control over rollout scheduling and monitoring.

How Mender Works

The core of Mender’s reliability is its A/B (dual-partition) update approach. Instead of updating the live root filesystem in place — which is risky, because the device becomes unbootable if anything goes wrong mid-update — Mender maintains two complete root filesystem partitions.

┌──────────────────────────────────────┐
│         Storage Layout               │
│  ┌───────────┐ ┌───────────────────┐ │
│  │  Bootloader│ │  Data partition   │ │
│  └───────────┘ └───────────────────┘ │
│  ┌────────────────────────────────┐  │
│  │ Rootfs A (active)             │  │
│  └────────────────────────────────┘  │
│  ┌────────────────────────────────┐  │
│  │ Rootfs B (inactive/next)      │  │
│  └────────────────────────────────┘  │
└──────────────────────────────────────┘

When an update arrives, Mender writes the new rootfs image to the inactive partition while the device keeps running on the active one. Once the write is complete and verified, the bootloader is instructed to switch to the updated partition on next boot. The device reboots, comes up on the new partition, runs the application, and — if everything looks good — commits the update. If the application fails to start, or if a watchdog timer fires because the device hasn’t reported in, the bootloader rolls back to the previous partition automatically.

The device never ends up in a partial state. Either the update succeeded and is committed, or the device has rolled back to what it was running before. This atomicity is what makes Mender suitable for unattended devices where you can’t send someone to fix a bricked unit.

Integration with Yocto

Mender integrates with the Yocto Project, which is the standard build system for custom embedded Linux distributions. If you’re using Yocto to build your device firmware, adding Mender is a matter of including the meta-mender layer in your build configuration:

# In your Yocto build directory
git clone https://github.com/mendersoftware/meta-mender layers/meta-mender

In your bblayers.conf:

BBLAYERS += " \
  ${TOPDIR}/../layers/meta-mender/meta-mender-core \
"

In your local.conf or distro config:

INHERIT += "mender-full"
MENDER_ARTIFACT_NAME = "release-1.0"
MENDER_SERVER_URL = "https://hosted.mender.io"

This configures the build to produce rootfs images in Mender’s artifact format, sets up the A/B partition layout, and includes the Mender client daemon that handles update checking and application. The resulting image already has OTA update capability baked in from the first boot.

The Mender Server

The Mender server — available as a hosted service (Mender Hosted) or self-hosted via Docker Compose — is where you manage deployments across your fleet. You upload a Mender artifact (.mender file), create a deployment targeting a device group, and the server delivers and tracks the update.

# Upload an artifact
mender-cli artifacts upload \
  --server https://hosted.mender.io \
  --token $MENDER_TOKEN \
  release-2.0.mender

# Create a deployment
mender-cli deployments create \
  --artifact-name release-2.0 \
  --device-group production-devices \
  --retries 3

The dashboard shows each device’s status: downloading, installing, rebooted, success, or failure. If a device fails (returns an error code from the application health check, or stops reporting), it’s marked as such and rolled back. You can see at a glance that 847 devices updated successfully, 12 are rolling back, and 3 haven’t been online to receive the update yet.

Phased rollouts let you update a percentage of devices first, monitor for issues, and proceed with the rest only if the initial wave looks healthy. This is standard practice for large fleets where a bad update could affect operations.

Signed Artifacts

Mender artifacts can be signed with asymmetric keys. The Mender client on each device has the public key baked in at build time; it will only install artifacts signed with the corresponding private key. This prevents a compromised update server — or a man-in-the-middle interception — from pushing malicious firmware to your devices.

# Sign an artifact with your private key
mender-artifact sign \
  --key /path/to/private.key \
  release-2.0.mender \
  --output release-2.0-signed.mender

For industrial IoT devices or anything in a regulated sector, the ability to cryptographically prove the provenance of firmware updates is increasingly important — and Mender makes it straightforward to implement.

Mender vs Balena vs SWUpdate

If you’re evaluating options, the comparison worth making is between Mender, balena, and SWUpdate.

balena is a full device management platform that includes OS, containerised application deployment, and OTA. It’s opinionated — you run balenaOS and deploy Docker containers. If that model fits your architecture, balena is very capable. If you have an existing embedded Linux build system you don’t want to change, or you’re not running containerised applications, Mender fits better.

SWUpdate is another open-source update framework, originally developed for Siemens. It’s more flexible in terms of update mechanisms but has a steeper learning curve and a less polished management server (though it integrates with Eclipse hawkBit for device management). For projects already in the Siemens/Yocto ecosystem, SWUpdate is worth evaluating. Mender’s integration story and hosted server are generally smoother for teams starting fresh.

For embedded Linux devices where you want reliable OTA updates with rollback and you’re not starting from balenaOS, Mender is the strongest open-source option available. The Yocto integration in particular makes it practical to add to an existing build system without a major rearchitecture.