Mender 1.4 beta: Preauthorize devices

9th Feb 2018

Mender 1.4.0 beta is here and ready for you to try out!

In addition, we are happy to announce the production release of Mender 1.3.1! The Mender 1.3.1 release notes contains the details on the improvements in the Mender 1.3.1 patch release.

The key features of Mender 1.4 beta are covered below, and you can see the detailed items in the Mender 1.4.0 beta release notes.

Preauthorize devices

You are probably familiar with the workflow of authorizing devices which are pending authorization. When provisioning a new device with Mender, you will get a UI notification similar to the following:

Device pending authorization

This is easy for testing and small-scale, but does not work well in a mass-production setting unless you always want to authorize all devices.

In order to improve integration with device mass production workflows as well as larger Enterprise platforms, the Mender server now also supports to preauthorize devices. When preauthorizing a device, you add its identity data and public key to the Mender server before it connects for the first time, so it is automatically authorized to receive software updates once it connects.

For example, in a mass production setting, you can call the preauthorize API after a device comes off the assembly line and it will automatically join the Mender server once it is sold and brought online by your customer.

The preauthorize device API is quite simple to use, you just have to send a POST request to one endpoint: /api/management/v1/admission/devices. An example API request looks like this:


POST /api/management/v1/admission/devices HTTP/1.1 <>
Authorization: Bearer <INSERT-USER-TOKEN>
Content-Type: application/json
Content-Length: 706


    "device_identity": "{\"mac\":\"02:01:02:03:04:05\"}",

If your request is successful, you will receive a 201 http response code. You can read more in the preauthorize API documentation.

Device authorization statuses

It is possible to preauthorize some devices, while leaving others to be inspected and authorized after they connect (the existing method). A complete overview of the authorization statuses and possible transitions of a device is shown below.

Device authorization statuses

The UI will also soon get more advanced functionality to manage these device states and transitions.

Read-only root file system support

As Mender writes an entire root file system partition, the system partition should conceptually be considered read only; any changes are made to it directly will be lost when the next OTA update is deployed. Data to be preserved should be stored on a separate partition.

Today the default build of Mender has the root file system partition configured as read-write. However, this default will be changed to read-only over time.

As the first step towards a default read-only root file system, we have tested and documented how you can configure your device with read-only root file system in Mender 1.4. You can read more in the documentation section configuring the image for read-only rootfs.

Easier modification of Mender Artifacts and disk images

Modifying a binary Mender Artifact or disk image in general entails unpacking, possibly loopback-mounting partitions and packaging again. This can be cumbersome, especially if you are doing only small modifications.

To simplify this, a modify option to the mender-artifact tool has been introduced in Mender 1.4. At the moment the option supports modifying key aspects of Mender configuration, like the server URI and TLS certificate, signature verification key as well as the Artifact name.

For example to change the name of an existing Artifact, you can simply run the following command:

./mender-artifact modify --name "release-10" raspberrypi3_release_1_1.4.0b1.mender

The same options work transparently on disk images as well, where both the root file system partitions are being modified:

./mender-artifact modify --name "release-10" mender-raspberrypi3_1.4.0b1.sdimg

You can download the prebuilt mender-artifact utility from the documentation on modifying a Mender Artifact.

Keep me logged in

To improve security, the Mender UI automatically logs you out after 15 minutes of inactivity in 1.2.0 and later versions. However, we got feedback that this security feature negatively impacted usability.

To address this, Mender 1.4.0 introduces the familiar "Keep me logged in" checkbox. By checking this when you log in, the Mender UI will not log you out even after prolonged inactivity (unless you explicitly log out, of course). Only use this option on a computer only you use and make sure to lock it if you leave it.

Keep me logged in

Other improvements

Help section

The Mender UI now has a Help section to ease in the initial onboarding process.

Help section navigation

For Hosted Mender, this section contains the exact commands you need to run, including any image URLs or tenant keys specific to your account:

Help - Build with Yocto

Inferred deployment progress bar

Mender 1.4 has progress bars for deployments, so you can easily track which state the deployment is in for any device:

Deployment progress bar

Please note that the progress is inferred, based on the state the device in. So it will only move as your device transitions from one state to another in the update process, e.g. from Downloading to Rebooting.

If you are using state scripts, they also have their separate states reported back, e.g. ArtifactInstall.Leave. This is useful in order to notice any unexpected delays or hangs while running your scripts.

Reduced server console logging

For those running an on-premise Mender server, a high volume of logs from the Dynomite service have been an issue. This is fixed by replacing Dynomite with Redis in Mender 1.4.

Please see the Mender 1.4 release notes for a full list of improvements in Mender 1.4.

Try Mender 1.4 beta

The documentation has a new 1.4 section that includes all the resources you need to get going. To test the new features, you can start with these pages:

Upgrading Mender 1.3 production installations

If you are using Mender 1.2 or 1.3, follow the Mender 1.3 upgrade documentation to upgrade to the 1.3.1 patch release.

It will likely work to use the same document to upgrade older releases of Mender as well, but please note that the official and tested upgrade path is always from the previous minor or patch release (i.e. 1.2.x and 1.3.0 releases for 1.3.1).

We do not recommend upgrading production installations to Mender 1.4.0 beta, rather create a new test environment (see link above).

Try Hosted Mender beta

Hosted Mender is a secure Mender server we host for you, so you do not have to spend time maintaining scalability, security, certificates, uptime, upgrades and compatibility of the Mender server. Simply point your Mender clients to our server!

Hosted Mender is currently in beta, already updated and fully compatible with the new Mender 1.3.1 and 1.4.0 beta client releases.

Sign up for Hosted Mender beta for free at

Support for your board

If you are getting started with OTA updates or do not have time to integrate the Mender client with your board, we are happy to help with professional services to enable Mender support for your board!

Share your feedback

We are happy to continue to see your general feedback on Mender, be it positive or need for improvement, on the Mender mailing list. Your continued feedback ensures Mender will meet your needs even better in the future!

If you believe you have encoutered a bug, please submit your report at the Mender JIRA issue tracker.

We hope you enjoy the new features and are looking forward to hearing from you!