In a previous post, I tried to run an Apple MDM stack on ARM-only hardware. NanoMDM ran, MicroMDM wouldn’t - no arm64 image and no cross-compile path I wanted to maintain. The project paused. I said I’d revisit it with x86 hardware.

I now have a Proxmox cluster with x86 nodes. The architecture barrier is gone. So I went back and did the evaluation properly.

Architecture wasn’t the real problem.

What changed

On ARM, the blocker was MicroMDM: no arm64 image, no easy cross-compile path worth maintaining. NanoMDM ran but requires more manual ceremony. The MDM stack as a whole was too painful to assemble on that hardware.

With x86 Proxmox, both images run. Docker deployment is straightforward. Traefik handles TLS. The plumbing that took a week to coax onto ARM snapped together in an afternoon.

The technical barrier is gone. That’s when I found the actual problem.

The enrollment problem

Apple’s MDM system has two fundamentally different enrollment modes, and which one you get depends on who owns the device.

Device Enrollment Program (DEP) is what organizations use. Devices are registered in Apple Business Manager (ABM) or Apple School Manager. When someone turns on a new device, it enrolls in MDM automatically before setup even starts. The MDM server has full control: Supervised mode, silent app installation, remote wipe, enforced policies the user can’t override.

User Enrollment is what personal devices get. It was introduced in iOS 13 to let people use a personal iPhone for work without handing over full device management. The MDM only manages a separate “managed” data container.

I don’t have Apple Business Manager. ABM requires a DUNS number and a business relationship with Apple. It’s designed for organizations, not personal homelabs.

Which means every device I own uses User Enrollment.

What User Enrollment actually lets you do

Not much. With User Enrollment, an MDM server can:

• Install managed apps (App Store only, not enterprise-signed)
• Push Wi-Fi, per-app VPN, and email profiles
• Manage certificates
• Wipe the managed data partition (not the whole device)

What it cannot do:

• Enforce Supervised mode policies (app restrictions, screen time overrides at OS level)
• Remotely wipe the full device
• See the complete installed app list
• Push configuration profiles silently
• Lock the device or force a passcode change
• Install apps without the user explicitly allowing each one

The features that make MDM compelling for IT departments - the ones I actually wanted - all require Supervised mode, which requires DEP, which requires ABM, which requires being a business.

The cost-benefit math

Getting a self-hosted MDM stack to the point of actually enrolling a device takes somewhere between 8 and 16 hours. You need to provision an Apple MDM push certificate (renews annually), set up a SCEP server or internal CA for device certificates, configure the MDM server, expose it behind a reverse proxy, and actually run through enrollment. That’s the setup cost alone.

Ongoing maintenance runs 2-4 hours a month: APNs certificate renewal, MDM server updates, dealing with breakage when iOS updates change enrollment behavior.

In exchange, you get Wi-Fi profiles and managed apps - both of which I can already push with Apple Configurator 2.

What actually works

Apple Configurator 2 handles the practical use cases. Connect a device via USB, push a profile, done. It’s free (Mac App Store download), doesn’t require a server. I use it for DNS-over-HTTPS profiles and the occasional VPN config.

iCloud covers shared settings across devices. iCloud Keychain syncs credentials, iCloud Drive handles files. For home use, this gets most of the “consistency across devices” benefit with no infrastructure.

Manual configuration is fine for the rest. I have around ten Apple devices. Running through setup manually takes a couple of hours - cheaper than building and maintaining a server that mostly duplicates what I can do with a USB cable.

When MDM makes sense

For organizations, MDM is worth every hour of setup. Zero-touch enrollment, fleet-wide policy enforcement, remote wipe for lost devices - none of that is achievable any other way. If you’re managing devices for a team, ABM plus supervised MDM is the right call.

For personal homelabs, it only makes sense if you have Apple Business Manager access (some sole proprietors do qualify), a device count large enough that manual management is genuinely painful, and a specific use case that User Enrollment actually covers.

I have none of those.

Lessons

Architecture was the easy problem. Months of thinking x86 hardware would unblock this project. When I finally did the evaluation with the right hardware, I found the ARM issues had been covering up a more fundamental mismatch: self-hosted MDM is designed for institutional device ownership, not personal use.

Read the enrollment docs before building the stack. Apple’s MDM documentation is clear on what User Enrollment can and can’t do. I should have read it at the start. Instead I worked through the full deployment and hit the limitations at enrollment time.

Apple Configurator 2 is underrated. Free, no server, handles profiles and supervised setup over USB, and integrates with ABM if you eventually get access. For personal use it covers most of what a self-hosted MDM would deliver - without the maintenance overhead.