Frequently asked questions about Mender

Open source, plan offerings, cost, and scalability

Yes, both the Mender management server and client on the target device are open source and free to use with a permissive license, Apache 2.0.

We also provide plans where we are responsible for hosting the Mender management server for you where users can avoid the setup and maintenance costs associated with running a server infrastructure.

Currently Mender has four plan offerings: Free open source, Starter, Professional, and Enterprise. Mender Open Source offers a robust and secure end-to-end update manager with client-server architecture and a set of core features. Mender Starter is an extension of the open source offering with a secure server we host for you. Mender Professional extends the Starter plan to include commercial value-added features with a secure server we host for you. Mender Enterprise extends the capability of the Professional plan with SLA backed support, custom pricing and customization to meet your unique requirements. Compare the plans and pricing at mender.io/plans/pricing.

We also offer consulting services.

The Mender server is regularly being scale tested in our environment, to ensure it can scale up to tens to hundreds of thousands devices. Setting up, optimizing, scaling and ensuring uptime of the server-side infrastructure is quite complex and environment-specific; device count, update size, frequency, polling intervals, high availability requirements and bandwidth available are key drivers for scalability.

We offer various plans where we take responsibility for all of the aforementioned complexity. With Mender Professional you scale based on your requirements with a secure server we host for you. For larger and more complex environments we have Mender Enterprise with SLA level support.


Yes, given the importance of the security of an OTA tool, Mender is partnering with a third party security auditing company. Issues are addressed as they are found.

The Mender client regularly polls the Mender server over HTTPS to check for updates so no ports need to be opened at the Mender client. Only TLS connections are allowed, the server rejects insecure connections.

To protect against man-in-the-middle attacks, the Mender client stores the server's TLS certificate during provisioning, e.g. during the build of the initial Yocto Project image that gets flashed to the device. CA-signed certificates is also supported.

Support for additional hardware and firmware/OS requirements

While Mender has strong support for the Yocto Project, it also supports the Debian family of distributions such as Debian and Raspbian.

Mender has also been ported to other build and operating systems like Buildroot and OpenWRT. Please see the blog posts Porting Mender to a non-Yocto build system and Notes from a user on Mender without Yocto for examples (note that some of Mender's needs may have changed since the blog posts were written).

We are also planning to expand the platform support further, please contact us for help with supporting your OS.

Yes. Mender has several reference devices, including the BeagleBone Black and Raspberry Pi 3, as well as a virtual device for testing purposes. These devices are part of the Mender CI system, are well supported, and you will see references to them throughout the documentation. Our Get Started guide and UI tooltips walk you through setting up a Raspberry Pi device with Mender.

Raspberry Pi 3 is supported for full system updates running Raspbian or Yocto Project builds.

For an overview of currently supported devices, please see the Board integration section of the Mender Hub forum.

Yes, Mender supports both GRUB and U-Boot. To support atomic rootfs rollback, Mender integrates with the bootloader of the device. The bootloader system requirements documentation contains more information on the exact U-Boot features leveraged.

In the spirit of open source, we would be delighted to give advice and feedback on implementation questions and pull requests for supporting more bootloaders; a good place to start is on the Mender Hub forum.

If you do not have time to work on this integration, we also offer board support services that can help meet all your integration needs.

Our strategy to support software updates to these devices is by using Mender on the gateway as a proxy to deploy remote updates to those smaller devices, through a variety of network protocols such as ZigBee, Bluetooth low energy and other local network technologies. With this approach, no agent is required to run on them.

For an example of how to use Mender to manage software updates for an external MCU, see this tutorial: How to do a proxy deployment to an FRDM-K64F device connected to a Raspberry Pi 3

Product specific

There were many trade-offs we considered as we began this project. Ultimately, we felt that Golang would best benefit the community due to the following:

  • Golang has more core language features and libraries that allows much faster development of applications. This means that more Mender features can be developed for the community and users much faster than if C was chosen as the language
  • The learning curve from C to Golang is very low, given the similarities in the language structures, as the co-founder of C (Ken Thompson) is also the co-founder of Golang
  • As it is a compiled language, Golang runs natively and very efficiently on embedded devices
  • Go is statically linked into a single binary, with no dependencies or libraries required at the device
  • Similar in size with C, Go binaries continue to get smaller as their compilers get optimized. For example, Go 1.7 reduced the binary size by 20-30%
  • Go provides wide platform coverage for cross-compilation to support different architectures

For dual A/B image updates, Mender requires four partitions: one boot, two root file systems, and one data partition, as described in the documentation for partition layout. A *.sdimg file with this reference layout is automatically generated when building Yocto Project images with meta-mender.

Mender places no upper limit on the number of partitions on your device. Also see the question on how to create more than four partitions.

Mender comes with a simple *.sdimg generator as part of the meta-mender Yocto Project layer. The *.sdimg files it outputs has Mender's reference partition layout with four partitions and is appropriate for flashing to SD cards using dd for testing and simple production use.

Production devices typically come with their own toolsets for generating and flashing internal storage like eMMC, e.g. imx-loader, mfg-tool, tegrarcm, or users are maintaining their own tools. Please refer to these tools on how to use the generated root file system with your desired partition layout and make sure to set the appropriate Yocto Project variables to tell Mender where the four required partitions are, as outlined in the storage documentation.

This is a Mender Artifact file which Mender uses to deploy updates. It contains various metadata required to deploy updates in a robust way, like the device types supported and version of the Artifact, in addition to the root file system update itself.

Internally it is packaged as tar archive. The Mender Artifact format is designed in such a way that multiple updates can be bundled in the same file. See the documentation on Mender Artifacts for a more detailed description.

The Mender Artifact format also supports package-based updates and updates for smaller devices.

For many devices with a display that interacts with an end user, it is desirable to ask the user before applying the update. You have probably seen this on a smartphone, where it will ask you if you want to update to the latest release of Android or iOS and it only starts after you hit "Apply".

This is supported by using the state scripting feature of Mender.

Mender automatically rolls back an update if it can not reach the Mender Server after the update is installed, in order to ensure another update can be deployed.

State scripting supports adding additional sanity checks to make sure that the device and applications are working as expected. For example, is the UI application running and responding within a given amount of time? If not, then the script can simply return 1 and Mender will roll back the update.

Mender streams the update from the server over HTTPS (or file, if used in standalone mode), so no temporary space is needed on the device. The checksum is also computed on the fly during the streaming.

Yes, Mender supports resuming downloads through HTTPs range requests. This is very useful in environments where downloads can get interrupted, e.g. if there is intermittent wireless network connectivity.

In order to offer generic robust rollbacks, Mender requires two rootfs partitions, which means effectively doubling the storage requirements for the rootfs. You can see the full partition layout in the documentation.

The most important design principles of Mender are 1) robustness and 2) ease of use. Currently, there is no other known approach that provides the generic robustness and simplicity of the dual rootfs approach. Secondly, the price of embedded storage is rapidly declining. This is why Mender takes a dual rootfs approach first.

In the future, other and less robust update mechanisms, such as variations of packages, tarballs, will be supported as well. Also see the question on application-level updates, as well as sensors and smaller devices below.

Yes, Mender has out-of-the-box support for application updates and use cases beyond dual A/B full image system updates. These use cases include containers (docker), packages (deb and rpm), files (directory copy/sync), and proxy deployment to peripheral devices.

The Mender client pulls the update from the management server. We chose this approach as it makes Mender work with more network topologies and reduces the attack surface of the client as no ports are open for Mender at the device.

Get in touch with us
to discuss how we can help!