This walkthrough targets teams that already run OpenClaw on a LeanVPS Germany (Frankfurt) remote Mac but want a smaller attack surface than “open the gateway on the LAN”. We keep the listener on loopback, require gateway token auth, reach the service through SSH LocalForward, and treat openclaw doctor --non-interactive plus openclaw config validate as merge gates. Public behavior is anchored to upstream docs—especially Configuration reference (gateway bind & auth), Configuration (env substitution), CLI doctor, and Gateway doctor—not third-party summaries.

Goal: loopback-only control plane, minimal exposure

The OpenClaw gateway multiplexes WebSocket and HTTP on port 18789 by default. The configuration reference states that gateway.bind: "loopback" keeps the listener on localhost, while non-loopback binds require gateway auth (token, password, or a carefully scoped trusted-proxy setup). For a shared remote Mac, the sweet spot is therefore: loopback bind + token mode, with operators and automation reaching the port through an encrypted tunnel instead of exposing 18789 on the host’s public interface.

Pair that topology with the broader daemon and egress discipline described in our companion article OpenClaw on LeanVPS Germany: daemon onboarding and compliance-style baselines. When you are ready to buy or resize capacity, use the public Purchase in Germany page and cross-check tiers on pricing.

127.0.0.1
Loopback bind
SSH -L
LocalForward tunnel
CI
Validate + doctor

Minimal reproducible steps (remote Mac)

Execute the sequence on a staging host first; promote the same plist, SSH stanza, and CI job to production after a green dry run.

  1. SSH baseline. Create a dedicated macOS user for OpenClaw. Install only your approved OpenClaw build, then verify non-interactive SSH using keys (disable password authentication for that account in sshd_config if policy allows).
  2. Declare bind + auth in JSON5. In ~/.openclaw/openclaw.json, keep gateway.mode: "local", set gateway.bind: "loopback", and configure gateway.auth.mode: "token" with gateway.auth.token: "${OPENCLAW_GATEWAY_TOKEN}" as shown under “Env var substitution in config values” in the official Configuration guide. If both token and password objects ever coexist, the reference requires an explicit gateway.auth.mode—set it deliberately to avoid ambiguous startup.
  3. Inject the token, not the secret file path in Git. Export OPENCLAW_GATEWAY_TOKEN from a LaunchDaemon EnvironmentVariables dictionary or a root-owned environment file with restrictive POSIX permissions. For a one-time bootstrap on a secured admin shell you may run openclaw doctor --generate-gateway-token as documented on CLI doctor; afterwards rotate and move the value into your secret store pattern.
  4. Headless health pass. Run openclaw config validate followed by openclaw doctor --non-interactive. The gateway doctor page documents that --non-interactive skips prompts, applies safe migrations, and avoids interactive OAuth refresh—ideal for cron or CI (Gateway doctor).
  5. Install or restart the gateway service. Use the vendor flow you already standardized (for example openclaw gateway install with your pinned flags). Confirm openclaw gateway status shows a healthy listener on loopback only.
  6. SSH LocalForward from your workstation. Run ssh -N -L 18789:127.0.0.1:18789 openclaw-svc@germany-host.example (adjust user and host). Your local tools now target ws://127.0.0.1:18789 while packets traverse SSH. Add -o ExitOnForwardFailure=yes and a systemd or launchd unit on the client if the tunnel must be long-lived.
  7. Smoke the token path. With the tunnel up, connect from your laptop to 127.0.0.1:18789 using the bearer token pattern your runbook documents (Control UI, CLI, or a small throwaway script). Deliberately send a wrong token once: you should see an auth failure instead of silent success—proving enforcement end-to-end.
Why not bind to LAN? Opening 18789 on 0.0.0.0 without compensating controls widens discovery and brute-force surface. If you truly need non-SSH access, place a hardened reverse proxy with mTLS or Tailscale Serve in front and re-read the trusted-proxy section of the configuration reference instead of skipping auth.

Compliance-minded exposure checklist (engineering only)

None of the bullets below constitute legal advice; they translate “least privilege” into concrete gates your security reviewers can grep for.

  • No plaintext tokens in shell history: load secrets via LaunchDaemon or CI secret injectors, never inline export in shared screen sessions.
  • Separate operator SSH from service accounts: humans use their own UNIX principals; the OpenClaw daemon user should not own your personal dotfiles.
  • Review gateway diffs in PRs: any change touching gateway.bind, gateway.auth, hooks, or gateway.http endpoints requires two-person review.
  • Back up config before doctor repairs: keep a timestamped copy of openclaw.json before upgrades; if a migration ever drops auth metadata, restore from artifact storage and restart the service.
  • Document break-glass: if someone temporarily widens bind mode for incident response, file a ticket and revert within the SLA window.

Merge gate recipe (GitHub Actions–style pseudocode)

Store a read-only fixture or sanitized excerpt of production config in Git—never the production token. Inject a throwaway OPENCLAW_GATEWAY_TOKEN from CI secrets so validation paths that resolve env substitution succeed. The job should:

  1. Install the same OpenClaw minor version pinned in production.
  2. Run openclaw config validate against the checked-in template merged with test secrets.
  3. Run openclaw doctor --non-interactive; fail if warnings cross your policy threshold (many teams treat any “auth missing” line as a hard error).
  4. Optionally run openclaw doctor --deep nightly—not on every PR—because deeper scans are slower and may need elevated permissions.

Escalation questions should follow your internal runbook; if you are blocked on provisioning or SSH, use the public Help center linked in the section below.

Operational guidance only. OpenClaw behavior changes release to release—verify flags and defaults against the official documentation links cited above before automation goes live.
Frankfurt · remote Mac

Need dedicated metal for this topology?

Provision a Germany-node Mac mini through our public purchase flow, align unified memory with your expected browser and model footprint on pricing, and open Help if provisioning or SSH access blocks you.

Purchase in Germany View pricing Help center