Forem: Tom Williams

Turning a Mac mini Into a Home Server for Self-Hosted Services

Tom Williams — Sun, 17 May 2026 13:59:41 +0000

The Mac mini is one of the more underrated pieces of homelab hardware you can buy. It's small, near-silent, sips power, and ships with an absurd amount of CPU per watt thanks to Apple Silicon. I've been running mine as a 24/7 home server for a while now, and this post is the writeup I wish I'd had when I started.

Why a Mac mini and not a Raspberry Pi or a NUC?

The honest answer: I already had one sitting on a shelf. But there are a few reasons it turned out to be a great fit:

Performance per watt. An M-series Mac mini will idle around 4–7W and still rip through container workloads that would make a Pi cry.
It's silent. No fans spinning up when Plex transcodes or when a backup job kicks off.
macOS is a real Unix. You get Homebrew, launchd, ZFS via OpenZFS if you really want it, and a familiar shell environment.
It just stays up. Mine has been running for months without a reboot beyond the occasional OS update.

The trade-offs are real though — you're paying Apple prices, you don't get ECC RAM, and storage expansion means hanging things off USB or Thunderbolt. If you need 40TB of spinning rust, build a NAS. For everything else, the Mac mini is excellent.

Initial macOS setup

A few settings to change before anything else:

Disable sleep. In System Settings → Energy:

Prevent automatic sleeping when the display is off: on
Start up automatically after a power failure: on
Wake for network access: on

Enable auto-login so the machine comes back up unattended after a power blip. Yes, this trades some security for uptime — make sure the box lives somewhere physically safe.

Turn on Remote Login (SSH) in System Settings → General → Sharing. While you're there, give the machine a sensible hostname.

Install the command line tools and Homebrew:

xcode-select --install
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

Container runtime: OrbStack

I run almost everything in containers, and on Apple Silicon, OrbStack beats Docker Desktop handily. It's faster to start, uses less RAM, has better filesystem performance, and the networking just works.

brew install --cask orbstack

Set it to start at login and you're done. The docker and docker compose CLIs work exactly as you'd expect.

Reverse proxy: Caddy

For routing traffic to services and handling TLS, Caddy is the path of least resistance. A single Caddyfile and you have automatic HTTPS from Let's Encrypt for every service.

jellyfin.home.example.com {
    reverse_proxy localhost:8096
}

homeassistant.home.example.com {
    reverse_proxy localhost:8123
}

I run Caddy in a container alongside everything else, with the config mounted from ~/srv/caddy/Caddyfile.

Remote access without opening ports: Tailscale

This is the single most important piece of the setup. Do not port-forward your home router to expose services to the internet. Instead, install Tailscale on the Mac mini and on every device you want to reach it from:

brew install --cask tailscale

Now your Mac mini has a stable 100.x.x.x IP that's only reachable by your own devices. Combine it with MagicDNS and you can hit http://mac-mini:8123 from your phone, anywhere in the world, with no firewall changes.

For services I want family members to reach, Tailscale's Funnel feature exposes a single service to the public internet through their edge, with TLS handled for you.

The services I actually run

Here's the current lineup, all in Docker Compose:

Service	What it does
Jellyfin	Media server. Hardware transcoding works on Apple Silicon with the right flags.
Home Assistant	Smart home brain. Runs in a container, talks to Zigbee via a USB stick.
Pi-hole	Network-wide ad blocking. DNS for the whole house points here.
Paperless-ngx	OCR'd document archive. Scan once, search forever.
Vaultwarden	Self-hosted Bitwarden-compatible password manager.
Uptime Kuma	Tells me when something I forgot about has fallen over.
Syncthing	Folder sync across all my machines without going through the cloud.

Each one is a folder in ~/srv/ with its own docker-compose.yml and persistent volumes underneath. Boring, predictable, easy to back up.

Storage and backups

My internal SSD holds the OS, container images, and small databases. For media and bulk data I have a Thunderbolt enclosure with a couple of SSDs in it, mounted at /Volumes/data.

For backups I run two layers:

Time Machine to a separate external drive, for the whole system.
Restic to Backblaze B2 for the irreplaceable stuff — Vaultwarden, Paperless, Home Assistant configs, photos. Encrypted, deduplicated, cheap.

A nightly launchd job kicks off the Restic run and pings a healthcheck URL when it succeeds. If the ping doesn't arrive, Uptime Kuma yells at me.

Monitoring

Nothing fancy: Uptime Kuma for "is the service responding," and Beszel for lightweight host metrics (CPU, RAM, disk, container health). Both run in containers, both have web UIs I can hit over Tailscale.

What I'd do differently

Buy the bigger SSD. Container images, databases, and Time Machine snapshots eat space faster than you think.
Get the Thunderbolt enclosure sooner. USB 3 is fine until you're moving real volumes of data.
Document the compose files in a git repo from day one. Past-me thought he'd remember which env vars he set. Past-me was wrong.

Wrapping up

A Mac mini won't replace a rack of Dell servers, but for a home setup that quietly hosts a dozen useful services and disappears into a shelf, it's hard to beat. The combination of low power draw, silent operation, and a real Unix environment makes it a genuinely lovely machine to run things on.

If you've got one gathering dust, give it a job.

Lessons from Migrating 9TB of File Shares to FSx

Tom Williams — Sun, 22 Mar 2026 14:00:29 +0000

Migrating a Windows file server sounds straightforward until you're staring at 9TB of data across 14 shares and trying to work out what's actually worth moving.

This is what I learned doing exactly that — moving a legacy EC2-hosted Windows file server to FSx for Windows File Server, with a detour through S3 Glacier for the data nobody was using.

Start with discovery, not migration

The temptation is to spin up FSx, robocopy everything across, and call it done. Resist that. You'll end up paying FSx prices for terabytes of data that hasn't been touched in years.

I wrote a PowerShell script to scan every share and classify files by age. This immediately surfaced that a significant portion of the data was cold — files that hadn't been written to in over two years.

The LastAccessTime trap

Here's the gotcha that cost me a day: the server had DisableLastAccess set to 1. This is a common Windows performance optimisation, but it means LastAccessTime is unreliable — it wasn't being updated when files were read.

That left LastWriteTime as the only trustworthy timestamp. It's a reasonable proxy (if nobody's modified a file in two years, it's probably cold), but it's not perfect. A file that's read daily but never edited would appear cold.

The fix: I enabled LastAccessTime tracking early in the project timeline and let it run for a few weeks before the final classification scan. This gave us a more accurate picture before committing to the archival decisions.

Lesson: Check fsutil behavior query DisableLastAccess on day one of any file migration project.

Archive before you migrate

With the data classified, the approach was:

Archive cold data to S3 Glacier (cheap, still retrievable if needed)
Migrate only active data to FSx
Keep the original EC2 instance read-only for a transition period

This significantly reduced the FSx storage footprint and brought the monthly cost down to something sensible.

Things I'd do differently

Automate the archival pipeline end-to-end: I used a semi-manual process with AWS DataSync. Next time I'd script the full workflow including verification and cleanup.
Set up monitoring on FSx from day one: Storage growth on FSx can surprise you. CloudWatch alarms on free storage space are essential.
Communicate the archive process to users early: People get nervous when they hear "we're archiving your files." Setting expectations about retrieval times and the safety net of Glacier avoids unnecessary panic.

Was FSx worth it?

Yes. Automated backups, native AD integration, no more patching a Windows Server instance, and the storage scales without us managing disks. The migration was a few weeks of focused work, but the operational overhead dropped permanently.

Why Event-Driven Infrastructure Beats Cron Jobs

Tom Williams — Sun, 22 Mar 2026 12:51:30 +0000

If you've spent any time managing infrastructure at scale, you've probably written a cron job that polls for something. Maybe it checks for untagged resources every hour, or scans for missing CloudWatch alarms on a schedule. It works. It's simple. And it's almost always the wrong long-term answer.

I recently rebuilt one of these systems — a compliance remediation tool that ensures every EC2 instance in our multi-account AWS organisation has CloudWatch CPU alarms — and the shift from scheduled polling to event-driven architecture made a surprising difference.

The cron approach

The original setup ran a Lambda on a CloudWatch Events schedule every 30 minutes. It would:

Assume a role into each member account
List all EC2 instances
Check for the existence of CloudWatch alarms
Create any that were missing

This worked, but had problems:

Latency: A new instance could run for up to 30 minutes without monitoring
Cost: Every run scanned every instance, even if nothing had changed
Complexity: The Lambda needed to handle pagination across dozens of accounts, manage rate limiting, and deal with partial failures gracefully
Noise: CloudWatch Logs filled up with successful "nothing to do" runs

The event-driven approach

The replacement uses EventBridge rules deployed to each member account via StackSets. When an EC2 instance launches or has its tags modified, the event is forwarded to a central event bus where a Lambda evaluates and applies alarms.

The reconciliation Lambda still exists — it runs daily as a safety net — but it catches edge cases rather than doing the heavy lifting.

What changed

Remediation time: From up to 30 minutes to under 60 seconds
Lambda invocations: Dropped significantly — we only run when something actually happens
Code complexity: The event-driven Lambda handles one instance at a time, not a full cross-account sweep
Terraform: The module became simpler because each component has a single, clear responsibility

When cron still wins

Event-driven isn't always the answer. Use scheduled runs when:

There's no reliable event source for the change you care about
You need a full reconciliation sweep (drift detection, for example)
The event volume would be higher than the polling cost

But for "react when something changes" — which is what most compliance automation is doing — EventBridge is the better tool.

Getting started

If you're currently running a polling Lambda and want to shift:

Identify the AWS API action that triggers the change you care about
Create an EventBridge rule matching that event pattern
Keep your existing Lambda as a daily reconciliation fallback
Deploy the rule to member accounts via StackSets

The two patterns complement each other. Events handle the real-time path, scheduled runs handle the "trust but verify" path.