Can two instances share one OPENCLAW_HOME

No. Official multi-instance guidance assumes separate home directories so config, credentials, and runtime sockets never collide; sharing one tree risks locking races and mixed gateway state.

Should I prefer OPENCLAW_GATEWAY_PORT or --port

Use OPENCLAW_GATEWAY_PORT in plist EnvironmentVariables for stable launchd supervision; use --port in manual shells or wrappers when experimenting; both should resolve to the same integer before you go live.

Why does only one gateway start under launchd

The second process often inherits the wrong PATH or still points OPENCLAW_HOME at production; confirm each plist block and run launchctl print user/$(id -u)/com.example.openclaw.staging to read the effective environment.

2026 OpenClaw on a Rented Mac Mini: OPENCLAW_HOME Multi-Instance, Dual Gateway Ports, and CI Polling Digest Webhooks

Apr 25, 2026

RunMini Tech Team

Read time: 9 mins

Teams that run OpenClaw on a rented Mac Mini often outgrow a single gateway: staging Skills, canary models, and production webhooks collide when every process assumes the same default listen port and the same on-disk home tree.

Official multi-instance guidance is three levers: separate OPENCLAW_HOME, distinct ports via OPENCLAW_GATEWAY_PORT or --port, and launchd PATH blocks that match SSH. Below: directory map, second onboarding, keep-alive, probes, CI digest merge. See install, upgrade, daemon health, OpenClaw hub.

Pain points when you clone configs instead of isolating homes

Socket and state races. Two gateways that still write under one OPENCLAW_HOME fight for the same SQLite or lock files; failures look random because they depend on boot order.
Port collisions. If both processes default to the same listen port, the second boot prints EADDRINUSE while launchd thrashes KeepAlive restarts and burns CPU on a quiet host.
PATH drift under launchd. SSH resolves openclaw under the npm global prefix while the agent inherits a tiny PATH, so interactive onboarding works yet the supervised gateway never binds a listener and logs only file-not-found errors.

Decision matrix: when to split OPENCLAW_HOME

Use the matrix before you buy a second machine. Most teams on RunMini stay on one Apple Silicon node and fund isolation with directories and ports instead of duplicate hardware. The official pattern is explicit: never share one home between two long-lived gateways; always publish which process owns which port in your internal catalog so firewall reviews stay boring.

Need	Single OPENCLAW_HOME	Two homes plus two ports
Prod only, one gateway	Simplest operations; one plist, one port map entry	Overkill unless you are rehearsing migrations weekly
Staging Skills or canary models nightly	High risk of clobbering tokens or caches	Recommended: mirror layout, different secrets file per tree
CI fires dozens of small workflow events per hour	OpenClaw sees alert fatigue even if gateways are healthy	Keep two gateways if needed, but merge CI into one digest webhook payload

Reproducible steps from directory plan to second gateway

Directory plan. Create ~/openclaw/prod and ~/openclaw/staging; note owner and backup policy.
Freeze prod. Record OPENCLAW_HOME, OPENCLAW_GATEWAY_PORT, and openclaw doctor before changes.
Second onboard. export OPENCLAW_HOME=~/openclaw/staging, openclaw onboard, then set OPENCLAW_GATEWAY_PORT=18790 or openclaw gateway --port 18790 so env and CLI match.
Smoke. Validate with lsof -nP -iTCP -sTCP:LISTEN, then move to launchd so SSH drops do not kill gateways.
Health. One probe per port per daemon health patterns.
CI digest. Poll Actions or GitLab schedules; aggregate failures to one JSON POST per window.

launchd, launchctl, and PATH hygiene for two labels

Copy the prod plist to a new Label. Set EnvironmentVariables for OPENCLAW_HOME, OPENCLAW_GATEWAY_PORT, and PATH including npm bin -g. Add RunAtLoad and ThrottleInterval. launchctl bootout then bootstrap; verify with launchctl print.

<key>Label</key><string>com.example.openclaw.staging</string>
<key>EnvironmentVariables</key>
<dict>
  <key>OPENCLAW_HOME</key><string>/Users/you/openclaw/staging</string>
  <key>OPENCLAW_GATEWAY_PORT</key><string>18790</string>
  <key>PATH</key><string>/opt/homebrew/bin:/usr/local/bin:/usr/bin:/bin</string>
</dict>
<key>ProgramArguments</key>
<array>
  <string>/opt/homebrew/bin/openclaw</string>
  <string>gateway</string>
  <string>--port</string>
  <string>18790</string>
</array>

Health checks and CI polling summary merged alerts

One synthetic check per port plus log rules for TLS or token churn. Buffer CI events in a state file; emit one webhook per window when severity crosses threshold.

Digest fields: repo, branch, failing matrix coords, log hash.
POST to staging first; promote URL after false positives drop.
See repository_dispatch for narrow secrets.

Triage: port conflicts and PATH mismatches

EADDRINUSE: check lsof, duplicate plists, stray tmux. Missing binary: diff SSH PATH with launchctl print; add npm global bin to the plist.

FAQ

Do I need two npm installs of @openclaw/cli?: Usually no. One global openclaw binary is enough if both plists call the same absolute path; isolation comes from OPENCLAW_HOME and ports, not duplicate packages.
Which ports on a shared RunMini host?: Use high ports like 18789 and 18790; document them; avoid WAN bind without TLS.

Citeable: two high ports; CI poll five–fifteen minutes; ThrottleInterval ≥ thirty seconds; digest under fifty KB.

Summary. Split OPENCLAW_HOME, bind ports with OPENCLAW_GATEWAY_PORT or --port, fix PATH in plists, probe each listener, merge CI into one webhook.

Rent a Mac Mini for dual OpenClaw gateways

Need Apple Silicon headroom for production and staging gateways without buying two desks of hardware? Open Pricing, then start Purchase—no login is required to begin checkout. Use Help Center for SSH and capacity questions; keep Blog runbooks for launchd and CI digests.

View Plans Rent Long-Term Help Center

After both gateways stay green overnight, lock the runbook in git and revisit when you add a third environment; Purchase stays login-free until you attach billing to an account.