OpenClaw on exe.dev

exe.dev sells a cheap always-on Linux VM with an HTTPS proxy in front, and the OpenClaw docs use it for a Gateway reachable at a public name without running your own VPS. There are two paths: a beginner path where exe.dev’s agent, Shelley, installs everything from one prompt, and a manual path through nginx. Here are both, the header rule that the docs call out as a hardening risk, the origin and proxy settings, how to reach the Control UI and approve devices, the config-patch pattern for channels, and updating.

The two paths

• Beginner path: open the exe.new OpenClaw link, fill in your auth key or token, click the agent button next to your VM, wait for Shelley to finish provisioning, open the VM’s public HTTPS address, authenticate with the shared secret, and approve pending device pairing requests from the shell.
• The Shelley prompt the docs provide asks for non-interactive accept-risk onboarding, nginx forwarding from the default Gateway port to the root location with WebSocket support, the allowed origin set to the exact public HTTPS origin, trusted proxies set to loopback because nginx overwrites the forwarded-for header, pairing through the devices commands, and a health check that shows OK.
• Manual path: create the VM, keep it stateful because the config, the shared and per-agent SQLite auth stores, sessions, channel and provider state and the workspace all live under the state directory, install the prerequisites and run the install script.
• The nginx site listens on port 80 and on port 8000, which exe.dev forwards to HTTPS, and proxies to the Gateway with HTTP 1.1, the upgrade and connection headers for WebSockets, standard proxy headers, and day-long read and send timeouts for long-lived connections.

Overwrite forwarding headers instead of preserving client-supplied chains. OpenClaw trusts forwarded IP metadata only from explicitly configured proxies, and append-style X-Forwarded-For chains are treated as a hardening risk.

Origin, proxy, auth

Set the Control UI allowed origins to the exact public origin and the trusted proxies to loopback only, both with strict JSON, then restart. The browser origin check is fail-closed for public hostnames, and the proxy allowlist lets OpenClaw use nginx’s overwritten forwarded-for value instead of treating every request as if it came from the loopback proxy; keep that list limited to proxies you control. The guide uses token auth: print the configured token from an interactive terminal with the auth-token show command, generate one with the doctor flag if none is configured and restart, or switch the auth mode to a password held in config or an environment variable. Approve devices with the devices list and approve commands, and when in doubt let Shelley do it from the browser.

Channels and updates

• For remote hosts the docs prefer one config patch call over many config sets: keep real tokens in the VM environment or the state directory’s env file, put only secret references in the config, write a patch file locally, pipe it over SSH with a dry run first, then apply it and restart.
• The example patch declares an env-backed secrets provider, enables Slack in socket mode with bot and app tokens as secret references, an open group policy and no mention requirement, enables Discord with its token as a reference, direct messages disabled and an allowlist group policy, and sets a primary model with a fast-mode parameter; a replace-path flag makes a nested allowlist become exactly the patch value.
• exe.dev handles authentication for remote access, forwarding traffic from port 8000 to the public HTTPS name with email auth by default, and updating is the plain update command.

OpenClaw remote access covers the proxy and origin patterns this recipe follows, and OpenClaw behind Cloudflare the other common HTTPS front for a self-run Gateway.

When to pick it

It fits someone who wants a stable public HTTPS name and an agent that does the plumbing, and who is comfortable that the VM, its state directory and its updates are theirs to keep. The OpenClaw Gateway explained is the process behind nginx, and Diali versus your own server weighs self-run hosting against a managed one.

On Diali

On Diali the proxy, origin and header rules are ours to get right once for every instance, the state directory lives on a persistent volume, and updates arrive with the release train rather than an update command. Hosted OpenClaw on Diali is the assistant and Diali security describes the boundary.

• One prompt to Shelley or one nginx site.
• Exact origin, loopback proxy, overwritten headers.
• Secrets in env, references in config, one patch.