2026 OpenClaw in Production: Multi-Endpoint Routing & CI Change Summaries

Use one automation UNIX user for OpenClaw, TLS material, and CI jobs so launchd and shells share PATH and secrets—otherwise you chase “works in Terminal, fails in CI.”

• Node 24 LTS for that user; verify node -v in a non-login shell and pin the major in images.
• Egress: HTTPS to every upstream; set HTTPS_PROXY consistently for daemons and shells if required.
• Secrets: mode 600 env files or a secret manager; rotate after any log leak.
• RAM: leave headroom for TLS and JSON spikes if workers colocate on the same Mac.
• Logs: fix stdout/log paths once so CI summaries always tail the same file.

Colocating gateway and dependency pulls? Keep one automation “plane” (Node, PATH, DNS). For CI log surfacing patterns, see GOPROXY fallback & CI logs.

Pick one install channel per fleet (global npm, installer, or pinned tarball), then bake openclaw onboard into the golden image so config dirs and ports exist before first boot.

• Doctor clean before registering upstreams—PATH and permission warnings often precede opaque 502s.
• Reverse proxy: forward Host and X-Forwarded-Proto so webhook URLs are correct.
• Reload via documented signal; avoid duplicate listeners from kill -9 loops.
• Pin semver in IaC so CI can echo it next to routing decisions.

Compatible servers share chat/completions JSON; they differ in auth, paths, quotas, and model ids. Copy the table into your runbook and map column three to real env keys.

Illustrative environment layout—replace names with your secrets backend:

# /etc/openclaw/endpoints.env (mode 600, not in Git)
UPSTREAM_OPENAI_BASE=https://api.openai.com/v1
UPSTREAM_OPENAI_KEY=sk-...
UPSTREAM_LOCAL_BASE=http://127.0.0.1:8080/v1
UPSTREAM_LOCAL_KEY=local-dev-token

# Routing: logical model -> upstream id (gateway-specific config file)
# fast -> openai/gpt-4.1
# cheap -> local/qwen2.5-7b
# default -> cheap

Prefer small ordered rules or generated JSON from a typed template—avoid one-line blobs.

Use a fast route such as /health, /healthz, or /ready; avoid billing upstreams on every shallow probe. Optional “deep” checks can run on a slower cadence.

# Local sanity (same user as the daemon)
curl -fsS "http://127.0.0.1:PORT/health" | jq .

# Through the public hostname (validates TLS + DNS + proxy)
curl -fsS "https://gw.example.com/health" | jq .

Schedule shallow probes with launchd ThrottleInterval, log under ~/Library/Logs, alert after consecutive misses—see the health runbook linked above. Export per-upstream fields to metrics when present.

After infra or dependency changes, surface green/red plus which lane served—without SSH.

Pattern A — GitHub Actions step summary. After a job that touches gateway config or model pins, append a short markdown section to GITHUB_STEP_SUMMARY when the variable exists:

SUMMARY_FILE="${GITHUB_STEP_SUMMARY:-}"
if [[ -n "$SUMMARY_FILE" ]]; then
  {
    echo "### OpenClaw routing snapshot"
    echo "- Gateway profile: ${OPENCLAW_PROFILE:-default}"
    echo "- Health (truncated):"
    curl -fsS "https://gw.example.com/health" | head -c 1200
    echo ""
    echo "- Last 30 lines of gateway log:"
    tail -n 30 "${OPENCLAW_LOG_PATH:-/tmp/openclaw.log}"
  } >> "$SUMMARY_FILE"
fi

Scrub secrets; log endpoint aliases, not raw keys.

Pattern B — inbound webhook to the gateway. When CI finishes, POST a signed JSON payload to your gateway’s automation route (if enabled) so bots can announce new lockfiles or model cache versions to Slack or Telegram—reuse channel setup from the message-channel FAQ linked in the introduction. Validate signatures the same way you would for vendor webhooks.

Treat extra endpoints like production deps: Node 24, clean doctor, versioned routes, scheduled health, CI-visible evidence. That keeps the gateway boring while R&D and automation stay aligned.