Running an unattended Mac mini fleet: a dedicated worker host, macOS 27 auto-login and deploy settings

Diffio 4.5 restores speech on a fleet of Mac minis (M4 Pro, 24 GB of unified memory). Each mini runs one worker, which can serve our production environment, our dev environment or both. This post covers the host side of that fleet: keeping each mini a dedicated worker host with free disk, logging it in without a person, the permissions set once in System Settings, and the host and deploy settings that keep it serving through reboots, crashes and failed deploys. How the worker overlaps downloads, encoding and uploads with inference is in Mac mini serving: overlapping I/O with inference, not batching, raised throughput.

A fleet mini runs the worker and nothing else

One of our minis had also served as a desktop and a research machine: it ran the ChatGPT desktop app, started at login by a launch agent, Chrome, a research restore process left from a previous day, and its research checkouts. It had 4.4 GB of swap in use; after the cleanup, 0.5 GB. Any desktop working set competes directly with the model and the running jobs.

The worker checks every minute for processes of its user outside macOS and its own folder, launch agents and daemons other than its own and Tailscale's, and active swapping, and reports any it finds as a warning in our analytics.

Desktop software comes back on its own: after a reboot, macOS reopened Chrome from the saved login session, and Chrome reinstalled three Google updater launch agents. defaults write com.apple.loginwindow TALLogoutSavesState -bool false stops apps from reopening at login.

The worker sweeps its work and temporary directories at startup, alerts below 20 GB free without refusing jobs, and deploys keep two releases

Each job writes into its own folder under the worker's work directory, removed when the job completes or fails. A crash or power loss mid-job leaves that folder behind, so the worker empties its work directory when it starts, when nothing can be running. Temporary files escaped that rule: one mini's per-user temporary directory held 14 GB of compiled Core ML models (.mlmodelc directories) left by model builds and research runs.

A release's code is 6.6 MB, but the weights bundle (the checkpoints, the speech-encoder and codec models, and the converted Core ML and MLX copies) is 24 GB, so a deploy keeps only the new release and the previous one, the rollback target, and deletes weight bundles neither uses. Seeding a bundle from a folder already on the mini uses APFS copy-on-write clones (cp -c), which share blocks until a file changes.

Below 20 GB free on the work volume (disk_alert_gb in the worker's configuration) the worker reports a warning to our analytics, and below 5 GB an error, repeated while it lasts; a deploy prints the warning and goes ahead. A job that actually runs out of space fails on its own. The worker used to offer no slots below the threshold, which would have taken a mini out of service with 20 GB still free.

Without a logged-in user, macOS 27's audiomxd and configd together use more than a CPU core

On a mini running macOS 27.0 (26A428) with no console user, audiomxd used 70–74% of a core and configd 45%, from boot onward. Auto-login for the service user provides a console user, and both processes drop to 0% CPU.

A sample of audiomxd shows a tight loop: Bluetooth audio routing (-[BTAudioRoutingRequest updateAudioState:withState:]) tries to start an XPC connection to the console user's session, asks configd for the console user (SCDynamicStoreCopyConsoleUser), finds none, and retries. Its log repeats UpdateAudioState failed to start XPC: kUnexpectedErr (No user logged in). Bluetooth was on, with nothing paired.

On macOS 27, auto-login needs /etc/kcpassword written by hand

sudo sysadminctl -autologin set -userName <user> -password - prints SACSetAutoLoginPassword error:22 even with the correct password, then exits 0. It writes autoLoginUser but not /etc/kcpassword, so the mini still boots to the login window.

#!/usr/bin/env python3
"""Turn on auto-login for USER. Run as: sudo python3 set_autologin.py USER"""
import getpass, os, subprocess, sys

KEY = bytes([0x7D, 0x89, 0x52, 0x23, 0xD2, 0xBC, 0xDD, 0xEA, 0xA3, 0xB9, 0x1F])

user = sys.argv[1]
password = getpass.getpass(f"Password for {user}: ")
if subprocess.run(["dscl", ".", "-authonly", user, password]).returncode != 0:
    sys.exit("wrong password")
data = password.encode() + bytes(12 - len(password.encode()) % 12)  # always at least one terminating zero byte
encoded = bytes(b ^ KEY[i % len(KEY)] for i, b in enumerate(data))
fd = os.open("/etc/kcpassword", os.O_WRONLY | os.O_CREAT | os.O_TRUNC, 0o600)
with os.fdopen(fd, "wb") as f:
    f.write(encoded)
os.chown("/etc/kcpassword", 0, 0)
os.chmod("/etc/kcpassword", 0o600)
subprocess.run(["defaults", "write", "/Library/Preferences/com.apple.loginwindow",
                "autoLoginUser", user], check=True)

After a reboot, stat -f %Su /dev/console prints the service user.

Full disk access over SSH and Screen Sharing are turned on in the Mac's System Settings, not from the command line

Full disk access is a macOS privacy permission (TCC, Transparency, Consent and Control, whose database System Integrity Protection guards), which the command line cannot grant, even with sudo, and Screen Sharing turned on from the command line could not capture the screen. Both are set once in System Settings on the mini when it is set up; full disk access can also come from an MDM profile.

An unattended mini needs host and deploy settings that survive reboots, crashes and failed deploys

Sources

• Diffio Mac mini serving measurements
• Diffio fleet operations, October 21–22, 2026 (not published)
• launchd.plist(5)
• Core ML: Downloading and compiling a model on the user's device
• How to log in automatically to a Mac user account, Apple Support