RAUC vs Mender: which should I use for embedded Linux OTA?

RAUC and Mender overlap, but they are not simply interchangeable versions of the same product.

A useful first distinction is:

RAUC is primarily an update mechanism you integrate into the device and your surrounding infrastructure. Mender provides an end-to-end OTA system with a device client and central deployment service.

If you already have RAUC integrated and qualified on your hardware, replacing it solely because you now need fleet management may be unnecessary.

If you are choosing an OTA architecture from scratch and want the same product to supply both device-side update technology and the server-side deployment system, Mender deserves serious consideration.

What RAUC gives you

RAUC is designed as a lightweight update framework for embedded Linux. It handles signed bundles, compatibility checks, redundant slot configurations, boot-success state, and integration with common bootloaders.

It deliberately does not try to be the fleet deployment server. That makes RAUC attractive when you want to own the system-image and recovery design while choosing the surrounding fleet infrastructure separately.

It also fits naturally into embedded Linux build systems such as Yocto, where the updater becomes part of the product image and boot architecture.

The trade-off is that once you have hundreds or thousands of devices, you still need something to decide which bundle goes to which device, stage the rollout, preserve historical outcomes, and operate the installed fleet.

What Mender gives you

Mender approaches the problem as an OTA platform.

Devices run the Mender client, which communicates with Mender's server-side deployment system, reports state, discovers deployments, and applies updates. Mender supports application updates as well as robust system updates, including A/B root-filesystem designs where the product is integrated appropriately.

If your central requirement is:

Give us a mature embedded Linux OTA system in which the device client and deployment service are designed together.

Mender is a strong fit.

The architectural difference

Decision	RAUC	Mender
Device-side robust update mechanism	Yes	Yes
Signed update artefact	RAUC bundle	Mender Artifact
A/B OS update support	Yes, integrated with your slot / boot design	Yes, with required board/system integration
Deployment server included	No, deliberately external	Yes
Fleet rollout model	Supplied by another system	Part of Mender
Existing qualified RAUC product	Keep the existing updater and add fleet infrastructure	Migration decision required
Updater + server as one OTA stack	Requires integration	Natural fit

Neither column is inherently better. They represent different ownership boundaries.

If you already use RAUC

This is the case most likely to be misdiagnosed.

Suppose your product already has:

• a qualified A/B partition layout;
• bootloader rollback;
• RAUC integrated into the image;
• signed production bundles;
• manufacturing and recovery procedures built around that architecture.

You then reach 500 or 5,000 devices and discover that manually publishing bundles is not a fleet-management strategy.

That does not necessarily mean the updater is wrong.

You may simply be missing the server-side layer RAUC intentionally leaves outside its scope.

Retaining the proven RAUC implementation and adding fleet orchestration can be much less disruptive than replacing the update architecture across an installed product.

If you are starting from scratch

The calculation is different.

Do not select an updater from a feature checklist alone. Ask:

• How much of the device image, bootloader, and recovery architecture do we want to own?
• Do we want one vendor/product to supply the updater and deployment server?
• Do we need application updates as well as complete system images?
• Are devices frequently offline or bandwidth constrained?
• How much staged-rollout control do we need?
• What evidence do we require after an update?
• What else must we operate on these devices besides OTA?

Mender may be the simpler answer when the purchasing problem is specifically a mature end-to-end OTA system.

RAUC can be the better component when you want to own the embedded Linux update/recovery architecture and integrate it with a wider fleet platform.

Where Dataplicity changes the RAUC equation

Dataplicity supplies the fleet layer while retaining RAUC on the device.

The responsibility split is:

your image build
    ↓
signed RAUC bundle
    ↓
Dataplicity targeting and staged rollout
    ↓
RAUC installation + boot behaviour
    ↓
product validation
    ↓
RAUC mark-good / rollback
    ↓
Dataplicity fleet outcome + release health

Dataplicity does not replace RAUC's transactional update safety. RAUC remains authoritative for the device's slot and rollback behaviour.

Dataplicity owns the surrounding operational problem: image catalogue and pins, targeting, rollout cohorts, durable success / rollback / validation / unknown outcomes, fleet comparison, and the connection to broader device operations and reliability evidence.

That is particularly relevant when OTA is only one part of the post-shipment problem.

If the same team also needs remote support, device diagnostics, application/container releases, logs, fleet drift/reliability, customer-facing product applications, and enterprise governance, evaluating OTA in isolation can create a fragmented operating stack.

Conversely, if OTA is genuinely the only platform problem you need to solve, a specialist OTA platform such as Mender may be entirely appropriate.

Practical decision

Choose RAUC plus a fleet layer when you already have or want a RAUC-based device architecture and need deployment and fleet operations around it.

Choose Mender when you want a mature end-to-end OTA architecture where the client and deployment server are designed as one system.

Do not migrate a working, field-proven updater merely because the deployment server is missing.

But do not pretend a device updater becomes fleet management merely because it can download a bundle from HTTPS.

The right choice depends on which layer you actually need to replace.

Related

• How do I manage RAUC updates across a fleet?
• How should I stage a RAUC rollout across production devices?
• How do I know whether a RAUC rollout actually worked?
• Dataplicity vs Mender
• RAUC image OTA requirements

External references

• RAUC documentation: https://rauc.readthedocs.io/
• Mender documentation: https://docs.mender.io/