Open Source Mac Device Management for Small

A small Mac fleet is one of the easiest things in IT to overpay for. Commercial Apple MDM platforms charge per device, per month, forever, and while the roughly $1 to $7 per-device range that a 2026 build-versus-buy analysis from Fora Soft documents looks trivial on a single invoice, it compounds across years and forces small teams to accept a vendor’s data model, a vendor’s roadmap, and a vendor’s terms. For organizations that want control, transparency, and a near-zero licensing line item, two open-source projects have quietly become the default answer: MicroMDM and its actively developed successor, NanoMDM. This series is a practical, five-part guide to running either one in production for a small Mac fleet in 2026.

Key Takeaways:

• MicroMDM v1 entered maintenance mode in June 2025, with support ending at the end of 2025; NanoMDM is the actively developed successor.
• NanoMDM is a minimalist Apple MDM protocol server, not a turnkey product, you supply SCEP, TLS, enrollment profiles, and a workflow layer yourself.
• Open-source MDM eliminates per-device licensing but shifts cost into engineering time, certificate management, and operational ownership.
• This five-part series walks through deployment, architecture, scaling, and security for small Mac fleets, start to finish.

Why Open-Source Apple MDM Matters in 2026

Apple device management has changed more in the last two years than in the decade before it. At WWDC 2026, Apple made a decision that directly affects anyone self-hosting MDM: legacy MDM software-update commands are removed in iOS, iPadOS, and macOS 27, which ships in fall 2026. Querying, scheduling, and deferring updates through the old command-and-response model stops working. Software updates must instead be driven through Declarative Device Management (DDM) declarations. Apple also moved core network settings (VPN, encrypted DNS, relays) to DDM and tightened TLS requirements for management traffic.

That shift matters because it changes what “running an MDM server” means. A self-hosted stack that only speaks the legacy protocol will silently lose update enforcement the moment a device upgrades to OS 27. The open-source projects in this series have had to adapt to that reality, and their differing responses are part of why the choice between them is now clearer than it was a few years ago.

The second reason open-source MDM matters is cost structure. Commercial platforms such as Jamf, Iru (formerly Kandji), Mosyle, Hexnode, and Microsoft Intune all solve the common case at roughly $1 to $7 per device per month, per the Fora Soft analysis. That pricing is honest and often worth it. But it is a recurring expense that scales linearly with fleet size, and it locks you into a vendor’s data model. Open-source MDM replaces that recurring line item with engineering effort, a trade-off that only makes sense when you understand exactly what you are taking on.

MicroMDM and NanoMDM: What Each One Actually Is

MicroMDM is the older of the two projects. It is a Go-based, MIT-licensed MDM server for Apple devices, with its origins in the IT team at Square, and it speaks the Apple MDM protocol directly, meaning it integrates with Apple Business Manager and Apple School Manager workflows. The project holds roughly 2,600 GitHub stars, a figure reported in a June 2026 roundup from Headwind MDM, and describes itself as “a performant and extensible device management solution for enterprise and education.”

The critical fact about MicroMDM in 2026 is its status. In June 2025, project maintainer Jesse Peterson published a post titled “MicroMDM v1 project maintenance mode”, formally confirming what had been true for years: no new feature work will happen in the v1 codebase, and security and bug fixes were only on an available-effort basis through the end of 2025. The official guidance is to migrate to NanoMDM and the “Nano-suite” of projects. MicroMDM v1 is not abandoned (the repository still sees commits and it remains a functional, batteries-included way to stand up a working server) but it is a dead end for anyone planning a long-term deployment.

NanoMDM is the successor. Its README describes it as “a minimalist Apple MDM server and library heavily inspired by MicroMDM,” and that word “minimalist” is doing real work. NanoMDM is just the core MDM protocol server: device and user enrollment lifecycle, APNs push notifications, and queueing and delivering commands. It is MIT-licensed, written in Go, created in 2021, and actively maintained. It ships with MySQL and PostgreSQL storage backends, supports horizontal scaling with minimal local state, handles multiple APNs topics (enabling multi-tenancy), and includes a migration endpoint for moving enrollments between storage backends or servers.

What NanoMDM deliberately does not include is just as important. There is no built-in SCEP service, no TLS termination, no ADE/DEP API access (though DEP enrollments are supported), no enrollment profile generation, no “blueprints” for automatic command sending, no JSON command API, and no VPP integration. Each of those is a component you supply yourself. The project’s own comparison frames it plainly: “NanoMDM is but one component for a functioning MDM server. At a minimum you need a SCEP server and TLS termination.”

MicroMDM vs. NanoMDM: A Side-by-Side Comparison

The two projects solve the same problem with opposite philosophies. MicroMDM is the “batteries-included” option: a single binary with a built-in command and webhook API, which makes it the fastest path to a running server and a good way to learn the protocol. NanoMDM is the deliberately minimal reimplementation, a small core plus composable libraries designed to be embedded, scaled horizontally, and run multi-tenant. Both speak the same Apple MDM protocol, so the certificate and enrollment mechanics are identical; the difference is in what you assemble around them.

The star counts come from the Headwind MDM roundup, which also makes a point worth internalizing: both projects are “infrastructure components rather than turnkey MDM products.” There is no full-featured graphical management interface, and there is no commercial support option from a vendor. If you are expecting a polished dashboard where you click to push a profile, neither project provides it out of the box. What they provide is a server you can build a management workflow around.

Who This Series Is For (and Who It Is Not)

This series is written for a specific reader: the technical lead, IT generalist, or platform engineer at a small organization that runs a fleet of Macs (roughly ten to a few hundred devices) and has the systems-administration skills to own a server. If you are comfortable with the command line, DNS, reverse proxies, and certificate management, you are the target audience. If your organization already has a dedicated Apple administrator who lives in Jamf, the series will still explain the trade-offs, but you may conclude the commercial route is the right one for you.

It is equally important to be clear about who should not self-host. A one-person shop managing three Macs does not need an MDM server at all; Apple Configurator remains a practical manual alternative for fleets under ten devices. And a regulated organization that needs SOC 2, HIPAA, or similar evidence (with auditors who expect vendor attestations and tamper-evident audit logs) will likely find that the compliance layer around a self-hosted server costs more in engineering time than a commercial subscription. The build-versus-buy math from Fora Soft puts the pure-cost break-even for a custom MDM near 3,000 devices, which tells you something about how front-loaded the effort is.

Open-source MDM sits in a comfortable middle: you are not building an MDM from scratch (NanoMDM is explicitly recommended by that same analysis as a “viable base” to extend), and you are not paying per-device fees. You are assembling and operating a server. That is a distinct category with distinct responsibilities, and the series treats it that way.

The Full Arc: What Each Part Covers

The series is organized as a progression from “get it running” to “keep it secure,” because that is the order in which real deployments actually fail. Most people can get an MDM server listening; the hard parts are the certificates, the architecture, the scale, and the security that come after.

Part 2, Deployment. The next installment covers getting MicroMDM and NanoMDM installed and configured for a small fleet. This is where the single biggest hurdle appears: the Apple Push Notification service (APNs) MDM push certificate, which requires annual renewal and is only issued through specific routes, joining the Apple Developer Enterprise Program, using the community mdmcert.download service, or extracting one from Profile Manager for testing. The deployment installment walks through the installation, initial configuration, and the certificate paths that determine whether your self-hosted stack is viable at all.

Part 3, Architecture. This part compares the design principles of the two projects in depth: MicroMDM’s componentized, publish-subscribe approach versus NanoMDM’s simpler request-response design, where HTTP handlers adapt directly to a service layer and then to a storage abstraction. It covers how these servers fit into an existing IT environment, the modularity of the Nano-suite (projects like NanoDEP, NanoCMD, and NanoHUB), and how to plan an architecture you will not have to rip out in a year.

Part 4, Scaling. Scaling is where NanoMDM’s design decisions pay off. Because it keeps minimal local state and pushes persistence into MySQL or PostgreSQL, it can scale horizontally in a way MicroMDM’s BoltDB backend could not. This part covers clustering, load balancing, and failover setups appropriate for a small organization that is growing, and it is honest about the point at which “just add another server” stops being the answer.

Part 5, Security and Compliance. The final part covers the layer most self-hosters neglect until an audit forces it: managing certificates (APNs, SCEP, TLS), enforcing FileVault and passcode policies, and producing the evidence an auditor or cyber-insurance carrier will ask for. It also covers what open-source MDM cannot do (location tracking and remote screen control are simply not features of these projects) so you know where a commercial supplement is unavoidable.

The Real Cost of Self-Hosting

It is tempting to frame open-source MDM as “free,” but that framing collapses the first time a certificate expires. The honest cost model has three parts. First, there is infrastructure: a server or virtual private server with uptime, security patches, and backups. Second, there is certificate lifecycle management, the APNs push certificate has a 365-day lifespan and must be renewed with the same Apple ID that created it, and the APNs “topic” embedded in the certificate cannot change during a device’s enrollment, which means swapping certificates requires re-enrolling every device. Third, there is the expertise itself: Linux administration, network security, and a working knowledge of Apple’s MDM protocol.

The Fora Soft analysis that frames custom MDM economics makes one claim worth taking seriously: certificates are the number-one silent failure in self-hosted management, accounting for a large share of post-launch outages. That is not a reason to avoid self-hosting; it is a reason to treat certificate management as a first-class operational concern from day one, which is exactly what Part 5 of this series addresses in depth.

There is also the matter of what open-source MDM leaves out that commercial tools include. Neither MicroMDM nor NanoMDM offers location tracking or remote control, a point documented in the AIMultiple 2026 comparison of open-source MDM tools. If your workflow depends on seeing a device’s screen or its physical location, you will need a supplement or a commercial platform. The point is not that open-source is universally better, it is that the trade-offs are specific and knowable, and you should make the decision with your eyes open.

How Long This Takes

A realistic timeline for a first-time self-hoster runs from a long weekend to a couple of weeks, depending on your starting point. Standing up NanoMDM in a Docker container behind a reverse proxy is an afternoon of work if you already understand DNS and TLS. The time sinks are the parts you have not done before: obtaining and renewing the APNs push certificate, standing up a SCEP server for device identity certificates, generating enrollment profiles, and (if you are coming from MicroMDM) re-enrolling every device, since the APNs topic cannot change mid-enrollment. A migration from MicroMDM to NanoMDM is not in-place; it is a phased re-enrollment, typically piloted with a small group before rolling out in waves.

The good news is that the effort front-loads. Once the server is running, the certificates are automated, and the enrollment profile is stable, the ongoing maintenance is modest, backups, monitoring, and the annual certificate renewal. The series is structured to get you there methodically: deploy first, then understand the architecture, then scale, then secure. By the end, you will have a self-hosted Apple MDM stack that you own end to end, with no per-device line item on the invoice and no vendor deciding when a feature ships.

If you are ready to start, the natural next step is Part 2, which walks through installation and the certificate paths that gate everything else. Read it with your Apple developer account details and your DNS provider handy, those two things, more than any code, determine whether your self-hosted MDM gets off the ground.

Sources and References

Sources cited while researching and writing this article:

• Custom iOS MDM Development: The 2026 Build-vs-Buy Playbook
• Top Open Source MDM Solutions in 2026: Honest Review
• MicroMDM v1 project maintenance mode · MicroMDM
• Top 5 Open Source MDM Software – AIMultiple

Series outline