Agentic Workforce Company
Agent Infrastructure · Self-Hosted Hardware

I built a self-hosted three-Mac-mini cluster for my agent fleet.

Three Mac minis and a MacBook Pro running local LLMs and an always-on agent fleet — networked over Tailscale and SSH, moved cross-country, and audited back to health. Including an honest attempt at exo distributed inference that hit a real hardware wall. Knowing the limits of your hardware is part of the skill.

IteratedROLE Builder & operatorSCOPE 3 Mac minis + MacBook ProPERIOD 2026 · CA → VA move May
CategoryAgent infrastructure
Hardware3× Mac mini + MacBook Pro
NetworkTailscale · SSH · Thunderbolt
MoveCalifornia → Virginia Beach
StatusIterated · single-node local LLM
The Problem

An always-on fleet needs real hardware it controls.

Cloud tokens aren’t a home. Hardware is.

Self-hosting three Mac minis gives me local inference at zero marginal cost, full control of the runtime, and a private network the agents live on.

The ambition was bigger than running one model per box. I wanted to bridge all three minis and run a single large model across them with distributed inference.

That goal is what pushed me into Thunderbolt bridging and the exo project — and it’s also where I hit a concrete, diagnosable hardware wall. This page is honest about both: what worked and what didn’t.

The Approach

Build the network, attempt the bridge, pivot when it breaks.

Three minis on one network — Tailscale on each, key-based SSH between them, a planned Cloudflare tunnel for external reach.

To attempt distributed inference I bridged the minis with Thunderbolt 4 cables, intending to install exo and run one LLM across all three. That attempt failed for a concrete, diagnosable reason — so I pivoted to running a strong local model on a single node: Qwen 3.5 9B served from LM Studio on Mac mini 3, reachable across the network.

When I moved the cluster cross-country, I brought it back up and ran a read-only health-and-model-drift audit before changing anything — diagnose first, remediate second.

I tried to run one model across all three minis over Thunderbolt. It hit a hardware wall — so the honest outcome is a single-node local model that actually works, not a distributed cluster I can't stand behind.

— Design note · goal vs. achieved outcome
Cluster & Stack

The physical topology.

Three Mac minis and a MacBook Pro on a private Tailscale mesh with key-based SSH. A Thunderbolt 4 line bridge was attempted across the minis. The local model runs on a single node — mini 3 — not distributed across the cluster.

Fig.01 — Self-Hosted Cluster TopologyThree-Mac-mini cluster topology with Tailscale mesh and an attempted Thunderbolt bridgeA MacBook Pro sync node at the top connects over a Tailscale private mesh to three Mac minis: mini 01 running the orchestrator, mini 02 running ops and Hermes workers, and mini 03 hosting local LLMs. The three minis are joined by an attempted Thunderbolt 4 line bridge using two cables with the third connection left unplugged to avoid a bridge loop. A local Qwen 3.5 model served by LM Studio runs on mini 03 only. An exo distributed-inference node is shown in amber dashed outline, labelled attempted but not deployed.MacBook Prohuman-facing sync nodeTAILSCALE · PRIVATE MESH + SSHNODE · mini 01OrchestratorOpenClaw · MCNODE · mini 02Ops · Hermesworker lanesNODE · mini 03Local-LLM hostOllama · LM StudioTHUNDERBOLT 4 · LINE TOPOLOGY (2 CABLES · 3rd UNPLUGGED)RUNS · SINGLE NODEQwen 3.5 9B · LM Studioexo · DISTRIBUTED INFERENCEAttempted & researched — never deployed

A MacBook Pro sync node and three Mac minis sit on a private Tailscale mesh with key-based SSH. The minis were joined by an attempted Thunderbolt 4 line bridge — two cables, third connection left unplugged to avoid a loop. The local Qwen 3.5 model runs on mini 03 only. exo distributed inference was researched and planned but never deployed — distributed inference across all three was the goal, not the outcome.

Hardware

3× Mac miniMacBook ProApple SiliconmacOS 26.x

Networking

Tailscaleed25519 SSHThunderbolt 4 bridgeCloudflare tunnel (planned)

Local LLM Serving

LM StudioOllamaMLX backendQwen 3.5 9Bphi4-mininomic-embed-text

Agent Runtimes

OpenClawHermesjob-lead scoring

Distributed Inference

exo (evaluated)line vs. loop topologyno RDMA support

Ops / Recovery

read-only fleet auditFileVaultTime Machinecron health
Honest Limits

exo: attempted, not deployed.

The honest failure is an asset. It shows real hardware-limit diagnosis and a sound pivot — not a broken promise.

▲ What did NOT happen

Distributed inference across the cluster was never achieved.

exo distributed inference was researched and planned but never installed or run. In the record: “I never was able to get exo set up… I never got to actually set up the software,” confirmed by ops as “exo was not involved. It was not installed / running.” Do not read this page as a working distributed-inference cluster — it isn’t one.

The single physical Thunderbolt-bridge attempt caused a heat event, diagnosed as normal macOS Thunderbolt / Bonjour multicast churn — not a thermal-throttle event (the OS logged ThermalPressure = 0). The hardware does not support RDMA. So the local model ended up running on a single node, and that single-node build is the part that actually works.

Bridge topology
RiskyTriangle3-cable loop → bridge loop
SafeLine2 cables · 3rd unplugged
Heat event (CPU)
Spike~82%mDNS/Bonjour churn
LoggedTP 0no recorded throttling
Inference target
Goal3 nodesone model, distributed
Reality1 nodeQwen 3.5 · verified live
By the Numbers

The facts of the build.

Descriptive facts from the internal record — not performance benchmarks. The cluster's value is control and cost, not throughput claims.

Machines
3+ 1 MBP
three Mac minis + a MacBook Pro sync node
Heat-event CPU
82%
on one node · ThermalPressure logged 0
Post-move audit
0crit / 6 warn
read-only security check after the move
Stale models cleaned
~9.9GB
old Qwen / Ollama models under a legacy account
~1 week
fleet offline during the California → Virginia Beach move; first post-move contact 2026-05-22
2 cables
safe Thunderbolt line topology — leave the third connection unplugged to avoid a bridge loop
6 findings
dead local-Qwen endpoint, inactive Slack gateway, failed crons, FileVault off, no recent backup, model drift
Move & Recovery

Offline, moved, and audited back to health.

~May 11 · Attempt
Thunderbolt bridge & exo attempt

Bridged the minis to try distributed inference. A heat event surfaced on one node, root-caused to macOS Thunderbolt / Bonjour multicast churn — not thermal throttling. Rolled back to the safe line topology.

~May 15–22 · Move
California → Virginia Beach

The whole cluster went offline for about a week and was physically relocated cross-country. First post-move contact landed 2026-05-22.

Post-move · Audit
Read-only health & model-drift check

Before changing anything, a read-only audit caught a dead local-Qwen endpoint, an inactive Slack gateway, failed crons, FileVault off on one node, and no recent Time Machine backup — 0 critical, 6 warnings.

June · Pivot
Single-node local model that works

LM Studio serving Qwen 3.5 9B on mini 3 went live and verifiably scored a synthetic job role in a live test, feeding the Hermes job-lead pipeline. ~9.9 GB of stale models were inventoried and cleaned.

My Role

Hands-on hardware, networking, and honest diagnosis.

I assembled the cluster, networked it, physically moved it across the country, and audited it back to health.

I attempted the exo distributed-inference build, diagnosed why the Thunderbolt bridge overheated, and made the call to pivot to a single-node local model. After the move I directed the read-only audit and the remediation — dead endpoints, FileVault, backups, model drift. This is real infrastructure work: hardware, networking, local model serving, and honest failure diagnosis. Knowing the limits of the hardware is part of the skill.

Skills Demonstrated

What this took.

Self-hosted AI infrastructure (Apple Silicon)Local-LLM serving (Ollama, LM Studio, MLX)Private-network design (Tailscale, SSH)Thunderbolt bridgingDistributed-inference evaluation (exo)Hardware-constraint diagnosis (Bonjour, RDMA, thermal)Disaster recovery / post-move fleet auditSecurity hygiene (FileVault, backups, cron health)Honest failure diagnosis

Want an operator who knows the limits of the hardware — and says so?