Running Darkbloom on a headless Mac: no monitor, SSH and automatic login

Updated September 29, 2026

Short answer: a headless Mac can serve Darkbloom, but it needs a user logged in to the Mac’s own desktop session, not just an SSH session. Turn on automatic login, turn off log out when idle, keep it from sleeping, and start the provider from the desktop (Screen Sharing works). Over plain SSH, App Attest can’t verify the Mac and starting the provider can fail. Everything below comes from Darkbloom’s docs and code (links at the end).

Why SSH alone isn’t enough

The provider runs as a LaunchAgent inside your login session (launchd’s gui/<your user id> domain). Darkbloom’s troubleshooting guide says these run only inside a logged-in session.
App Attest, and the Apple push notifications Darkbloom uses to check the provider’s code, work only inside a logged-in desktop session. With nobody logged in, darkbloom doctor says the provider can’t obtain an APNs token or attest.
On macOS 27, a provider started from SSH runs outside the desktop session even when someone is logged in. darkbloom doctor flags this as gui session, and Apple can report App Attest as unsupported (is_supported_false).

Set up the Mac once

Connect a screen, or use Screen Sharing, and log in as the user that runs Darkbloom.
System Settings → Users & Groups → Automatically log in as → choose that user. After a reboot or power cut the Mac then logs back in on its own. macOS doesn’t offer automatic login while FileVault is on.
System Settings → Privacy & Security → Advanced → turn off Log out automatically after inactivity. Screen lock is fine; only logging out stops the provider.
Optional: sudo pmset -a sleep 0, so the Mac never idle-sleeps. The provider keeps the Mac awake while it serves, but deep idle sleep can delay reconnecting and verification.
In Terminal in that desktop session, run darkbloom start (or darkbloom restart).
Run darkbloom doctor and check console session, automatic login, auto-logout on idle and sleep prevention. On macOS 27, also check gui session and launch session.

Managing it remotely

Screen Sharing gives you the real desktop session. Run darkbloom start, darkbloom restart and darkbloom unenroll there.
Over SSH, use the read-only commands: darkbloom status, darkbloom doctor and darkbloom logs --last 1h.
If darkbloom doctor reports gui session after you started the provider over SSH, run darkbloom restart from the desktop.

“launchctl bootstrap failed”

darkbloom start and darkbloom restart load the provider into your desktop login session with launchctl bootstrap gui/<your user id>. The text after “launchctl bootstrap failed:” comes from macOS’s launchctl, and Darkbloom’s docs don’t give a cause for error 5. Providers have seen it on headless Macs and after restarts in September 2026. What the docs do say is that the provider belongs in a logged-in session and should be started from the desktop. So:

Log in at the screen or over Screen Sharing and run darkbloom start in Terminal there.
Check the service: launchctl print gui/$(id -u)/io.darkbloom.provider | head shows whether it is loaded and its last exit status.
Read the logs: tail -50 ~/.darkbloom/provider.log ~/.darkbloom/watchdog.log.
If darkbloom restart says the provider is not running, use darkbloom start.
If it still fails from the desktop, run darkbloom report (add --dry-run to see what it sends first) and ask in the Darkbloom Slack with the report id.

Power cuts

With automatic login on, the Mac logs back in after a power cut and the provider starts with the session. It then has to be verified again before it gets paid work, which can take a while (see verification pending). Some providers use a small UPS so short power cuts don’t restart the Mac at all.

Sources

Provider attestation guide (console session, automatic login): github.com/Layr-Labs/d-inference/blob/master/docs/provider/attestation.md
Troubleshooting (doctor checks, service lifecycle): github.com/Layr-Labs/d-inference/blob/master/docs/provider/troubleshooting.md
CLI reference (LaunchAgent label and paths): github.com/Layr-Labs/d-inference/blob/master/docs/provider/cli-reference.md
Doctor’s session, login and sleep checks: github.com/Layr-Labs/d-inference/blob/master/provider-swift/Sources/ProviderCore/Diagnostics/AttestationReadiness.swift
How the provider is loaded with launchctl: github.com/Layr-Labs/d-inference/blob/master/provider-swift/Sources/ProviderCore/Service/LaunchAgent.swift

How BloomGauge helps

BloomGauge’s optional phone access, private through your own Tailscale tailnet, shows a headless Mac’s earnings and status from your phone, and My Macs puts up to ten Macs in one read-only view.

Download BloomGauge, free for Mac

Questions

Can I run Darkbloom on a Mac without a monitor?

Yes. Log in once at the screen or over Screen Sharing, turn on automatic login, turn off auto-logout, keep the Mac from sleeping and start the provider from that desktop session. After that it can run with no monitor attached.

Why doesn’t Darkbloom work over SSH?

The provider runs inside your desktop login session, and App Attest and Apple push notifications only work there. A provider started over SSH, or a Mac with nobody logged in, can’t be verified, so it gets no paid work. Use Screen Sharing to start or restart it.

What does “launchctl bootstrap failed: 5” mean when I run darkbloom restart?

darkbloom could not load its provider service into your desktop login session. Darkbloom’s docs don’t list a cause for error 5, but they say to start the provider from the logged-in desktop. Log in at the screen or over Screen Sharing, run darkbloom start there and check launchctl print gui/$(id -u)/io.darkbloom.provider.

Updated 2026-09-29. Still stuck? Ask in #bloomgauge on the Darkbloom Slack or contact us. BloomGauge is independent and not affiliated with Darkbloom.