Mac mini Home Server Docker: 7 launchd Jobs, 0 Containers

Every Mac mini home server guide I have read opens the same way: install Docker, then paste a compose file. This Mac mini runs an actual business — a blog with 117 published posts, a click tracker, a revenue ledger, a social poster — and has never had a container on it. Not Docker, not Colima, not Podman, not OrbStack. which docker returns nothing, there is no Dockerfile in the repository, and a recursive grep for docker across every shell, Python and YAML file returns zero hits.

That is a starting condition, not advice. But it left a question I could test rather than argue about: what does a container give you that launchd does not? Three of the four answers were what I expected. The fourth is unfixable at the operating system level, and not for the reason I assumed.

What is actually running

Seven jobs are loaded in the user domain: daily-content, daily-report, daily-revenue, weekly-review, social-planner, social-dispatch, threads-token. The repository holds eight plists — com.mmm.karma is still written but still not installed, the same gap I found during a fleet audit two weeks ago and still have not closed.

Every one has the same ProgramArguments shape: /bin/bash plus a path to a shell script. The host dependency surface underneath is three commands — the scripts invoke python3 four times, claude four times and curl three times. The interpreters are the fragile part: python3 resolves to Homebrew's 3.14.5 while a separate system Python sits at /usr/bin/python3, and /opt/homebrew/bin holds 373 entries that nothing pins.

Counting the plist keys made the isolation question concrete. Across all eight files there are exactly nine distinct keys, and every one is a label, a path, a schedule or a log destination. Zero resource keys, zero isolation keys: no HardResourceLimits, no SoftResourceLimits, no Nice, no ProcessType. The fleet has never asked for a limit of any kind.

The lab: asking launchd for container guarantees

So I asked. I bootstrapped seven throwaway agents into gui/501, each one running a probe that reads its own getrlimit values from inside the process, and declared the limits a container would normally give me.

Requested	plist key	Applied?	Does it bite?
64 open files	NumberOfFiles	Yes, 64/64	Yes — the 61st open() failed with Too many open files
8 processes	NumberOfProcesses	Yes, 8/8	Too well — fork failed at zero
2 CPU seconds	CPU	Yes, 2/2	Yes — killed by SIGXCPU
nice 15	Nice	Yes, nice 15	Yes
background priority	ProcessType	nice stayed 0	Different mechanism, not visible here
128 MiB memory	Data, ResidentSetSize	No — still unlimited	No

The process cap deserves more than a table row. RLIMIT_NPROC on macOS counts processes per user ID, not per job. My login user already owns 317 processes, so a job declaring a limit of 8 starts 39 times over budget and cannot fork even once. As a per-job sandbox it is not strict, it is broken.

The CPU cap behaved exactly like a container limit. A job with CPU set to 2 and a busy loop asking for 20 seconds died, and launchctl print reported last terminating signal = Cputime limit exceeded: 24. Note the field name: when a job dies by signal the last exit code line disappears entirely — the blind spot I catalogued while measuring what launchctl print reports as a job's last exit status.

The memory limit cannot be set at all

The last row is the interesting one. I declared both Data and ResidentSetSize at 128 MiB, then had the job allocate 64 MiB at a time. It sailed through all sixteen chunks, reported a full gibibyte allocated, and exited 0, with empty stderr. plutil -lint was happy, bootstrap returned 0, and launchctl print said nothing was wrong.

My first assumption was that launchd was silently dropping keys it did not like. It is not. Calling setrlimit directly through libc shows the kernel refusing the syscall: RLIMIT_DATA and RLIMIT_RSS both return rc=-1, errno=22, while RLIMIT_NOFILE and RLIMIT_NPROC return 0 from the same loop as controls.

But it is not a blanket refusal either. Sweeping the value showed a floor: 128 MiB rejected, 4 GiB rejected, 1 TiB accepted. A binary search put the smallest accepted memory limit at 452,787,257,344 bytes, or 421.69 GiB — on a machine with 16 GiB of physical RAM. The smallest memory cap this operating system will accept is 26.4 times more memory than the computer has.

The number is not a constant. Three binary searches inside one run returned byte-identical results, but the floor moved about 1.5 MiB between runs. So I measured it against the process's own virtual size, and the two matched exactly: floor 452,787,257,344 against a vsz of 452,787,257,344, a difference of zero bytes. Then I allocated 700 MiB and searched again. vsz grew by 704.0 MiB; the floor grew by 704.0 MiB. Ratio 1.0000 both times.

That is the mechanism: the smallest memory limit you can set is whatever address space the process has already reserved, and a modern Apple silicon process reserves hundreds of gibibytes of it. So the limit fails in both directions. Ask for anything meaningful and the kernel returns EINVAL; set it to the floor and there is zero headroom left, so the next allocation dies. I confirmed the second half accidentally, when a 512 MiB allocation right after a successful floor-setting call raised MemoryError.

Apple's own documentation promises otherwise. man 2 setrlimit on this machine describes RLIMIT_RSS as "the maximum size (in bytes) to which a process's resident set size may grow… This imposes a limit on the amount of physical memory to be given to a process." Its ERRORS section explains EINVAL as "RLIM_INFINITY or lower than rlim_cur", which is not what happened; the address-space floor is not in the page at all. Same species of drift as when the vm_stat swap counters turned out to be an odometer.

What Docker would have cost on this machine

I have never installed Docker here, so this section is documentation and other people's reports, not measurement. Docker's settings reference states that Docker Desktop's memory "defaults to 50% of your host's memory", with a 1 GB swap file. On this 16 GiB Mac mini that is an 8 GiB virtual machine sitting resident, against a measured peak of 373.5 MiB for the largest process my fleet runs — a factor of 21.9. And the jobs are absent most of the time: the scheduler's duty cycle, measured for the home server electricity cost calculator, is 9.65% of wall-clock. A VM does not have a duty cycle.

Nor is the networking the Linux behaviour. Docker documents that host networking on Docker Desktop needs version 4.34 or later, must be switched on in settings, and "works on layer 4… unlike with Docker on Linux, network protocols that operate below TCP or UDP are not supported."

Community reports about the overhead have been consistent for years. In the OrbStack thread on Hacker News, OrbStack's own developer says memory "is allocated on demand, but unfortunately not freed afterwards" — the VM ratchets upward — and elsewhere concedes a user report of "265% CPU usage doing nothing". An Instacart engineer describes moving to remote development environments because of "the horrible performance of Docker Desktop", adding that "even when running containers that do nothing I'd find my CPU was high for no reason". A 2025 write-up carries the same complaint in its title: Docker Desktop at 300% CPU, Colima and Portainer at 0.2%.

The honest ledger

Running zero containers did not buy me isolation. The lab probe listed ~/.ssh, walked ~/Library/Keychains with 1,443 entries, and read ~/Documents, all from inside a launchd job with a working directory of /. Same undefended surface I found testing whether a self-hosted AI agent sandbox actually holds, and the reason I audited which secrets an unattended agent really inherits.

So the real trade is narrower than the guides suggest. What a container would genuinely add here is dependency pinning — two Python interpreters and 373 unpinned Homebrew entries are a real upgrade hazard — plus a memory ceiling the host kernel flatly refuses to provide. That second one matters on a 16 GiB box that already swaps, and it is the strongest argument for containers I found, discovered by trying to do without them. What launchd gives me is fd limits, CPU-second limits, and a scheduler I already understand from comparing launchd against cron on macOS.

I have changed nothing yet. No resource limits are in any of the eight plists as of today, and com.mmm.karma is still uninstalled. If you want the plists, runner scripts and prompts this fleet actually uses, they are in the Playbook.

Sources: the inventory, plist key counts, RSS figures and the seven launchd lab agents were measured on this machine today (macOS 26.4.1 build 25E253, Mac16,10, M4, 16 GB) in the user domain gui/501; LaunchDaemon and root behaviour were not tested, and the floor may differ there. The setrlimit floor was found by binary search and checked against process virtual size in the same run. All seven lab agents were then removed, leaving the seven com.mmm jobs untouched. Docker figures come from the Docker Desktop settings reference, the host network driver docs and the linked Hacker News threads — Docker has never been installed here, so none of those numbers are mine. Reddit's search endpoint refused this client again, so the community evidence is Hacker News only.