Is the management server open source?

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

What is your business model?

We are initially focused on support subscriptions and professional services as our business model. Our support subscription includes a dedicated Mender contact with access to our support ticket system with defined service level agreements.

After building a very healthy baseline OTA updater, we plan to add commercial add-ons for more sophisticated functionality.

We also plan to host the management server for customers as a commercial SaaS offering.

Is it on-premise or hosted?

Our initial release is an on-premise management server. However, we are planning to offer a hosted/SaaS server after we ensure the infrastructure takes into consideration all the security nuances to ensure a trusted and secure environment. This will remove the need to setup and manage the web application.

Is Mender going through third party security audits?

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. Mender Software Support customers get immediate notifications and steps to remediate security findings.

Why did you write Mender (the client and server) in Golang instead of C?

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

How about other embedded Linux distributions?

While Mender has an optimized experience with the Yocto Project, it is possible to adapt to other build systems. Please see this blog post for an example (note that some of Mender's needs may have changed since the blog post was made). Also, please keep in mind that using other build systems than Yocto is unsupported at this time.

Does Mender support the Raspberry PI or other devices?

Mender has two reference devices: BeagleBone Black and a virtual QEMU-based one using vexpress-qemu. These devices are part of the Mender CI system, well supported and you will see references to them across the documentation. The purpose is to have one virtual device, as you do not need any hardware to test, and one physical device, to make sure Mender works in real scenarios.

In order to lower cost of scaling and meeting needs of specific applications, no two production devices have the same hardware specifications. This means that software such as Mender must be integrated with production devices.

In conclusion, we do not plan to add any more reference devices. Additional device integration will be handled either by community contributions or consulting engagements and you can see them in the meta-mender repository. However, they will not be as well tested as the two reference devices.

Does Mender support using other bootloaders than U-Boot, e.g. GRUB?

To support atomic rootfs rollback, Mender integrates with the bootloader of the device. Currently Mender supports U-Boot, as it is by far the most widely used bootloader on embedded devices. The bootloader system requirements documentation contains more information on the exact U-Boot features leveraged.

As part of broadening the platform support, we do anticipate adding support for other bootloaders like GRUB in the future, although no short term plans are in place for this at the moment.

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 community mailing list.

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.

How many partitions does Mender support on the device?

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.

How can I create more than four partitions on my device?

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.

What is the purpose of the *.mender file and what does it contain?

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, however the Mender client currently only supports a single root file system update. See the documentation on Mender Artifacts for a more detailed description.

Also see the questions on package-based updates and updates for smaller devices -- these features will leverage the same Mender Artifact format when the Mender client has support for them in the future.

Does Mender stream the update to the partition?

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.

The dual-rootfs approach takes up additional storage, how can this be addressed?

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 OSTree, packages, tarballs, will be supported as well. Also see the question on application-level updates, as well as sensors and smaller devices below.

Does Mender support application-level or package-based updates?

We are currently focused on doing full image-based updates with a dual rootfs partition in order to ensure a robust approach in the presence of potential failures such as poor network connectivity and power loss of endpoint devices during the update process. Our chief goal is to ensure the updates are secure and reliable.

Applications can also be updated as part of image based updates today and we plan to improve support for application-level updates further by integrating with package managers and other types of installers.

How about delta-based updates due to bandwidth concerns?

This is a planned feature.

How does the Mender client-server communication work? Is it secure?

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.

Does the management server push the updates to the clients on the endpoint 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.

How about sensors and other smaller devices?

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.

Have more questions? Email us at contact@mender.io.

Or follow our Getting Started Guide to start using Mender today.