Skip to content
Back to blog
5 min read

Making a Headless Mac Mini Come Back on Its Own After a Power Cut

  • macos
  • homelab
  • self-hosting

If you run a Mac Mini as a home server (a little M4 box tucked away with no monitor, reachable over SSH or Tailscale), there’s one failure mode that quietly ruins the whole setup: the power blips, the machine shuts off, and it just… sits there. Dark. Your containers are down, your VPN is down, and you don’t find out until you try to reach something and nothing answers.

The fix isn’t one setting. Getting a Mini to recover fully on its own is a chain of three things, and skipping any link leaves you stranded at a different point in the boot. Here’s the whole chain.

Step 1: Power the machine back on

The first link is the easy one. macOS has a setting that powers the machine on automatically when power is restored after an outage.

In the GUI: System Settings → Energy → “Start up automatically after a power failure.” On a desktop Mini there’s no battery section, so it lives right under Energy.

For a headless box it’s cleaner to do it over SSH:

sudo pmset -a autorestart 1

Confirm it took:

pmset -g | grep autorestart

You want to see autorestart 1.

This flag covers exactly the scenario that matters: power was cut, then came back, and the Mini powers itself up. On Apple Silicon Minis, plugging power in after a full shutdown also tends to boot the machine, but autorestart is the setting you actually rely on for outage recovery, so set it explicitly.

So far so good. The box turns on. But if you stop here, you’ll discover it boots straight to a login screen and goes no further. Which brings us to the link almost everyone gets stuck on.

Step 2: Log in automatically, and yes, it’s FileVault

Here’s the thing nobody tells you up front: auto-login cannot work while FileVault is enabled. FileVault encrypts the disk and needs a password at boot to unlock it, so by design macOS can’t log itself in without a human at the keyboard. If your Mini boots but never reaches the desktop, this is almost always why.

Check the status:

fdesetup status

If FileVault is on and you want unattended boot, you have a decision to make. For a home server, disabling it is the common trade: you give up some at-rest encryption in exchange for the machine being able to come back without you. Whether that’s the right call depends on what’s actually on the box. If you decide to turn it off:

sudo fdesetup disable

Decryption runs in the background, so on a large disk give it some time to finish.

With FileVault out of the way, enable auto-login: System Settings → Users & Groups → “Automatically log in as” → pick your user and enter the password. There’s no clean pure-CLI way to set this on modern macOS (it involves writing a kcpassword file correctly), so just use the GUI toggle once over Screen Sharing. You only do it one time.

Verify:

defaults read /Library/Preferences/com.apple.loginwindow autoLoginUser

It should print your username.

Now the machine powers on and lands in a real user session. The last link is getting your actual software to come up, and this is where it pays to be deliberate, because not everything should start the same way.

Step 3: Start your services, the right way for each kind

There’s a mental model that makes this whole part click, and it’ll save you from a fragile setup:

LaunchDaemons for anything that should run without a human logged in. Login Items only for things that genuinely need a GUI session.

A LaunchDaemon starts at boot, before and independent of any login. That’s exactly what a server wants. If you instead lean on auto-login plus login items for everything, then the day a login fails for any reason, all your services go down with it. Daemons survive that. So sort your software into the right bucket.

GUI apps (e.g. OrbStack)

These do need a session, so they belong in login items: System Settings → General → Login Items → Open at Login. OrbStack also ships its own Settings → Start OrbStack at login toggle, which tends to be more reliable than the macOS login item for it specifically, so prefer that one.

Containers

Don’t trust the app alone to bring containers back. Set a restart policy so they recover on their own once the engine is up:

docker update --restart unless-stopped <container>

Or in Compose:

restart: unless-stopped

Now once OrbStack’s engine starts, the containers follow automatically.

Background services (Samba, Syncthing, MiniDLNA, Tailscale, cloudflared)

These should be LaunchDaemons, full stop. They have no business waiting on a GUI login. Tailscale and cloudflared already install themselves as daemons (sudo tailscale up, cloudflared service install), so they’re handled. For NAS pieces that don’t ship a daemon, write a plist in /Library/LaunchDaemons/ with RunAtLoad and KeepAlive set to true, and they’ll come up at boot and stay up.

The whole chain, in order

When all three links are in place, an outage becomes a non-event:

  1. autorestart powers the Mini back on when the lights come back.
  2. Auto-login (with FileVault out of the way) gets you into a real session.
  3. Daemons + restart policies + login items bring your stack back: daemons first at boot, GUI apps on login, containers right behind their engine.

Power blips, the box comes back, everything reconnects, and you never had to touch it. That’s the point of a home server.

The most common place to get stuck is the FileVault/auto-login link. If your Mini powers on but nothing’s reachable, start there before you go debugging individual services.