OpenClaw on Upstash Box

Upstash Box is a managed Linux environment with a keep-alive lifecycle, and the docs use it for a persistent OpenClaw Gateway reached through an SSH tunnel rather than a public port. The page is short because the shape is simple: tunnel in, install, onboard without a daemon, bind to loopback, start one background process, and let the box’s init script own restarts. Here is each step, the npm detail that changes the install command, and the two rules that keep the setup from fighting itself.

Box and tunnel

• You need an Upstash account, a keep-alive box created in the console, its box id, and its API key, plus an SSH client; Upstash keeps its own current walkthrough alongside the OpenClaw docs.
• Connect with an SSH tunnel that forwards the dashboard port to your machine, using the box API key as the SSH password when prompted, with server-alive interval and count options that reduce idle tunnel drops during onboarding.
• Check the box’s Node and npm versions first, because the install command depends on them: newer npm takes an allow-scripts flag for the package, older npm must omit it; then install OpenClaw globally with sudo.
• Run onboarding with the no-install-daemon flag, follow the prompts, and copy the dashboard URL and token it prints at the end.

The Box init script is the single owner of Gateway startup, so two processes do not contend for the same lock and port.

Start and reach it

Set the Gateway bind to loopback so it is reachable only through the tunnel, start one unsupervised process in the background with nohup, and run doctor with JSON output to confirm the state. With the tunnel active, open the dashboard locally at the loopback address on the forwarded port with the token in the URL fragment. For auto-restart, set the same nohup start line as the box init script so the Gateway comes back when the box starts; onboarding deliberately skipped daemon installation so that the init script is the only thing starting the Gateway.

Troubleshooting and next

• If SSH freezes during onboarding, reconnect with a clean SSH config, ignoring the local config file and disabling connection multiplexing, plus the same keepalive options; that bypasses stale local settings and keeps the tunnel alive through idle periods.
• The docs’ next steps are the usual three: set up messaging channels, tune the Gateway configuration, and keep OpenClaw updated.
• Nothing on the box is exposed to the internet; the dashboard exists only at the far end of your tunnel, which is the whole point of the loopback bind.

OpenClaw remote access explains the tunnel and proxy patterns this recipe is one instance of, and OpenClaw doctor the check that ends it.

When to pick it

It suits someone who already lives in an SSH tunnel and wants a box that stays up without a VPS to patch; the trade is that every dashboard visit starts with the tunnel. The OpenClaw Gateway explained is the process the init script owns, and Diali versus your own server weighs self-run hosting against a managed one.

On Diali

On Diali there is no tunnel and no init script to maintain: the Gateway is private by construction, restarts are ours, and the dashboard is a sign-in away. Hosted OpenClaw on Diali is the assistant and Diali pricing what it costs.

• Tunnel in with the API key as the password.
• No daemon; the init script owns startup.
• Loopback bind, token in the fragment.