Headwind MDM: an open source Android device management panel for corporate fleets

What the platform does and who it is built for

Headwind MDM is a Mobile Device Management platform for Android devices, designed for corporate app developers and IT managers. The project describes itself more specifically as a platform for corporate Android applications, and the copyright line is 2020 h-mdm.com.

The feature list covers the whole device management surface. Enrollment to Android 7 and later devices through scanning a QR code. Working in Application mode without enrollment. Customizing the mobile desktop design and the available applications. Automatic deployment of applications through the web panel. Mobile device management with groups, configurations and device status. Setting the available mobile device capabilities such as GPS, Wi-Fi and Bluetooth. Managing the automatic OS update mode on the device. An extensible platform design allowing custom plugin development. Collection of application logs in the web panel. And centralized configuration of corporate applications.

The audience is specific. This is not a consumer device manager, it is a way to get a fleet of Android phones and tablets into a known state, push your own corporate applications onto them, and see what they are doing. The application mode entry point matters here, because it lets you use the platform without the full enrolment flow, which is the path for a device you already control and are not trying to manage through the QR code dance.

The project also asks for contributions, specifically plugins related to mobile device management, and points to the project website for developing a public plugin, suggesting a feature, ordering custom development or reporting a bug.

The web panel is Java on Tomcat, and the scripts do the deployment

The control panel is cross-platform, because it is written in Java and uses the Tomcat web server, though the documentation is clear that the best OS for the deployment is Ubuntu Linux.

The repository layout shows how the deployment is organised. There is a pom.xml at the root for the Maven build, a server/ directory for the web application, a common/ directory for shared code, a plugins/ directory, a swagger/ directory for the API description, and an install/ directory.

Then there is the set of scripts, and they are the interesting part for an administrator. There is hmdm_install.sh, which is the installer script for placing the web panel on the server, letsencrypt-ssl.sh for TLS certificates, iptables-tomcat.sh for the firewall rules the container needs, update-web-app.sh for updating the deployed panel, init-plugin.sh and init-plugin.bat for the plugin initialisation, and cpu_monitor.sh. There is also a jwt/ directory for token handling, a notification/ directory and a docs/ directory.

So the deployment model is a Java web application, built with Maven, installed onto a server by a shell script, with the operational pieces written as separate small scripts rather than folded into the application. That is a reasonable shape for a product whose installer has to handle Tomcat, certificates and firewall rules on the target machine.

The quick start path, from a QR code to an enrolled device

The quick start is five steps and it is worth following in order, because two of them are things you cannot do from the panel.

Clone the project and build it, with the details in BUILD.txt. Install the web panel to the server by using the installer script. Open the web panel and follow the hints to generate a QR code. Perform the factory reset on your Android device and tap 7 times on the welcome screen. Then follow the instructions to scan the QR code and enroll the mobile agent.

The seven taps on the welcome screen is a detail specific to Android's developer options, and it exists so that the device exposes the settings the enrolment needs. The factory reset comes before it for the same reason, since enrolment wants a clean device with the development options available.

The QR code is the mechanism that carries the enrolment configuration from the panel to the device, and it is the piece that makes the whole thing practical for a fleet. Scanning a code on each device beats typing a server address on each device.

The INSTALL.txt and TROUBLESHOOTING.txt files in the repository are the reference for the deployment and for what to do when the enrolment does not go through, and the VIBECODE.md and CLAUDE.md files indicate that the project has been set up for AI assisted development, which is worth knowing if you plan to contribute.

The enterprise edition and the features it holds back

The split between the open source server and the paid edition is the most important thing to understand before you deploy this, because several of the capabilities you would most want are on the paid side.

The enterprise edition adds the restriction of mobile user functions, described as a kid's shell for corporate users, and the ability to disable changing the mobile device settings. It adds kiosk mode with COSU and single-task mode. It adds sending images from the mobile device to the server. It offers cloud-based or self-hosted server setup, premium support for enterprise users, and custom plugin development services.

The two to look at closely are the lock-down features. A corporate fleet usually needs to stop a user from opening settings and undoing your configuration, and the open source list does not include that. Without it, the enrolment and configuration story is a convenience rather than a control.

The enterprise edition may be ordered on the project website.

This split is a legitimate business model for a product where the hard part is support and the enterprise feature set, but it does change how you evaluate the project. The server code is Apache-2.0 licensed and the repository is the full server, but the product you may need is partly commercial.

The alternative to consider is running a general device management product, where the lock-down features are included in the price you already pay, or writing the policy layer yourself with device owner APIs. The difference in approach is that Headwind MDM separates the open platform from the commercial features, while a general MDM product ships the whole policy set and the vendor keeps it behind a subscription.

Where Headwind MDM is the wrong choice

The first limit is the platform scope. This manages Android, and only Android. There is nothing in the feature list about iOS, which means a company with a mixed estate either runs two systems or standardises on Android for the devices it manages.

The second is the version floor on the agent side. Enrollment is to Android 7 and later devices, so anything older is out of scope, and the documentation does not describe behaviour on older releases.

The third is the deployment work. The control panel is a Java web application on Tomcat that you install with a script onto a server, and the operational scripts cover TLS certificates, iptables rules and plugin initialisation. That is a real footprint: a server to patch, certificates to renew, and a firewall configuration to maintain. A team that expected a hosted console has to think about who runs the box.

The fourth is the plugin dependency. The extensible platform design is a strength for a company that needs specific integrations, and it is a cost for a company that just wants the standard features, because the documentation routes plugin development through the project website rather than describing a self-serve plugin API.

The fifth is the split between what you can run and what you can buy. The server is open source and self-hostable, and some of the control features live in the enterprise edition, so a strict reading of the open source part gives you deployment and monitoring without the restrictions.

Compare that with the alternative of a device management product with an agent you install from a managed cloud. The difference in approach is that a hosted product takes the server off your hands and bundles the policy features into the subscription, while this project gives you the server and the deployment work, and sells you the lock-down behaviour separately.

Licence, releases and what to verify before the first enrolment

The server code is released under the Apache-2.0 licence, with the LICENSE and NOTICE files at the repository root. The Apache 2.0 terms are permissive, with a patent grant, and they allow you to run and modify the server for internal corporate use without a per-device fee, which is the point of the open source edition. You should read the LICENSE file yourself for the exact terms.

The release history shows an active maintenance line. v5.40.1 came on 2026-07-21, v5.40.2 on 2026-08-04 and v5.41.1 on 2026-09-03, and the last push was on 2026-10-15, so the tree is about a week old relative to today. The default branch is master and the repository is not archived.

What to verify before the first enrolment is a concrete checklist. Read BUILD.txt and INSTALL.txt rather than the five line quick start, because the panel is a Tomcat deployment with certificates and firewall rules attached and the short version skips the details that matter on a real server.

Then test the enrolment on one device, not ten, and confirm the QR code path works with your device fleet manager. If you plan to use the application mode instead, verify that the panel can push your application and that the device stays in the state you expect afterwards.

Finally, decide which of the enterprise features you need, because the answer changes what you are buying. If it is the restrictions and kiosk mode, budget for the enterprise edition rather than planning to build them, and if you only need the open source server, confirm that the absence of those restrictions is acceptable to your security team before you roll the fleet out.

Editorial conclusion

Headwind MDM fits an organisation that ships Android devices to staff or customers and needs enrolment, app deployment and device status in a panel it hosts itself, and it fits a team that wants to extend the platform with plugins. It does not fit a mixed iOS and Android estate, and the restrictions that make a corporate fleet manageable are in the enterprise edition rather than the open source server. Before you deploy it, read BUILD.txt and INSTALL.txt end to end, plan the enrollment flow with your device fleet manager, and confirm which of the lock-down features you actually need are only in the paid edition.

Frequently asked questions

Official sources

1. h-mdm/hmdm-server on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases