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, Basic, 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 Basic is an extension of the open source offering with a secure server we host for you. Mender Professional extends the Basic 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. See our plans at plans at mender.io/plans/pricing.
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.
The Mender client can utilize private keys stored in Hardware Security Modules (HSM) or in Trusted Platform Modules (TPM). This is an additional layer of security which eliminates storage of private keys (secrets) as plain text files on the device, making it harder for an attacker to gain access to keys to impersonate devices.
Yes, Mender’s license is Apache 2, which is compatible with GPLv3. See the GPL compatibility page on the Apache.org website for details.
We provide an enterprise component which acts as mTLS edge proxy / ambassador. This component can take advantage of the customer’s PKI, use a customer’s specific TLS server certificate and verify client-side certificates. The mTLS ambassador can be hosted by the customer.
We can provide AWS Private Link service end-point from hosted Mender. It is the responsibility of the customer to set up a VPN from their infrastructure to an AWS account where the Private Link is connected.
No, Mender Artifacts do not support encryption. However it is possible to use encrypted files as payloads. Customers can write their custom Update Modules to manage the decryption.
It is complicated and therefore normally only encrypts certain files and folders and not full partition.
The Mender Enterprise server supports configurable API rate limits. When a device or a user is
crossing the rate limit threshold, it will receive the HTTP status code 429 Too Many Requests.
See also the Mender documentation section about Security.
No. Mender is currently focused on embedded Linux based operating system distributions. This is due to the popularity and market demand in using Linux based systems in creating IoT products and solutions.
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.
No. Linux OS, precisely speaking Linux kernel is the most popular OS for embedded IoT devices while Android is a framework built on top of Linux kernel. So every Android device is running Linux kernel but every Linux device doesn’t have Android. We can think of the Linux kernel as the foundation on which Android is built.
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 operating 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
It is possible to support LXC containers writing a custom Update Module. You can refer to the Kubernetes Update Module or the Docker Update Module as starting points.
A/B operating system updates work at the block level, thus can work with any filesystem.
Mender client can run on any platform golang can target, including x86.
Read/write; but if doing delta image updates, then read only.
Read/write; but if doing delta image updates, then read only.
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:
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 updates. These use cases include containers (docker), packages (deb and rpm), files (directory copy/sync), and proxy deployment to peripheral devices.
Yes. Mender provides a more efficient mechanism for updating software over-the-air when using cellular networks (e.g. 4G/LTE) with robust delta-based updates and automatic assignment of delta updates.
Delta updates are included in Mender Professional and Mender Enterprise.
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.
The client binaries are about 7 MB in size, or about 4 MB when debug symbols are stripped. This includes most of the dependencies for the client, such as the http, TLS, and JSON libraries.
It is architecture-dependent. The client depends on the LZMA library for Artifact compression, which is present in most Linux distributions, including those based on the Yocto Project.
Yes. Mender currently has integration with Google Cloud Platform and Microsoft Azure IoT. The reference integration ensures the same identity and cryptographic credentials are used by both Mender and the cloud service provider. Main benefits of this integration are that you no longer need to manage device registrations in multiple places, you can easily correlate analytics with past software update deployments with the Mender server, and you minimize the number of secret key credentials that need to be handled and protected which makes security stronger.
Yes. Mender server can be installed on any private infrastructure as a self-managed service. To read documentation for self-managed installations of the Mender server, visit the documentation page of the latest stable release.
Yes. The public APIs are split into two types - Device and Management. Device APIs are for device-originating requests, the Management APIs are intended for use by the UI and other tools that manage devices, Artifacts or deployments across devices.
Yes. Read here to learn more about how to use Helm charts with Mender.
You need to generate binary delta Artifacts, and you must start with two full file system Artifacts. You can use Yocto, mender-convert, or any mechanism of your choice to create the images. See Create a Delta update Artifact to learn about the commands.
There are two client configuration parameters that allow controlling the frequency of communication between the client and the server: UpdatePollIntervalSeconds and InventoryPollIntervalSeconds. Both parameters are stored in a configuration file /etc/mender/mender.conf and can be modified to change the polling intervals.
Consult this section of Mender documentation on all the configuration options in mender.conf
Yes. Mender uses a framework called Update Modules to include updates to peripheral devices. An Update Module is an extension to the Mender client for supporting a new type of software update, such as a package manager, container, bootloader and updates of nearby devices such as microcontrollers. Learn more about how to Create custom Update Modules.
You can customize artifact download and installation processes through the use of state scripts. Mender state scripts can be run between any state transition, not just before/after the install state and has nine different states as you transition into a state, “Enter” or out from a state, “Leave”.
A: Software streams directly to and installs on a disk partition on the device. The simplest and most robust way to update a device is to write a new file system image directly to the flash partition. Mender comes with built-in support for a dual redundant scheme (also known as A/B scheme), which ensures that the device always comes back to a working state in event of a failure.
Mender provides special integration points for your existing boot code to hook into so that Mender can be a part of the normal boot process. These integration points, along with certain required U-Boot features and configuration options, allow Mender to do safe, automatic updates of the device, with rollback support. This normally requires patching of stock U-Boot versions, which is what the automatic process does. Learn more here.
No. Mender Enterprise instead supports Dynamic groups, which allows you to define a group based on filters. Dynamic groups allow a single device to appear in multiple groups which is not possible with hierarchical or nested groups. This allows much more flexibility to group by both geography and product.
Yes. This is done through standalone deployments. Standalone works with Mender where no Mender server is used and the deployments are triggered at the device, either manually in the terminal or by custom scripts. This can be useful in order to deploy updates to devices which do not have network connectivity or are updated through external storage like a USB stick.
If you would like to run Mender in standalone mode, you must make sure that the Mender client does not run as a daemon. In most cases this will entail disabling or removing any systemd unit that starts the Mender client. Learn more about it in the Mender documentation.
Mender will mark the update as successful and permanent by running this command: mender -commit. Learn more about it in the Mender documentation.
The deployments are triggered at the device, either manually in the terminal or by custom scripts.
You can always install artifacts on a device running the Mender client independently from the server, using the Mender client in stand-alone mode.
