Running OpenClaw on a Mac Mini 24/7 — My Setup and Monthly Cost

Why Your Laptop Isn’t Good Enough

I ran OpenClaw on my MacBook Pro for about three weeks before I got burned. I had a DCA strategy buying ETH every 6 hours and a simple grid bot on BTC/USDT. Worked great — until it didn’t.

What happened: I closed my laptop to go to lunch. macOS went to sleep. OpenClaw’s daemon stopped. My scheduled 2 PM buy never executed. The grid bot missed a rebalance during a 4% dip that would have been profitable.

I didn’t realize any of this until I checked that evening. No error, no notification — because the process that sends notifications was also asleep.

This isn’t an OpenClaw problem. It’s a physics problem. Laptops sleep. Lids close. Wi-Fi disconnects when you walk out of range. If you’re running any kind of scheduled trading strategy, you need a machine that stays on 24/7.

Your options are:

1. A cloud VPS (DigitalOcean, Hetzner, AWS)
2. A dedicated always-on machine at home
3. An old laptop you never close

I went with option 2 — a Mac Mini. Here’s why, and exactly how I set it up.

Why a Mac Mini Specifically

The Mac Mini comes up constantly in the OpenClaw community, and after running one for a month I understand why:

Apple Silicon is absurdly power-efficient. My M2 Mac Mini idles at about 5-7 watts. For comparison, a typical Intel NUC idles at 15-25W, and even a Raspberry Pi 5 sits around 5-8W under light load. The Mac Mini gives you a full desktop OS at nearly Raspberry Pi power consumption.

macOS “just works” for OpenClaw. No driver headaches, no dependency nightmares. The install script runs clean. Node.js on ARM64 macOS is well-supported. I’ve had zero compatibility issues in 30 days.

It’s silent. The M2 Mac Mini has no fan noise at idle. My office is dead quiet. If you’re putting this on a desk or shelf, you’ll forget it’s there.

Resale value. If I decide this whole thing was a bad idea in six months, I can sell the Mac Mini for 75-80% of what I paid. Try doing that with a used VPS.

That said, a Mac Mini is overkill for just running OpenClaw. I’ll cover the VPS alternative at the end for people who don’t want to spend the upfront cost.

My Hardware

Here’s exactly what I bought:

Total upfront: ~$479

Some notes on these choices:

• 8GB RAM is enough. OpenClaw’s daemon uses about 200-400MB of RAM. Node.js and the LLM API calls are not memory-intensive because the actual inference happens on the API provider’s servers (Claude, GPT, etc.), not locally. If you’re also running other services, get 16GB.
• 256GB storage is plenty. OpenClaw itself is tiny. Trade logs, even after months, are small CSV files. You’d need more storage only if you’re running a local LLM (which is a different setup entirely).
• Ethernet, not Wi-Fi. Wi-Fi drops happen. For a trading bot, a dropped connection at the wrong moment means a missed or stuck order. I hardwired it to my router and haven’t touched Wi-Fi.
• UPS is optional but recommended. A $55 battery backup gives me about 20 minutes of runtime during a power outage — enough for the Mac Mini to ride out a brief flicker or for me to get a notification and shut down gracefully. If you live somewhere with stable power, skip it.

macOS Configuration: Preventing Sleep

This is the part that most “run a server on Mac” guides get wrong. There are multiple places macOS can decide to sleep, and you need to disable all of them.

Step 1: System Settings

Go to System Settings > Energy (on older macOS versions, this is “Energy Saver”):

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

That last one is important. If the power goes out and comes back, you want the Mac Mini to boot itself without you pressing the button.

Step 2: Disable sleep via Terminal

Open Terminal and run:

sudo pmset -a sleep 0
sudo pmset -a disksleep 0
sudo pmset -a displaysleep 5
sudo pmset -a hibernatemode 0

This sets:

• System sleep: never
• Disk sleep: never
• Display sleep: 5 minutes (saves energy, doesn’t affect processes)
• Hibernate: disabled

Verify your settings:

pmset -g

You should see sleep 0 and disksleep 0 in the output.

Step 3: Enable auto-login

Go to System Settings > Users & Groups > Login Options (you may need to click the lock icon to make changes):

• Set Automatic login to your user account

This means after a power failure and reboot, the Mac Mini logs into your account without waiting for a password. Yes, this is a security trade-off. If someone physically steals the Mac Mini, they have access to your account. For a box sitting on a shelf in your home, I think the trade-off is worth it. If you disagree, skip this and use the remote access setup below to manually log in after reboots.

FileVault warning: If you have FileVault (disk encryption) enabled, auto-login won’t work. You’ll need to either disable FileVault or accept that you need to manually enter your password after a reboot. I disabled FileVault on this machine since it’s a dedicated bot runner, not my personal computer.

Step 4: Disable software updates auto-restart

macOS loves to install updates and restart at 3 AM. For a trading bot, this is a disaster.

sudo defaults write /Library/Preferences/com.apple.SoftwareUpdate AutomaticDownload -bool false
sudo defaults write /Library/Preferences/com.apple.SoftwareUpdate AutomaticallyInstallMacOSUpdates -bool false

You should still update macOS manually on a regular schedule — just do it on a weekend when you can supervise the process.

Installing OpenClaw as a Persistent Daemon

If you already have OpenClaw installed, skip to the daemon configuration. If not:

curl -fsSL https://openclaw.ai/install.sh | bash

Follow the onboarding wizard. Once OpenClaw is installed, you need to make it start automatically on boot and restart itself if it crashes.

Create a launchd plist

macOS uses launchd for managing daemons (like systemd on Linux). Create this file:

mkdir -p ~/Library/LaunchAgents
nano ~/Library/LaunchAgents/com.openclaw.daemon.plist

Paste this content:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
  "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>com.openclaw.daemon</string>

    <key>ProgramArguments</key>
    <array>
        <string>/usr/local/bin/openclaw</string>
        <string>gateway</string>
        <string>start</string>
    </array>

    <key>RunAtLoad</key>
    <true/>

    <key>KeepAlive</key>
    <true/>

    <key>StandardOutPath</key>
    <string>/tmp/openclaw-stdout.log</string>

    <key>StandardErrorPath</key>
    <string>/tmp/openclaw-stderr.log</string>

    <key>EnvironmentVariables</key>
    <dict>
        <key>PATH</key>
        <string>/usr/local/bin:/usr/bin:/bin:/opt/homebrew/bin</string>
    </dict>
</dict>
</plist>

Important: Check where your OpenClaw binary actually lives by running which openclaw. If it’s /opt/homebrew/bin/openclaw instead of /usr/local/bin/openclaw, update the path in the plist accordingly.

Load the daemon:

launchctl load ~/Library/LaunchAgents/com.openclaw.daemon.plist

Verify it’s running:

launchctl list | grep openclaw
openclaw gateway status

Now OpenClaw will:

• Start automatically when you log in
• Restart itself if it crashes (KeepAlive is set to true)
• Log stdout and stderr to /tmp/ so you can debug issues

Test the setup

Reboot your Mac Mini to confirm everything works end-to-end:

sudo reboot

After it comes back up, SSH in (we’ll set that up next) and verify:

openclaw gateway status

If you see the gateway running, your always-on setup is complete.

Setting Up Remote Access

The Mac Mini is headless now — no monitor, no keyboard. You need ways to reach it.

Option 1: SSH (for terminal access)

Enable SSH in System Settings > General > Sharing > Remote Login. Turn it on and note your local IP.

Test from another machine on your network:

ssh yourusername@192.168.1.xxx

Option 2: Screen Sharing (for GUI access)

Enable in System Settings > General > Sharing > Screen Sharing. You can then connect from any Mac using Finder > Go > Connect to Server > vnc://192.168.1.xxx.

Option 3: Tailscale (for access from anywhere)

This is the one I actually use day to day. Tailscale creates a private VPN between your devices — your phone, your laptop, and the Mac Mini all get static IPs on a private network.

# Install Tailscale on the Mac Mini
brew install tailscale

Open the Tailscale app, sign in, and it assigns your Mac Mini an IP like 100.x.y.z. Now you can SSH into it from anywhere in the world:

ssh yourusername@100.x.y.z

No port forwarding, no dynamic DNS, no exposing your home network. I’ve been using Tailscale for a month and it’s been rock solid. I can check on my bot from a coffee shop or from my phone.

Why not just port-forward SSH? You can, but it exposes port 22 to the internet. Bots will find it and hammer it with brute-force login attempts within hours. Tailscale is simpler and more secure.

Connecting Telegram as Your Control Channel

This is the part that made the whole setup feel “complete” for me. With Telegram connected, I manage OpenClaw from my phone. No SSH, no dashboard — just text messages.

Step 1: Create a Telegram bot

1. Open Telegram and search for @BotFather
2. Send /newbot
3. Name it something like “My OpenClaw Bot”
4. BotFather gives you a token like 7123456789:AAH... — save this

Step 2: Get your Telegram user ID

Search for @userinfobot in Telegram and send it any message. It’ll reply with your numeric user ID (something like 123456789).

Step 3: Configure OpenClaw

Add these to your OpenClaw environment config (usually ~/.openclaw/.env):

TELEGRAM_BOT_TOKEN=7123456789:AAHxxxxxxxxxxxxxxxxxxxxxxxxx
TELEGRAM_ALLOWED_USERS=123456789

The TELEGRAM_ALLOWED_USERS field is critical — it ensures only you can send commands to the bot. Without it, anyone who finds your bot’s username could control your trading.

Step 4: Restart the daemon

launchctl unload ~/Library/LaunchAgents/com.openclaw.daemon.plist
launchctl load ~/Library/LaunchAgents/com.openclaw.daemon.plist

Now open Telegram and message your bot. Try:

What strategies are currently running?

If it responds, you’re connected. From here, you can do everything through Telegram: start strategies, check status, pause bots, view trade history. I do about 90% of my OpenClaw interaction through Telegram now.

Monthly Cost Breakdown

Here’s what this setup actually costs me per month, after running it for 30 days:

The LLM API cost surprised me. I expected it to be higher, but most OpenClaw operations (checking price, placing an order) are short conversations. The LLM is only called when OpenClaw needs to interpret a command or make a decision. Routine scheduled buys barely use any tokens after the initial setup.

My DCA strategies cost about $3/month in API fees. If you’re running more complex strategies that involve LLM reasoning on every trade (like sentiment analysis), expect $8-15/month.

Alternative: Running on a VPS

If $419 upfront sounds like a lot, a cloud VPS is a perfectly valid alternative. Here’s how the two options compare:

My honest take: If you’re just running a DCA bot and nothing else, a $6/month Hetzner VPS is probably the smarter financial choice. You’ll spend less over the first two years and get better uptime.

I chose the Mac Mini because:

1. I already wanted one for other projects
2. I don’t love having exchange API keys on a server I don’t physically control
3. I run three OpenClaw instances with different strategies, and the M2 handles all of them without breaking a sweat

If you go the VPS route, the OpenClaw setup is the same — just use systemd instead of launchd for the daemon, and skip the macOS sleep prevention steps.

Quick VPS setup (DigitalOcean)

# On a fresh Ubuntu 24.04 droplet
curl -fsSL https://deb.nodesource.com/setup_22.x | sudo -E bash -
sudo apt-get install -y nodejs

# Install OpenClaw
curl -fsSL https://openclaw.ai/install.sh | bash

# Create a systemd service
sudo tee /etc/systemd/system/openclaw.service > /dev/null <<EOF
[Unit]
Description=OpenClaw Gateway
After=network.target

[Service]
Type=simple
User=$USER
ExecStart=/usr/local/bin/openclaw gateway start
Restart=always
RestartSec=10
Environment=PATH=/usr/local/bin:/usr/bin:/bin

[Install]
WantedBy=multi-user.target
EOF

sudo systemctl enable openclaw
sudo systemctl start openclaw

Monitoring: Knowing When Things Break

Running a trading bot 24/7 means you need to know when it stops working. Here’s what I set up:

Telegram heartbeat

I asked OpenClaw to send me a daily health check:

Every day at 8 AM UTC, send me a Telegram message with:
- Current gateway status
- Number of active strategies
- Last trade executed (time and details)
- Current exchange connection status

If I don’t get this message by 8:05 AM, something is wrong.

Simple uptime check script

I also run a basic cron job that pings the OpenClaw gateway and alerts me if it’s down:

# Add to crontab: crontab -e
*/5 * * * * curl -sf http://127.0.0.1:18789/health > /dev/null || \
  curl -s -X POST "https://api.telegram.org/bot<YOUR_BOT_TOKEN>/sendMessage" \
  -d "chat_id=<YOUR_USER_ID>&text=OpenClaw gateway is DOWN"

This checks every 5 minutes. If the health endpoint doesn’t respond, it sends me a Telegram alert directly (bypassing OpenClaw, since OpenClaw is the thing that’s down).

What I’ve seen go wrong

In 30 days of running, I had:

1. One crash due to an OOM kill — I was running a memory-hungry backtest alongside the live strategies and macOS killed the OpenClaw process. The KeepAlive in launchd restarted it within 10 seconds. I missed nothing, but I got a scare. Lesson: don’t run backtests on the same machine as live trading.

2. One internet outage (45 minutes) — My ISP had a brief outage at 2 AM. OpenClaw couldn’t reach the exchange API, logged errors, and retried when the connection came back. No missed trades because nothing was scheduled during that window. Luck, not skill.

3. Zero macOS-related issues — No surprise restarts, no sleep events, no kernel panics. The Mac Mini just sits there and runs.

My Uptime After 30 Days

After one month of running this setup:

• Uptime: 99.7% (the 0.3% was the ISP outage and one manual reboot for a macOS update I chose to install)
• Trades executed: 127 out of 128 scheduled (one missed during the backtest OOM incident, but it auto-recovered on the next cycle)
• Total power consumption: ~5.2 kWh (measured with a Kill-A-Watt meter)
• Total LLM API cost: $6.42 (across three strategies)

I’m happy with this setup. It’s not perfect — a data center VPS would give me better uptime numbers — but it’s quiet, it’s in my house, and I can physically unplug it if something goes catastrophically wrong. There’s a psychological comfort in that.

Lessons Learned

Things I got right:

• Hardwired ethernet from day one. Zero dropped connections.
• UPS paid for itself during a 3-second power flicker that would have rebooted the machine.
• Tailscale for remote access. I literally set it up once and forgot about it.

Things I got wrong:

• I initially ran OpenClaw without the launchd daemon. Just had a Terminal window open with the process running. When the screen saver kicked in and macOS aggressively managed background processes, it caused intermittent slowdowns. The launchd approach is much more reliable.
• I didn’t set up monitoring until week two. For the first two weeks I was just… hoping it was still running. Don’t be like me. Set up the heartbeat on day one.
• I over-complicated the initial setup by trying to run OpenClaw inside a Docker container on macOS. It works, but it adds complexity for no real benefit on a dedicated machine. Docker makes more sense on a shared VPS.

What I’d add next:

• An external uptime monitor (like UptimeRobot hitting a health endpoint exposed via Tailscale) for redundancy
• Automated daily backups of my OpenClaw config and trade logs to iCloud or a Git repo
• A second Mac Mini at a friend’s house for geographic redundancy (overkill, but I think about it)

Next Steps

• New to OpenClaw? Start with our BTC DCA strategy tutorial to set up your first bot
• Want to add more strategies? Check out the OpenClaw trading skills guide for extending capabilities
• Running on Linux instead? The VPS section above covers the basics — the systemd service config is all you need to adapt