Six months with a Mac mini M4 as my only server

In November 2025 I moved my production stack off Fly.io and onto a Mac mini M4 sitting on a shelf in my bedroom in Daan District, Taipei. Six months later I have a full dataset: uptime, electricity, every weird edge case. This is the follow-up to the post I wrote the day I made the move. Every number in this post is real. Some of them surprised me.

The experiment was simple: could a base model consumer computer provide reliable, cheap, and predictable infrastructure for my small software projects? The cloud promised scale I did not need and delivered bills I could not predict. I wanted the opposite. I wanted fixed costs and total control, even if it meant a single point of failure I could physically touch. Here is what happened.

Hardware

The total capital expenditure was minimal. I bought everything new from PChome 24h and had it delivered the next day. The goal was not to find the absolute cheapest hardware, but the most convenient and reliable setup I could assemble in an afternoon.

| Item | Cost (NT$) | Cost (US$) | Notes | | -------------------- | ---------- | ---------- | ----------------------------------- | | Mac mini M4 (base) | NT$22,900 | US$740 | 16GB RAM, 512GB SSD | | CyberPower 600VA UPS | NT$1,590 | US$51 | Essential for Taipei's grid quirks | | USB-C Desk Fan | NT$580 | US$19 | Proactive measure for summer | | CAT6 Ethernet Cable | NT$120 | US$4 | 3 meters, direct to router | | Total Capex | NT$25,190 | US$814 | One-time cost, fully depreciated |

The M4 Mac mini is an impressive piece of silicon. The base model's efficiency cores are more than enough for my background agents, and the performance cores handle intermittent heavy loads like local model inference without breaking a sweat. The 16GB of unified memory was a calculated risk. I knew it would be tight, but it has proven sufficient so far. The Uninterruptible Power Supply (UPS) was non-negotiable. It has already saved me from one outage.

Workload

So what is actually running on this machine? It is a mix of my own production agents, development tools, and personal utilities. It is a true multi-purpose server, not a dedicated appliance.

• Conway Automaton loop: A long-running agent that simulates a specific set of Conway's Game of Life rules for a project. It is written in TypeScript, runs on Bun, and maintains a steady state memory usage of about 50MB RSS. It does a burst of computation every 5 seconds.
• OpenClaw Bridge: This is a custom bridge connecting a private Telegram group to a Discord server. It polls, transforms, and forwards messages. Also TypeScript on Bun, it uses around 80MB RSS and has low, spiky CPU usage.
• Postgres 17: A single instance with one primary database. It stores user data and state for my agents. As of today, the entire data directory is only 42MB on disk. It is running via Homebrew services, which has been surprisingly stable.
• Cron Runner: A simple SQLite-backed job scheduler I wrote. It runs 15 scheduled jobs, from daily database backups to hourly API checks. Minimal resource footprint.
• Claude Code Sessions: This is the heaviest workload. When I am working, I often run a local inference server for Claude Opus models to help with coding. This is an intermittent load, but it can spike memory usage to over 2GB and push the CPU to 70% utilization across all cores.
• System Services: On top of my agents, the machine runs a standard macOS Sonoma setup, my personal Helix and tmux session (which is always running), and Syncthing for keeping my files in sync across devices.

The baseline resource usage with all agents running but no active development is remarkably low. The system idles with ~5.4GB of 16GB memory used (including macOS itself) and a CPU load of 3-8%. This leaves plenty of headroom for the heavy inference tasks when I need them.

Uptime

This is the number everyone asks about. How reliable can a consumer machine in an apartment be? The answer is: pretty reliable, if you account for the obvious failure modes. Over the last 172 days, my monitored uptime has been 99.7%.

The downtime was entirely self-inflicted or predictable. There have been zero hardware failures.

| Date | Duration | Reason | Resolution | | ------------ | -------- | -------------------------------------------- | ----------------------------------------------------------------------- | | 2025-11-22 | 12 min | launchd service misconfiguration | Wrapped agent command in caffeinate to prevent sleep; reloaded service. | | 2025-12-04 | 45 min | Planned reboot for macOS 15.2 update | Manual reboot after applying system updates. | | 2026-01-14 | 3h 10m | Building-wide power outage | UPS worked, but I had not configured auto-shutdown/reboot. Fixed. | | 2026-02-08 | 20 min | Scheduled Hetzner failover test | Manually failed over traffic to a cloud VM to test my recovery plan. |

The longest outage was my own fault. On January 14th, our building had a scheduled power maintenance event. The UPS kept the Mac mini online for about 25 minutes, but I had never configured the software to trigger a graceful shutdown when the battery ran low. The machine died ungracefully. I have since configured it to shut down after 15 minutes on battery, which is more than enough to survive the typical Taipei power flicker. The other incidents were minor configuration errors or planned maintenance.

Electricity

The single biggest win of this setup is the power efficiency. Apple Silicon is not a gimmick. I have a Kasa smart plug with power monitoring attached to the Mac mini's power cable, and the numbers are lower than I expected.

• Idle Power Draw: 5.8W (agents running, no active tasks)
• Peak Power Draw: 47W (running a local Claude Opus model for code generation)
• Average Monthly Consumption: ~3.5 kWh

In Taipei, Taipower's residential electricity rates are tiered. My apartment's usage tier averages out to about NT$2.63 per kWh.

This means the Mac mini itself costs NT$9.20 (US$0.30) per month to run.

That number is so low it feels like a rounding error. Of course, the server is not the only thing running. The total "infrastructure" power cost, including my monitor (when on), the internet router, and the UPS's own small draw, comes to about NT$420 (US$13) per month. This is the real, all-in operational cost of my setup. It is a fixed, predictable, and tiny number.

A Note on Heat

The period from November 2025 to April 2026 covers Taipei's winter and spring, which are mild. The real test will be the brutal summer, from June to September. I was concerned about thermal throttling, so I ran a stress test before I fully committed to the setup back in August 2025.

I placed the Mac mini in my non-air-conditioned office and let it run my full workload during a typical August afternoon. The ambient temperature in the room peaked at 34°C.

Under these conditions, the Mac mini's internal temperature, measured with iStat Menus, briefly hit 88°C. I observed minor thermal throttling for about four hours. The most noticeable impact was on my Conway agent's loop latency, which degraded from a p50 of 200ms to 420ms. The machine never became unstable, but the performance hit was real.

My fix was twofold and cost less than US$20. I bought a small aluminum stand to lift the mini off the shelf for better airflow, and I aimed a cheap USB desk fan at its rear exhaust vent. With this setup, even under the same load, the maximum internal temperature I have seen since is 78°C, with no observable throttling.

Network

A server is only as good as its connection to the world. I pay for Chunghwa Telecom's residential fiber plan, which provides a symmetric 500/500 Mbps connection. It has been rock solid. I route all public traffic through a free Cloudflare Tunnel, which provides DDoS protection and a stable IP address, obscuring my home IP. The tunnel adds about 15ms of overhead, a price I am happy to pay.

Here is a look at real-world latency from the Mac mini to various global endpoints.

| Destination | Latency (RTT) | Notes | | -------------------- | ------------- | ----------------------------------------------- | | Tokyo, Japan | 2ms | My closest major cloud region. | | Singapore | 35ms | Key hub for Southeast Asia. | | Ashburn, VA, USA | 178ms | Primary RPC endpoint for the Base blockchain. | | London, UK | 245ms | Location of a CDN I interact with. |

The latency to the US and Europe is significant, but for my use cases, it is not a bottleneck. For example, the p99 latency for a typical API call to one of my agents (/api/ask) is 3.2 seconds. Almost all of that time is spent waiting for a response from a local Claude Opus model, not on the network. The actual network transit time is a tiny fraction of the total request time.

Cost Comparison

So, how does this stack up against the cloud? Before this experiment, I was running a similar workload on Fly.io. A direct comparison is difficult because cloud billing is complex, but we can estimate.

An equivalent setup on Fly.io would require:

• One shared-cpu-2x machine with 4GB RAM and a 100GB disk: ~US$38/month
• A managed Postgres instance: +US$15/month
• Total base cost: US$53/month

Over six months, the paper cost for Fly.io would have been US$318.

My Mac mini setup cost:

• One-time hardware capex: US$814
• Six months of electricity (total infra): 6 * US$13 = US$78
• Total six-month cost: US$892

The break-even point on raw cost is roughly month 12. After the first year, the Mac mini becomes dramatically cheaper.

But this comparison misses the most important point: predictable burn. The real reason I left the cloud was a billing incident where a runaway test process cost me US$200 in four hours. That kind of risk does not exist on my Mac mini. The maximum cost is fixed. The peace of mind that comes from knowing my bill will be US$13 next month, no matter what my code does, is the real prize.

Weird Things That Happened

Running a server in your home is not sterile like a datacenter. Strange, unexpected things occur at the intersection of production software and domestic life.

1. Syncthing vs. Postgres: I use Syncthing to keep my code and documents synchronized. Twice in the first month, Syncthing's conflict resolution process seemed to trigger a crash in my Postgres instance. I eventually realized that Syncthing was trying to sync the pgdata directory while Postgres was performing a checkpoint flush, leading to a race condition. The fix was simple: I added the Postgres data directory to Syncthing's ignore list. I now handle database backups with a separate pg_dump cron job.

2. SSD Wear: I was curious about how the constant writes from Postgres would affect the internal SSD. According to smartmontools, the SSD has processed 3.2TB of writes in six months. This is mostly from Postgres transaction logs. While that sounds like a lot, Apple's consumer SSDs are typically rated for at least 150 TBW (terabytes written). At this rate, the drive should last for decades.

3. The "Server Room" Sound: My landlord, who lives downstairs, asked me one day if I was running a "server room" because he sometimes heard a fan. The Mac mini itself is completely silent. The sound he was hearing was the tiny, high-pitched fan inside the CyberPower UPS, which kicks on occasionally to cool its charging circuit. We had a good laugh about it.

4. Typhoon Resilience: In September, before the official switch but during testing, a typhoon passed near Taipei. My internet connection from Chunghwa went down for 42 minutes. The UPS kept the Mac mini and router powered on. My neighbor runs a small import-export business and has a Starlink dish for emergencies. We have a reciprocity agreement: he can use my fiber if his Starlink is down, and I can use his Starlink if my fiber is down. My Mac mini automatically failed over and stayed online. The traffic was routed through space for almost an hour.

What I Would Change

The setup is not perfect. If I were starting from scratch today, I would make two small changes.

1. More RAM: I would buy the 24GB RAM variant of the Mac mini. 16GB has been sufficient, but I am already close to the limit when running my largest local AI models. The next generation, Claude Opus 4.7, reportedly requires 22GB to run efficiently. I want that headroom for the future.

2. External SSD for Postgres: The internal SSD is fast, but best practice for database performance is to separate the write-ahead log (WAL) I/O from the main data I/O. I would add a small, fast external Thunderbolt SSD dedicated solely to the Postgres WAL and temporary tables. It is a minor optimization, but one that pays dividends in performance and stability over the long term.

What I would not change is the fundamental approach. I would not move back to a cloud VM. The stability, predictability, and raw performance-per-dollar of this local setup is addictive.

Would I Recommend This?

This is the critical question. My answer is a qualified yes.

This setup is likely the right answer for you if:

• Your workloads are relatively steady and fit comfortably under 10GB of memory.
• You value predictable, low costs over burst scalability.
• You are philosophically inclined to own your own infrastructure.
• You live in a location with a stable power grid and reliable, affordable internet.

Do not do this if:

• You need the ability to scale to handle unpredictable traffic spikes. A cloud VM or serverless platform is still the right tool for that job.
• You travel constantly or do not have a stable home base. This setup requires a physical location.
• You live somewhere with an unreliable power grid or expensive internet. The costs and headaches would quickly outweigh the benefits.

Conclusion

The Mac mini is not a special piece of hardware. It is a boring consumer computer running boring consumer macOS, with enough memory and CPU that it can pretend to be a server for one person's small projects. Six months in, it has done everything I asked and cost me the price of two nice dinners in electricity. The cloud has its place. Not in my bedroom.