How OpenClaw’s December 2025 Gateway Became a Managed Service

OpenClaw’s Gateway acquired its first practical service lifecycle across three December 2025 beta releases, when the project was temporarily named Clawdis. In eight days, operators went from manually starting a loopback daemon to installing a supervised package, choosing a remote-access path, and adjusting authentication after an unusually short-lived PAM option.

This article starts with beta1 as the operational baseline. The relay and Unix-socket origins of Gateway ownership are covered separately; the question here is how beta1 through beta3 made the daemon installable, restartable, supervised and remotely reachable.

Beta1 established the service contract

The v2.0.0-beta1 release, published on 19 December 2025, made the break explicit. Its release notes described a loopback-only WebSocket daemon at ws://127.0.0.1:18789 that owned “all providers/state.” The CLI, WebChat, macOS app and nodes became clients. Helper subcommands stopped auto-spawning the Gateway; an operator had to start it directly or let the macOS app do so.

The same release shipped a typed, JSON Schema-validated protocol and Gateway helpers for health, status, sending, agent runs and raw calls. Cron also became Gateway-owned. An optional bridge on port 18790 allowed paired nodes to connect from a LAN while the main control plane remained on loopback.

For operators, the immediate change was lifecycle-related: helper commands no longer started the daemon on demand. The Gateway had to be running before clients could use it, and remote operation needed a deliberate bridge, SSH tunnel or private-network path to its loopback boundary.

The historical Gateway runbook at the beta3 tag records the intended service contract. The daemon ran until stopped, returned a non-zero exit on fatal errors so a supervisor could restart it, emitted a shutdown event for clients and rejected malformed or non-connect first frames. It also documented a “one Gateway per host” rule and said sends should fail fast rather than open fallback provider connections.

Packaging turned architecture into operations

Two days later, v2.0.0-beta2 shipped a Bun-compiled embedded Gateway, a gateway-daemon command and launchd support. This was the point at which the architectural change acquired a lifecycle story for ordinary installations: the macOS package could install and supervise the process instead of requiring a terminal to remain open.

The release also added bind-mode configuration, Tailscale authentication and PAM authentication, plus safer handling when upgrading the listening socket. The macOS app clarified local versus remote Gateway selection and re-established remote tunnels when needed.

PAM did not last. v2.0.0-beta3, published on 27 December, removed Gateway PAM/system authentication and directed operators to a token or shared password. It also required password authentication for public Tailscale Funnel exposure. That is a useful historical warning against treating every capability in a beta as a durable deployment contract: PAM appeared in one beta’s release notes and was explicitly removed in the next.

Beta3 also added a SIGUSR1 in-process restart path exposed through the Gateway tool. The release notes say this avoided requiring an external supervisor for that particular restart operation. It did not make supervision obsolete. The tagged runbook still recommended launchd or systemd for process survival and log handling, and described non-zero fatal exits as signals for a supervisor.

Who felt the transition

Three groups had immediate work:

1. CLI and server operators had to run a persistent daemon before helper commands would work. A dead Gateway now meant failed sends and calls, not an invisible helper-spawn recovery.
2. Remote operators had to choose an exposure model. The tagged remote-access guide prescribed forwarding remote loopback over SSH with ssh -N -L 18789:127.0.0.1:18789 user@host. Clients could continue to address local port 18789 while the tunnel carried traffic to the remote host.
3. macOS and node users moved onto a shared control plane. The app could manage an SSH tunnel, while paired nodes used the bridge on suitable LAN or tailnet paths. Those were different trust and transport paths, not interchangeable labels for “remote.”

Anyone exposing the dashboard also had to understand Serve versus Funnel. The beta3 Tailscale document kept the Gateway on loopback in both modes. Serve offered tailnet-only HTTPS and could trust Tailscale identity headers by default. Funnel was public and refused to start without shared-password mode. A configured token still had to be presented over an SSH tunnel; the encrypted tunnel did not cancel Gateway authentication.

The beta-era operations model

The three betas forced operators to separate four concerns that were easy to blur together:

• Binding: where the Gateway listens. Loopback limits direct network reachability.
• Transport: how a remote client reaches that listener, such as SSH forwarding or Tailscale.
• Authentication: what the Gateway accepts during the WebSocket handshake.
• Supervision: what restarts the process after a crash, reboot or fatal configuration error.

Solving one does not solve the others. SSH supplies a protected path but does not supervise the process. A token authenticates a client but does not make a public bind prudent. SIGUSR1 can reload the Gateway in process but cannot recover a process that has already exited. Tailscale Funnel supplies public routing and HTTPS, which is precisely why beta3 required password mode rather than treating network reachability as identity.

A sensible migration checklist in that period was therefore short but structural: install a service definition, keep the Gateway on loopback unless direct binding is intentional, configure an explicit credential, choose one remote path, and monitor both process liveness and provider readiness. The tagged runbook distinguished those last two checks: a successful WebSocket connect established liveness, while the health call reported whether the messaging provider was ready.

What the beta1–beta3 sequence established

The December sequence established an operations order: first determine whether the daemon is running, then whether the client can reach it, then whether authentication succeeds, and only then investigate an individual UI or channel.

It also separated remote-access vocabulary into distinct dimensions. “Local,” “remote,” “Serve,” “Funnel,” “token” and “supervised” did not mean the same thing: beta1 set the manual daemon baseline, beta2 packaged and exposed it, and beta3 tightened restart and authentication behaviour.

This analysis is based on the tagged release notes and documentation preserved with v2.0.0-beta3. We verified the source URLs and tag publication timestamps, but did not independently install or reproduce these historical beta builds. The beta3 release attributes upstream coverage for Gateway SIGTERM timeouts and webhook authentication; those are upstream-reported tests, not tests run by OpenClaw Academy.