Yes, both the management server and the client on the device are open source with a very permissive license, Apache 2.0.
We are initially focused on support subscriptions and services as our business model. 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.
Our initial release is an on-premise management server, however we have plans 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.
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:
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.
Mender has two reference devices: BeagleBone Black and a virtual QEMU-based one using
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.
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 through installer modules. Also see the question on sensors and smaller devices below.
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.
We are currently focused on doing full image-based updates with a dual rootfs partition in order to ensure a robust approach due to potential failures such as poor network connectivity or power failure of endpoint devices. Our chief goal is to ensure the updates are secure and reliable.
However, we have begun investigating package-based and other types of updates and we expect to implement that once we have a robust approach for image-based updates.
This is a planned feature.
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.
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.
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 firstname.lastname@example.org.
Or follow our Getting Started Guide to start using Mender today.