The sales pipeline would die at 10pm every few nights and I wouldn't find out until morning.
I'd wake up, check Telegram, and there'd be nothing, no briefing, no prospect batch, no outreach drafts. Just silence. Then I'd SSH in and find the same scene: auth failure in the logs, swap exhausted, token rotation script had run mid-pipeline and killed everything.
This was my AI agent infrastructure on Hetzner. 4GB RAM, shared CPU, and a rotating API key system that sounded clever until it wasn't.
I spent weeks fighting it. Added retry logic. Tuned the swap. Wrote better error handling. Fixed the token rotation timing so it wouldn't collide with pipeline runs. And every fix worked, until it didn't.
At some point I had to ask myself an honest question: am I building an AI business team, or am I maintaining a server?
What Was Actually Breaking
The VPS setup wasn't unreasonable. 4GB RAM for a handful of agents, scheduled via cron, running on Hetzner's cheapest tier. On paper it should've been fine.
The reality was messier.
The auth failures came from a quirk in how the token rotation script handled concurrent sessions. If an agent was mid-run when the token flipped, that agent was running with a stale key. It would fail. The next cron run would try to spin up a new agent, which would also hit something stale or locked. By the time the dust settled, the whole pipeline had bailed out and logged an error nobody saw until morning.
The swap exhaustion was simpler, just a RAM problem. Running Prospector, Scorer, Researcher, and Outreach Writer sequentially meant each one was loading context, doing web research, writing files, and exiting. Sequential, not parallel. But each one still needed enough headroom to actually run. 4GB, split with the OS and the gateway process and any stale session cleanup, wasn't it. The system would hit swap, slow to a crawl, and timeout.
The token rotation breaking pipelines was the one that annoyed me most because it was my own design failing. I built the rotation to keep API keys fresh. It worked perfectly in isolation. Combined with a running pipeline, it was a landmine.
Three failure modes. All three solvable. All three requiring time I didn't want to spend.
The Decision
I have a Mac Mini M4 sitting on my desk. 24GB unified memory. ARM architecture. Runs silent. Pulls maybe 10-12W at idle.
I'd been using it for other things and had avoided turning it into the agent host because it felt like overkill, or maybe like giving up on the VPS. Like admitting the cheap server approach wasn't going to work.
It wasn't going to work.
The moment I reframed it, this isn't overkill, this is right-sizing, the decision was obvious. The Mac Mini isn't my server. It's my infrastructure. There's a difference. A server you fight with is not infrastructure. It's a hobby project disguised as a business tool.
I needed something that ran the pipeline, didn't require me to babysit it, and didn't eat my morning trying to figure out what broke overnight.
What the Migration Actually Looked Like
I'm not going to pretend this was a 20-minute process. It took a weekend.
The OpenClaw gateway moved first. That was straightforward, install, configure, point it at the right API keys. The gateway is what manages agent routing, session handling, and cron jobs. Getting that running clean on macOS took a couple hours mostly because I was being careful about key management this time. No rotation scripts. Keys live in the gateway config. They don't rotate mid-pipeline.
Then the 6 agents. Each one has its own instructions file, voice profile, and output format. Moving them was mostly copying files and verifying the paths were right. The agents themselves are stateless, they read from workspace, write to workspace, exit. No persistent process to migrate.
The cron schedule is what makes the whole thing work. Three fixed jobs:
- 10pm: Sales pipeline kicks off. Prospector finds businesses matching ICP, Scorer ranks them, Researcher digs up decision-maker info, Outreach drafts personalized emails and LinkedIn DMs.
- 7am: Morning briefing. Pipeline status, content queue, weather, a manifesto principle, one clear action for the day.
- Monday, Wednesday, Friday at 2pm: Content Creator drafts LinkedIn and X posts for the week's pillar.
On the VPS, those crons were dice rolls. On the Mac Mini, they run. That's the whole difference.
24GB Changes Things
I didn't fully appreciate this until I started running the pipeline and watching memory usage.
The Prospector agent doing real web research on 15-20 companies, writing structured output, handling retries, it uses real memory. The Scorer reading that output and running each prospect through the rubric, more memory. By the time Outreach is drafting personalized messages with company-specific details and links, you want headroom.
On the VPS, that headroom didn't exist without hitting swap. On the Mac Mini, the whole pipeline runs with 6GB used and 18GB free. The agents finish faster. They don't timeout. The output quality is better because the model isn't being starved of context mid-run.
The auth problem is gone because there's no rotation. One key, stored properly, lives in the config. The pipeline doesn't race against a rotation script because there is no rotation script.
What It Looks Like Now
Every morning around 7, Telegram gets a briefing. Pipeline status from the night before, how many prospects, outreach drafts ready, any issues. Content queue. One action for the day.
Every night at 10, the sales pipeline runs. While I'm asleep, 6 agents are working in sequence. By morning there's a batch ready for review.
Three times a week, content drafts land in Telegram. I approve them, spend 30 seconds copy-pasting to LinkedIn and X.
The system has been running clean for a few weeks now. No auth failures. No swap exhaustion. No pipelines dying mid-run and waiting silently for me to notice.
That's what I wanted when I started this. Not a server to maintain, an infrastructure that runs.
The Honest Takeaway
I held onto the VPS longer than I should've because switching felt like admitting the approach didn't work. It didn't work. The Mac Mini costs more upfront and nothing monthly. The VPS cost less upfront and my time every few days.
If you're building anything that needs to run while you're not watching it, reliability is the whole thing. Not features. Not clever architecture. Does it run when I'm not there? That's the question.
My answer is yes now. It wasn't before.