Dataplicity vs Mender: which platform fits your Linux fleet? #

Choose Mender when secure software and OS update management is the centre of the problem. Choose Dataplicity when updates are one part of a broader post-shipment problem that also includes remote support, fleet diagnosis, reliability, product state, customer tenancy, and customer-facing software.

This comparison should not reduce Mender to "an OTA tool", and it should not reduce Dataplicity to remote access.

Both products overlap across device management. Compare which architecture you want to make central, and which responsibilities each one leaves with you.

Reviewed against public Mender documentation and current Dataplicity product contracts on 7 September 2026.

Mender: update-centred device management #

Mender provides a mature client/server OTA architecture for embedded Linux, and separately for supported microcontroller environments. Its documentation covers OS, application, and container updates, Mender Artifacts, deployment management, phased rollouts, and device-management add-ons including Remote Terminal, Port Forward, File Transfer, Configure, and Monitor with alerting.

For robust system updates, Mender uses A/B root filesystem designs with bootloader state, commit, and rollback, which requires board and boot integration.

Mender is not one monolithic release. Current supported components are Mender Client 6.0, Mender Server 4.1, Mender Gateway 2.1, and Mender MCU Client 1.0. The Linux client was rewritten in C++ and split into mender-auth and mender-update, with root filesystem writing moved into an Update Module backed by mender-flash. The deb, rpm, docker, and script modules now live in a separate Update Modules repository, and Client 6.0 adds a supported docker-compose module.

Two additions are worth knowing:

Mender Gateway proxies devices on segregated networks, can cache Artifacts locally, and supports mTLS provisioning. It is an Enterprise capability.
Mender Orchestrator previews coordinated multi-component system updates with topology, manifests, ordering, and system-level rollback. It requires Client 6.0 and Mender's documentation states it is not yet recommended for production.

Mender also now covers microcontrollers through its MCU client and Micro device tier. If your estate mixes Linux devices with Zephyr-class hardware, that is a genuine Mender advantage. Dataplicity is a Linux product.

If your primary procurement problem is:

We need a mature, end-to-end mechanism for safely deploying software and complete Linux system updates.

Mender deserves serious consideration.

Dataplicity: the post-shipment Linux product operating layer #

Dataplicity starts from the broader problem of operating a Linux product after it leaves the factory.

Its centre of gravity includes:

remote engineering access and support;
device logs and diagnostics;
fleet jobs and cohort operations;
Device Classes and stable product definitions;
Pulse fleet drift and reliability evidence;
application and container release management;
optional first-class RAUC OS-image management;
customer, site, and device tenancy;
branded Customer Portal;
Product Applications and device-facing workflows.

For RAUC fleets, Dataplicity does not replace the device-side RAUC safety model. It manages the surrounding fleet problem: image catalogue and pins, staged cohorts, delta delivery where supported, durable rollout outcomes, rollback and validation visibility, and release-health context.

If you want a worked starting point rather than an integration project, Dataplicity OS ships a CM5 reference image with RAUC A/B slots, tryboot integration, and persistent state already in place. It is a reference implementation, not a required distribution.

The OTA difference #

Mender owns both the device client and the deployment platform for its update architecture.

Dataplicity can instead sit around an existing RAUC architecture:

text

your build system
    ↓
signed RAUC bundle
    ↓
Dataplicity targeting + rollout
    ↓
RAUC install / boot / mark-good / rollback
    ↓
Dataplicity outcome history + fleet/release health

This matters for brownfield products. If a field-proven RAUC image, bootloader, and recovery procedure already exist, the choice is not necessarily "replace RAUC with Mender or remain manual". You can keep RAUC and add the missing fleet layer.

Mender's documentation does not describe a supported native RAUC integration. Because Update Modules can wrap an arbitrary installer, a custom module could invoke RAUC, but that is integration you would design and maintain rather than a documented Mender capability.

See RAUC vs Mender for that architecture decision specifically.

Choose Mender when... #

Mender is the stronger fit when:

robust OTA is the main procurement reason;
you want the updater and central deployment service designed as one system;
your release engineering is built around Mender Artifacts;
software and OS rollout semantics matter more than customer-facing product software;
devices sit on segregated networks where a caching gateway helps;
the estate includes microcontrollers as well as Linux devices;
you want Mender's device-management add-ons around that update-centred architecture.

If the roadmap is mostly "we must safely update the Linux system across thousands of devices", Mender is a natural product to evaluate.

Choose Dataplicity when... #

Dataplicity is the stronger fit when:

you are operating an existing Linux product and want to preserve its OS and application architecture;
support engineers need direct diagnosis and fleet evidence as much as software deployment;
the estate is brownfield or heterogeneous;
you already use RAUC and need fleet orchestration rather than a replacement updater;
OS image, application, remote-support, and reliability workflows need to coexist;
downstream customers need their own portal, users, sites, and device views;
the customer relationship needs product-specific pages and customer-safe controls, not only an isolated tenant;
product workflows span vendor, cloud, customer, and device state beyond a release event;
enterprise governance and approval controls around high-risk actions matter.

The advantage is breadth across the vendor, Linux device, and customer loop.

Mender now has multi-tenancy. Read what kind. #

Mender Enterprise supports Service Provider multi-tenancy: a parent tenant creates and administers isolated child tenants, including their users, device limits, and inherited SSO. Mender's own documentation gives downstream customers as an example. Any comparison claiming Mender has no customer tenancy is out of date.

The distinction that still holds is what the tenant contains. A Mender child tenant is a scoped device-management workspace. Dataplicity's Customer Portal is a branded, product-specific surface built on Device Classes: customer, site, and device allocation, product streams and settings, customer-safe actions, and bounded workflows through Product Applications. Mender's documentation does not describe white-label branding, an embeddable end-customer portal, or product workflow records.

Choose on that basis, not on whether the word "tenant" appears in both products.

Brownfield nuance #

Mender does not always require replacing the existing OS. Application Update Modules can be installed on an existing Linux system, while robust full-system updates require deeper partition, bootloader, and board integration.

Likewise, Dataplicity's RAUC support does not mean any Linux device automatically becomes safe for managed A/B updates. The customer image still needs a qualified RAUC slot layout, bootloader rollback, persistent-data design, and physical validation.

Compare the responsibilities you are adopting, not caricatures of either agent.

Decision table #

Decision	Mender	Dataplicity
Primary architecture	Update-centred device management	Connected-product / Linux fleet operating layer
Full OS OTA	Core Mender architecture with required integration	First-class for qualified RAUC Device Classes; RAUC remains device-side updater
Application updates	Core, through Update Modules including `docker-compose`	Software Builds / container orchestration
Existing RAUC fleet	No documented native integration; a custom Update Module is your own work	Keep RAUC; add fleet orchestration and outcome visibility
Reference OS image	Yocto layers and board integrations you assemble	Dataplicity OS CM5 image, or your own qualified Linux
Staged image rollout	Core deployment capability, phased and dynamic groups	Tag/cohort waves for managed RAUC images
Delta updates	Robust rootfs deltas; automatic server-side generation on Enterprise	`casync` delivery for OS images and Class Software
Multi-component system updates	Orchestrator, in preview on Enterprise	A Software Build composes container versions with an optional OS image per Device Class
Update rollback truth	Mender update architecture	RAUC slot/boot truth recorded as fleet outcomes
Segregated networks	Mender Gateway with Artifact caching	Outbound agent connection; no inbound port required
Microcontrollers	Mender MCU client and Micro tier	Not covered; Dataplicity is a Linux product
Remote terminal / access	Available as add-ons	Core support capability
Fleet drift / reliability correlation	Monitoring, checks, and alerting	Pulse Issues / Releases and fleet comparison are first-class operating concepts
Tenancy model	Service Provider parent/child tenants on Enterprise	Customer, site, and device model behind Customer Portal
Customer-facing product UI	Not described in public documentation	First-class
Product workflow records / processes	Not the core product	Product Applications
Best fit	Update-centred device management across Linux and MCU estates	Whole post-shipment Linux product operations

They can still coexist #

There are estates where Mender and Dataplicity can sensibly coexist.

An organisation with a deeply established Mender update programme may use Dataplicity for a different operational layer rather than replacing the updater for architectural neatness.

Likewise, a company with an established RAUC architecture can use Dataplicity without adopting Mender at all.

Replace a mature field mechanism only when the replacement solves a real problem.

No cloud platform substitutes for device update engineering #

Whether you choose Mender or RAUC with Dataplicity, robust OS updates still depend on the device design.

You must address concerns such as:

bootloader-integrated rollback;
power-failure behaviour;
slot and partition design;
persistent data compatibility;
image integrity and signing;
product-specific validation;
physical testing on the hardware you ship.

The fleet platform can orchestrate and observe those mechanisms. It cannot make an unsafe image layout safe by adding a dashboard.

Where Mender is plainly stronger #

Against a platform that orchestrates an existing RAUC setup, Mender is stronger where an integrated OTA stack earns its keep:

its own versioned Artifact format with a metadata and dependency model
a native client/server deployment lifecycle with status and rollback reporting
turnkey A/B bootloader and partition integrations across many boards
automatic server-side delta generation
phased and dynamic-group rollouts as a core deployment primitive
hosted and self-hosted server options
Gateway, audit, RBAC, and mTLS in Enterprise
microcontroller coverage alongside Linux

Sources #

Primary Mender documentation:

Dataplicity: