Pre-deployment checks: Node version and permission model
Pin the runtime before you harden anything else. OpenClaw’s gateway and CLI stacks assume a current Node LTS line (teams standardized on Node 22+ in 2026). On the remote Mac, verify with node -v and npm -v, and install via nvm or the official pkg so upgrades are repeatable.
Create a dedicated macOS user (for example openclawsvc) that owns the install directory and log paths. Avoid running the gateway as an admin account with passwordless sudo; that turns a single leaked token into full disk access. Check effective ownership:
id openclawsvc ls -la ~/openclaw-gateway chmod 750 ~/openclaw-gateway chmod 600 ~/openclaw-gateway/.env.gateway
Grant macOS privacy permissions only where required. If a skill shells out to automation tools, document which TCC prompts appear; do not blanket-enable Full Disk Access “to save time.” For launchd services, use UserName in the plist to drop privileges explicitly.
Gateway token and access control: reproducible configuration steps
Your first control plane decision is network exposure. Bind the gateway to loopback and put a reverse proxy in front, or bind to a private interface only. A typical safe pattern on remote Mac is: OpenClaw listens on 127.0.0.1:PORT; Caddy or nginx terminates TLS and forwards to that port with optional IP allowlisting.
Enable bearer-token authentication on the gateway path your CI and clients use. Store the token in .env.gateway (mode 600) and reference it from launchd:
export OPENCLAW_GATEWAY_TOKEN="$(openssl rand -hex 32)" # launchd EnvironmentVariables block: # OPENCLAW_GATEWAY_TOKEN = <value from secrets store>
When calling the gateway from GitHub Actions or another CI system, inject the token via encrypted secrets—never echo it in workflow logs. Add a CI guard step that fails if grep -R "OPENCLAW_GATEWAY_TOKEN" . would match plaintext in tracked files.
Illustrative openclaw.json fragment (adjust keys to your installed OpenClaw version):
{
"gateway": {
"listen": { "host": "127.0.0.1", "port": 18765 },
"auth": { "mode": "bearer", "header": "Authorization" },
"rateLimit": { "perMinute": 120 }
}
}
Pair bearer auth with VPN-only or SSH port-forward (ssh -L 18765:127.0.0.1:18765 user@remote-mac) and default-deny firewall rules.
Outbound domain allowlist and proxy policy checklist
Agents are SSRF amplifiers if every skill can fetch arbitrary URLs. Start from a written allowlist of hosts your jobs actually need, then enforce it in layers.
| Category | Example hosts (trim to your stack) | Notes |
|---|---|---|
| Model / inference APIs | api.openai.com, api.anthropic.com, regional endpoints you use | Pin API base URLs in config; block wildcards. |
| Package registries | registry.npmjs.org, github.com, objects.githubusercontent.com | Required for install and ClawHub-style pulls. |
| ML artifacts | huggingface.co, cdn-lfs.huggingface.co | Add only if you pull models at runtime. |
| Internal services | Private registry hostnames | List in NO_PROXY so they bypass the corporate proxy. |
Set proxy variables once for the service account shell and launchd environment:
export HTTPS_PROXY="http://proxy.corp.example:8080" export NO_PROXY="127.0.0.1,localhost,.internal.corp,artifacts.internal"
Without a central proxy, combine macOS firewall allow rules with versioned skills so outbound changes are reviewed.
Log auditing and alert thresholds
Structured logs beat screenshots. Redirect gateway stdout/stderr to dated files under /var/log/openclaw/ (owned by the service user) or use launchd StandardOutPath / StandardErrorPath. Rotate with newsyslog or a small logrotate config so disks do not fill during model pulls.
Minimum viable monitoring on a remote Mac node:
- 401/403 rate: alert if more than N failed auth attempts per minute from a single IP (N often 10–30 after baseline).
- New outbound hosts: daily digest of DNS names not seen in the prior 7 days.
- Error budget: sustained
ECONNRESET/ TLS handshake errors above 5% of requests for 10 minutes. - Quota signals: API 429 responses correlated with gateway user-agent—often the first sign of a leaked token.
Forward logs to a SIEM when you can; otherwise cron + grep -E "401|403|EACCES|certificate|handshake" beats silent failure.
Common errors: ports, TLS, and permissions
| Symptom | What to run / check |
|---|---|
EADDRINUSE on gateway port | lsof -nP -iTCP:18765 -sTCP:LISTEN then stop the stale process or change openclaw.json port consistently in proxy config. |
TLS UNABLE_TO_VERIFY_LEAF_SIGNATURE | Corporate MITM: install root on the Mac keychain or set NODE_EXTRA_CA_CERTS=/path/to/corp.pem for the service user only. |
| Clients get connection reset externally | Confirm proxy proxy_read_timeout exceeds long model streams; verify firewall allows return traffic on established connections. |
EACCES writing cache or logs | ls -la on cache dir; fix owner to openclawsvc; avoid running sudo npm -g mixed with user installs. |
| Intermittent 401 from CI | Compare secret names across repos; check for trailing newline characters in the stored token; ensure clock skew is minimal (sntp -sS time.apple.com). |
After any change, run your usual health command (for example openclaw doctor if available in your build) and a local curl -sf -H "Authorization: Bearer $TOKEN" http://127.0.0.1:18765/health before you expose the proxy listener.
Pre-launch security checklist
- Gateway not bound to
0.0.0.0without IP allowlist + strong auth. - Token rotated from any default; stored 600; absent from git and CI output.
- Egress allowlist documented;
HTTPS_PROXY/NO_PROXYset for the daemon user. - Logs landed on disk with rotation; at least one automated alert on auth failure spikes.
- Restore test: rebuild node from script in a clean user home.
Security FAQ
Should the OpenClaw gateway listen on 0.0.0.0 on a remote Mac? Prefer not. Bind to loopback and use a reverse proxy with TLS and IP restrictions, or bind to a private interface only. Unauthenticated gateways on public interfaces were a repeated finding in 2025–2026 exposure data.
Where should I store the gateway bearer token? In a 600-permission env file or secrets manager, injected via launchd or your orchestrator. Rotate on staff changes and never print tokens in CI logs.
How do I limit arbitrary outbound URLs from skills? Maintain a hostname allowlist, enforce proxy and firewall egress, and keep skill code reviewed. Document exceptions instead of turning off filters.
What log patterns deserve alerts? Auth failure bursts, TLS or handshake error spikes, new outbound hosts versus baseline, and sustained 429 responses that may indicate token abuse.
Summary and how to choose your remote Mac node
Hardening OpenClaw on a remote Mac is mostly boring work done well: correct Node and user permissions, bearer tokens that never touch git, outbound paths that match a written allowlist, and logs you actually alert on. That combination directly addresses the gateway exposure patterns that dominated 2025–2026 postmortems.
If you are selecting infrastructure, prioritize a dedicated Apple Silicon host with stable egress and a support path for SSH/VNC break-glass access—so you can apply the checklist above without fighting shared multitenant noise. Compare plans on our pricing page, rent a node via purchase, read help for access details, and keep following the OpenClaw deployment series on the blog for adjacent CI and Docker topics.
Run OpenClaw on hardware you control end-to-end
Explore technical blog, home, help, and purchase—no login required to browse.