# MicroMDM v1: an API-first Apple MDM server in Go, now in maintenance mode

> MicroMDM v1 is a self-hosted Mobile Device Management server for Apple devices that exposes device actions through an HTTP API and a CLI. It is in maintenance mode, so the decision is whether to run v1 as it stands or start on NanoMDM instead.

**micromdm/micromdm** — Mobile Device Management server

- Repository: https://github.com/micromdm/micromdm
- Website: https://micromdm.io
- Stars: 2,679 · Forks: 403
- Language: Go
- License: MIT
- Published: 2026-09-28 · Updated: 2026-09-28 · Language: en
- Canonical page: https://hysenlabs.com/projects/micromdm-micromdm

## What MicroMDM v1 actually solves for Apple fleet administrators

MicroMDM v1 is a Mobile Device Management server for Apple devices. The README states the design goal plainly: it is focused on giving you all the power through an API. That sentence is the whole product thesis. Instead of a web console where an administrator clicks through device groups, MicroMDM exposes scheduling of device actions and processing of the responses over HTTP, and ships a companion CLI, mdmctl, built from the same repository.

The audience follows from that. It is aimed at people who already run infrastructure as code and want device management to behave like the rest of it: enrollment profiles generated and served by the server, commands issued from a script or a CI job, responses captured through webhooks rather than read off a dashboard. The repository topics list macadmin and macadmins, and the user guide covers DEP provisioning alongside manual profile installs, which is the two-path reality of Apple device onboarding.

It is not a general endpoint management platform. The README describes a server for Apple Devices, and nothing in the repository layout suggests Android or Windows support. If your fleet is mixed, MicroMDM covers one part of it.

The other thing to know before anything else is the warning at the top of the README. The v1 project is in maintenance mode and support officially ends at the end of 2025. The README directs readers to explore or migrate to NanoMDM and the other projects in the Nano suite. That warning governs every other judgement in this article.

## How the server, the API and mdmctl fit together

The repository layout is the clearest description of the architecture. There is a cmd directory for the binaries, an mdm package, a server package, a platform directory, and separate top-level directories for dep and vpp. Those last two map to Apple's Device Enrollment Program and Volume Purchase Program, which are distinct integrations rather than features folded into the core server.

The dependency list in go.mod confirms the shape of the implementation. The server uses gorilla/mux for routing and go-kit/kit for the service layer, which is the standard Go toolkit pattern for splitting transport from business logic. It embeds boltdb/bolt as the storage engine, a single-file key-value store, so the server does not require an external database. Apple protocol work is handled by micromdm/plist for property lists, micromdm/scep for certificate enrollment, and smallstep/pkcs7 for the CMS signing that MDM payloads require. cfgprofiles handles configuration profile generation.

That stack explains the operational profile. You get one binary plus a data directory, which is why the Dockerfile declares a volume at /var/db/micromdm and runs micromdm serve as its command. Certificate authority duties are internal: SCEP enrollment is part of the server rather than delegated to a separate service.

The API and webhooks guide in docs/user-guide describes the loop at a high level: you schedule a device action through the API, and the server processes the response. The README does not document which endpoints exist, what the webhook payload contains, or how retries behave, so plan to read the docs directory rather than the README for that.

## Installing MicroMDM v1 and enrolling a first device

The repository ships a Makefile, so the documented build path is Go tooling rather than a package manager. The Makefile defines a deps target that runs go mod download, and a build target that produces the micromdm and mdmctl binaries. Note the version check in the Makefile: the gomodcheck target fails with the message that micromdm requires Go version 1.11 or higher. The Dockerfile builds with golang:1.20, while go.mod declares go 1.17, so pick a toolchain that satisfies both.

```bash
make deps
make build
```

After that, the binaries land under build/ for the current platform. The Dockerfile copies them from build/linux/ into /usr/bin/, which tells you the expected output path on Linux builds.

The container route is the shorter one, and the Dockerfile is explicit about what it exposes and where state lives.

```bash
docker build -t micromdm/micromdm .
docker run -p 80:80 -p 443:443 -v /var/db/micromdm:/var/db/micromdm micromdm/micromdm
```

The image exposes ports 80 and 443, declares a volume at /var/db/micromdm, and its default command is micromdm serve. Mounting that volume is not optional in practice: it is where the Bolt database and the server's certificates live, so an unmounted container loses its identity on restart.

From there the README points to docs/user-guide/quickstart.md for getting the server up, docs/user-guide/enrolling-devices.md for customizing the enrollment profile and getting it onto a device, and docs/user-guide/api-and-webhooks.md for scheduling actions. For a local environment or a demo, the README names the ngrok guide under tools/ngrok as the best resource, which is the practical answer to the problem that Apple devices need to reach your server over HTTPS on a public address.

## Where MicroMDM v1 stops being the right tool

The maintenance-mode notice is the first limitation and the largest one. The README says support officially ends at the end of 2025 and encourages migration to NanoMDM. The last push to the repository was on 2026-09-12 and the most recent release is v1.13.1 from 2025-10-17, but a recent push is not the same as a support commitment, and the project itself has stated the end date. Treat any deployment as a migration project with a deadline, not a steady state.

The second limitation is scope. The README describes a server for Apple Devices. There is no Android or Windows management here, and no indication that one is planned for v1. A fleet that is not Apple-only needs a second system regardless of what MicroMDM does well.

The third is the API-first design itself, which is a trade-off rather than a defect. The README frames API access as the point of the project, and the related searches include people looking for a MicroMDM UI, which suggests the absence of a bundled console is felt. If your administrators expect to click through a web interface to see device state, MicroMDM v1 will not give them that, and the API plus webhook model means you are building the reporting layer yourself.

The fourth is the storage choice. Bolt is a single-file embedded database. The Makefile even carries a comment that race tests are not run by default, linking to a bbolt issue, with a separate test-race target. That is a sign the maintainers were deliberate about concurrency testing rather than an indictment of the design, but it does mean the persistence layer is a file you have to back up and protect, not a replicated database you can fail over.

## NanoMDM and the Nano suite as the intended successor

The README does not leave the alternative to guesswork. It names NanoMDM, at github.com/micromdm/nanomdm, and refers to other projects in the Nano suite, and it frames the choice as explore or migrate. Same organisation, same problem space, different generation.

The difference in approach is structural rather than cosmetic. MicroMDM v1 is a complete server: it bundles the MDM service, the SCEP certificate authority, the Bolt database, and the command API into one deployable unit with micromdm serve as the entry point. The Nano projects are described as a suite, which implies the responsibilities that v1 welded together are separated into components you compose. That matters if you already have a certificate authority or a database you want to keep, and it matters less if you valued the single binary.

The practical consequence for a v1 user is that migration is not a version bump. Moving to NanoMDM means re-examining how enrollment, certificate issuance and storage are wired, because those pieces are no longer inside one process. The README gives the direction and the repository name; the docs directory in this repository is where the v1 behaviour is specified, and it is the reference you would compare against when mapping your current setup onto the successor.

## Licence, build cost and upgrade path

MicroMDM is MIT licensed. That is a permissive licence, so embedding the server in a commercial product or modifying it internally is permitted under its terms. This is not legal advice; read the LICENSE file in the repository if the distinction matters to your organisation.

The upgrade cost is dominated by the maintenance-mode notice rather than by the code. Support officially ends at the end of 2025, so the meaningful upgrade is not from v1.12.1 to v1.13.1 but from v1 to NanoMDM. The release history shows v1.13.0 in January 2025 and v1.13.1 in October 2025, so the v1 line did receive releases through 2025, but the README's own framing tells you where the effort goes next.

Build cost is low and predictable. The Makefile's deps target is go mod download and the build target produces two binaries. The Dockerfile is a two-stage build with CGO disabled, which means a static binary and no C toolchain requirement at runtime. The runtime image is alpine with ca-certificates added, which is a small footprint. There is no external database to provision, because Bolt is embedded.

What you should budget for instead is the operational work the API-first design pushes onto you: serving HTTPS on a reachable address, which is why the README points at the ngrok guide for local setups, and building the reporting and alerting that a bundled console would otherwise provide.

## Conclusion

Adopt MicroMDM v1 if you need a self-hosted Apple MDM server you can drive entirely from scripts and you accept that the project is in maintenance mode with support officially ending at the end of 2025. Do not adopt it for a new long-lived deployment, and do not expect it to manage Android or Windows devices, since the README describes it as a server for Apple Devices. Before committing, read the maintenance-mode blog post linked at the top of the README, check whether NanoMDM covers the same enrollment and command flow you need, and confirm the Go toolchain your build will use, because the Dockerfile builds with golang:1.20 while go.mod declares go 1.17.

## FAQ

### What is MicroMDM?

It is a Mobile Device Management server for Apple devices, written in Go and licensed under MIT. The README describes it as devops friendly and focused on giving you all the power through an API, with mdmctl as the companion command line tool.

### Is there a free MDM software?

MicroMDM is open source under the MIT licence, so there is no licence fee to run the server yourself. You still supply the host, the HTTPS endpoint that Apple devices can reach, and the operational work of running it, and the README notes that v1 is in maintenance mode with support officially ending at the end of 2025.

### Can MicroMDM manage Android or Windows devices?

No. The README describes MicroMDM v1 as a Mobile Device Management server for Apple Devices, and the repository layout covers Apple-specific integrations such as the Device Enrollment Program and the Volume Purchase Program.

### Does MicroMDM have a web UI?

The README does not describe a bundled web console. It presents the project as API-first, with device actions scheduled through the API and responses processed through webhooks, and the user guide covers the API and webhooks rather than a graphical interface.

### How do I install MicroMDM?

Build it from source with the Makefile, where make deps runs go mod download and make build produces the micromdm and mdmctl binaries, or use the Dockerfile, which exposes ports 80 and 443, declares a volume at /var/db/micromdm, and runs micromdm serve by default.

## Sources

- [License: MIT](https://github.com/micromdm/micromdm/blob/main/LICENSE)
- [micromdm/micromdm on GitHub](https://github.com/micromdm/micromdm)
- [Project website](https://micromdm.io)
- [README](https://github.com/micromdm/micromdm/blob/main/README.md)
- [Releases](https://github.com/micromdm/micromdm/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/micromdm-micromdm