Host OpenClaw

Create the VM#

On your computer, create a VM. Names are global across exe.dev, so if my-openclaw is taken pick another (or run ssh exe.dev new and use the name it prints):

ssh exe.dev new --name=my-openclaw
ssh my-openclaw.exe.xyz

Everything below runs on the VM, as the default exedev user.

Install OpenClaw#

OpenClaw needs Node.js 24.16+ or 26.1+, and the VM image ships an older Node. The official installer takes care of it: on Ubuntu it installs Node 24 LTS from NodeSource (replacing the system nodejs package), installs OpenClaw with npm into ~/.npm-global, and puts that on your PATH.

On the VM:

curl -fsSL https://openclaw.ai/install.sh | bash -s -- --no-onboard --no-prompt
source ~/.bashrc
openclaw --version
node --version

It takes two or three minutes. You should see OpenClaw 2026.x.y and v24.x. --no-onboard skips the interactive setup wizard; the next steps do the same setup with flags.

Set up the Gateway service#

Non-interactive onboarding writes ~/.openclaw/openclaw.json, generates the Gateway's auth token, creates the agent workspace, and installs and starts the systemd user service openclaw-gateway. Models are configured in the next step, so it skips auth here:

openclaw onboard --non-interactive --accept-risk --mode local \
  --auth-choice skip --install-daemon --skip-channels --skip-search

--accept-risk is OpenClaw's acknowledgement that an agent with a shell is powerful; on a VM of its own, that is the point. The first start of the Gateway takes about a minute, so onboarding may end with Gateway did not become reachable. That is fine; wait for it:

until curl -fs http://127.0.0.1:18789/healthz; do sleep 5; done; echo

This prints {"ok":true,"status":"live"}.

A systemd user service normally stops when its user's last session ends. Lingering keeps it running with nobody logged in and starts it at boot. exe.dev VMs have it on for exedev; make sure:

sudo loginctl enable-linger "$USER"
loginctl show-user "$USER" -p Linger
systemctl --user is-enabled openclaw-gateway

Expect Linger=yes and enabled.

Connect Claude through exe.dev#

Every exe.dev VM can call Anthropic's Messages API at https://llm.int.exe.xyz with no key: exe.dev adds the credentials on the way out and bills your account. Point OpenClaw's built-in Anthropic provider there:

openclaw config patch --stdin <<'EOF'
{
  models: {
    providers: {
      anthropic: {
        baseUrl: "https://llm.int.exe.xyz",
        apiKey: "exe-llm-integration",
        request: { allowPrivateNetwork: true },
      },
    },
  },
  agents: { defaults: { model: { primary: "anthropic/claude-sonnet-5-5" } } },
  memory: { search: { provider: "none" } },
}
EOF
openclaw gateway restart

What each line does:

• apiKey is a placeholder. OpenClaw wants a value; the integration ignores it.
• allowPrivateNetwork is needed because llm.int.exe.xyz resolves to a link-local address inside the VM, which OpenClaw's SSRF guard blocks unless you opt in for that provider. Without it, every reply fails with Blocked: resolves to private/internal/special-use IP address.
• Claude Sonnet 5.5 is the default model; anthropic/claude-opus-5-5 is stronger and costs more (openclaw models set anthropic/claude-opus-5-5).
• memory.search.provider: "none" makes memory search keyword-based. OpenClaw's semantic memory search wants an OpenAI embeddings key, and the embeddings path doesn't accept the integration's address yet.

The restart takes up to a minute. Then send the agent a test message:

until curl -fs http://127.0.0.1:18789/readyz >/dev/null; do sleep 5; done
openclaw agent --agent main -m "Reply with exactly: pong"
openclaw models status | grep -E 'Default|Utility'

The agent answers pong, and the models are anthropic/claude-sonnet-5-5 and anthropic/claude-haiku-5-5 (for small background tasks), both through the integration.

Open the dashboard#

The Gateway listens on 127.0.0.1:18789 only. exe.dev's HTTPS proxy sends https://my-openclaw.exe.xyz/ to port 8000, private to you, so nginx on port 8000 passes it to the Gateway, WebSockets included. This replaces the image's default nginx site:

sudo tee /etc/nginx/sites-available/openclaw >/dev/null <<'EOF'
# https://<vm>.exe.xyz/ (exe.dev proxy) -> nginx :8000 -> OpenClaw Gateway 127.0.0.1:18789
map $http_upgrade $openclaw_connection {
    default upgrade;
    ""      close;
}

server {
    listen 8000 default_server;
    listen [::]:8000 default_server;
    server_name _;

    location / {
        proxy_pass http://127.0.0.1:18789;
        proxy_http_version 1.1;

        # The dashboard talks to the Gateway over a WebSocket
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $openclaw_connection;

        proxy_set_header Host $host;
        # Overwrite, never append: OpenClaw trusts these only from 127.0.0.1
        proxy_set_header X-Forwarded-For $remote_addr;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-Proto https;
        proxy_set_header X-Forwarded-Host $host;

        proxy_read_timeout 1d;
        proxy_send_timeout 1d;
        proxy_buffering off;
        client_max_body_size 50m;
    }
}
EOF
sudo rm -f /etc/nginx/sites-enabled/default
sudo ln -sf /etc/nginx/sites-available/openclaw /etc/nginx/sites-enabled/openclaw
sudo nginx -t && sudo systemctl reload nginx

Then tell the Gateway its public address and that nginx on 127.0.0.1 is a proxy it can trust for client addresses. The dashboard refuses browser origins it doesn't know, so the address must match exactly:

openclaw config patch --stdin <<EOF
{
  gateway: {
    publicOrigin: "https://$(hostname).exe.xyz",
    controlUi: { allowedOrigins: ["https://$(hostname).exe.xyz"] },
    trustedProxies: ["127.0.0.1"],
  },
}
EOF
curl -s http://127.0.0.1:8000/healthz; echo

The last line goes through nginx and prints {"ok":true,"status":"live"}. (Other paths return proxy_attribution_required when you curl them from the VM itself; that is OpenClaw refusing a forwarded request that claims to come from localhost, and it is expected.)

Now pair your browser. Two layers protect the dashboard: exe.dev's login, and OpenClaw's own auth, where each browser is a device the Gateway must approve.

1. Open https://my-openclaw.exe.xyz/ and log in to exe.dev. The dashboard asks for a Gateway secret; leave that page open.

2. On the VM, make a one-time owner pairing link for this address:

   openclaw dashboard --json | jq -r .browserUrl | sed \
     -e "s#^http://[^/]*/#https://$(hostname).exe.xyz/#" \
     -e "s#gatewayUrl=[^&]*#gatewayUrl=wss%3A%2F%2F$(hostname).exe.xyz#"
   

3. Open the printed https://my-openclaw.exe.xyz/#bootstrapToken=... link in the same browser within ten minutes. It is single-use; the dashboard connects, and that browser stays paired as the owner.

Type a message in the chat box; Claude answers.

If the link expired, make a new one. To pair another browser or your phone without a link, run openclaw gateway auth-token --show in a terminal on the VM (it refuses to print into a pipe or log), paste the token into Gateway secret, then approve the request it creates:

openclaw devices list
openclaw devices approve <requestId>

Connect Telegram#

Telegram is the easiest channel to run headless: a bot token is the only credential, and OpenClaw long-polls Telegram, so nothing on the VM is opened to the internet.

1. In Telegram, open a chat with @BotFather (check the handle exactly), send /newbot, choose a display name and a username ending in bot, and copy the token it replies with.

2. On the VM, give OpenClaw the token. read -s keeps it out of your shell history; it is stored in ~/.openclaw/openclaw.json, which only exedev can read:

   read -rsp "Telegram bot token: " TELEGRAM_BOT_TOKEN; echo
   openclaw channels add --channel telegram --token "$TELEGRAM_BOT_TOKEN"
   unset TELEGRAM_BOT_TOKEN
   openclaw channels status --probe
   

   The status line for Telegram default shows enabled, configured and no error. getMe returned 401 means the token is wrong.

3. Pair your own account. Send your bot any message. Telegram DMs start in pairing mode: the bot ignores the message and replies with an 8-character pairing code and your Telegram user ID. On the VM:

   openclaw pairing list telegram
   openclaw pairing approve telegram <CODE>
   

   Approve only the code your bot sent you. The first approval also makes you the command owner (commands.ownerAllowFrom), which owner-only commands and approval prompts need.

4. Lock the bot to you. In pairing mode strangers who find the bot can still request codes; an allowlist with your numeric user ID makes it ignore everyone else outright. Set the list before the policy (an empty allowlist is rejected):

   TG_ID=123456789   # your numeric Telegram user ID, from the bot's pairing reply
   openclaw config set channels.telegram.allowFrom "[\"$TG_ID\"]" --strict-json
   openclaw config set channels.telegram.dmPolicy allowlist
   openclaw config set commands.ownerAllowFrom "[\"telegram:$TG_ID\"]" --strict-json
   openclaw config get channels.telegram.dmPolicy
   openclaw config get channels.telegram.allowFrom
   

   This prints allowlist and your ID. The change applies without a restart.

Send your bot another message: it answers within a few seconds. Groups stay blocked (groupPolicy defaults to allowlist with no groups); see Telegram access control if you want the bot in a group.

Restart, status, and logs#

The Gateway is a normal systemd user service; OpenClaw's commands wrap it and add health checks:

openclaw gateway status        # Runtime: running, Connectivity probe: ok
openclaw gateway restart       # drains running work, restarts, waits for health
openclaw status                # channels, model, recent sessions
openclaw logs --follow         # the Gateway's own log (also in /tmp/openclaw/)
journalctl --user -u openclaw-gateway -n 100 --no-pager
openclaw doctor                # read-only checks; --fix applies repairs

systemctl --user restart openclaw-gateway works too. A restart takes up to a minute before the dashboard reconnects on its own.

To see it come back after a reboot, reboot the VM (your SSH session drops):

sudo reboot

Give it a minute or two, then on your computer, without logging in to a shell first:

ssh my-openclaw.exe.xyz curl -s http://127.0.0.1:18789/healthz

It prints {"ok":true,"status":"live"}, and your Telegram bot answers again. The Gateway started at boot because the unit is enabled and lingering is on; nobody had to log in.

Where your data lives#

OpenClaw keeps everything that matters in ~/.openclaw. The program itself (~/.npm-global) can always be reinstalled.

Ask the agent to write lasting preferences into AGENTS.md or MEMORY.md rather than relying on chat history; those files are what it reads at the start of every session.

Back up and restore#

Don't copy the live SQLite files; openclaw backup create snapshots them safely while the Gateway runs and archives config, credentials, and the workspace with them:

mkdir -p ~/backups/openclaw && chmod 700 ~/backups
openclaw backup create --output ~/backups/openclaw --verify
ls -lh ~/backups/openclaw

A fresh install archives to a few hundred kilobytes, ending in Archive verification: passed. Make it nightly with a systemd timer that also deletes archives older than 14 days:

mkdir -p ~/.config/systemd/user
cat > ~/.config/systemd/user/openclaw-backup.service <<'EOF'
[Unit]
Description=OpenClaw backup archive

[Service]
Type=oneshot
ExecStart=%h/.npm-global/bin/openclaw backup create --output %h/backups/openclaw --verify
ExecStart=/usr/bin/find %h/backups/openclaw -name *-openclaw-backup.tar.gz -mtime +14 -delete
EOF
cat > ~/.config/systemd/user/openclaw-backup.timer <<'EOF'
[Unit]
Description=Nightly OpenClaw backup

[Timer]
OnCalendar=*-*-* 03:30:00
RandomizedDelaySec=30m
Persistent=true

[Install]
WantedBy=timers.target
EOF
systemctl --user daemon-reload
systemctl --user enable --now openclaw-backup.timer
systemctl --user start openclaw-backup.service
systemctl --user list-timers openclaw-backup.timer

The archives hold your bot token, the Gateway token, and every conversation, so keep copies private. A backup on the same disk doesn't survive losing the VM; on your computer, pull copies down now and then:

rsync -av my-openclaw.exe.xyz:backups/openclaw/ ./openclaw-backups/

To restore, unpack an archive into a staging directory, stop the Gateway, swap the state directory, and start again:

ARCHIVE=$(ls -t ~/backups/openclaw/*-openclaw-backup.tar.gz | head -1)
rm -rf ~/openclaw-restore
openclaw backup restore "$ARCHIVE" --target ~/openclaw-restore
systemctl --user stop openclaw-gateway
mv ~/.openclaw ~/.openclaw.before-restore
mv ~/openclaw-restore/*/payload/posix/home/exedev/.openclaw ~/.openclaw
rm -rf ~/openclaw-restore
openclaw doctor --non-interactive
systemctl --user start openclaw-gateway

backup restore verifies the archive before it writes anything, and never touches the live directory. Once everything works, delete ~/.openclaw.before-restore. To move to a new VM, install OpenClaw there (the first two sections), copy the archive over, restore it the same way, then rerun the nginx and gateway config steps from "Open the dashboard" so the address matches the new VM.

Update#

openclaw update detects the npm install, checks the new version while the old Gateway keeps serving, then swaps it in, runs openclaw doctor, and restarts the service. Your ~/.openclaw stays where it is; the update only replaces the program in ~/.npm-global, and migrates state if a new version needs it. Take a backup first:

openclaw backup create --output ~/backups/openclaw --verify
openclaw update --dry-run
openclaw update
openclaw --version
openclaw gateway status

Don't use sudo npm i -g openclaw: it installs a second copy outside ~/.npm-global that the service doesn't use. After an update, reload the dashboard tab; if it reports a protocol mismatch, open a fresh pairing link.

Use your own key or subscription#

The LLM integration is the default because the key never touches the VM. Other options:

• Your Anthropic API key, still off the VM. Store it in the exe.dev integration instead of on the VM; nothing changes in OpenClaw. On your computer:

  printf '%s' "$ANTHROPIC_API_KEY" | ssh exe.dev integrations edit llm --anthropic=byok --anthropic-key=-
  

• A key on the VM, or another provider. Remove the integration override, then run the interactive onboarding and pick your provider (Anthropic, OpenAI, OpenRouter, and many more):

  openclaw config unset models.providers.anthropic
  openclaw onboard
  

• A Claude or ChatGPT subscription. Claude Code is preinstalled on the VM; log in with claude, then choose the Claude CLI route in openclaw onboard to run the agent on your subscription. For ChatGPT, either connect the subscription to the exe.dev integration (ssh exe.dev integrations setup chatgpt, see LLM integration) or sign in from openclaw onboard. Check your plan's terms for automated use first; OpenClaw's Anthropic page explains the trade-offs.

Troubleshooting#

Gateway did not become reachable after onboarding or a restart. The first start, and each restart, takes about a minute on a small VM. Check openclaw gateway status; if Runtime isn't running, read journalctl --user -u openclaw-gateway -n 100 --no-pager. A config error makes the service exit with status 78 and stay stopped until you fix it; openclaw doctor names the bad key.

The agent replies OpenClaw couldn't finish this reply. Look in openclaw logs --follow while you send a message. Blocked: resolves to private/internal/special-use IP address means request.allowPrivateNetwork is missing from models.providers.anthropic. A 401 or 403 from llm.int.exe.xyz means the LLM integration isn't attached to this VM; test it with curl -s https://llm.int.exe.xyz/v1/messages -H 'content-type: application/json' -H 'anthropic-version: 2023-06-01' -d '{"model":"claude-haiku-4-5","max_tokens":5,"messages":[{"role":"user","content":"hi"}]}' and see LLM integration.

The dashboard says Browser origin not allowed. allowedOrigins must be exactly https://<vm>.exe.xyz, with no trailing slash. If the VM was renamed or this is a copy, rerun the gateway config patch above.

The dashboard shows pairing required or Pairing link is no longer valid. The link was used or is older than ten minutes. Make a new one, or approve the browser with openclaw devices list and openclaw devices approve <requestId>. Private windows forget their pairing when closed.

502 Bad Gateway at https://my-openclaw.exe.xyz/. nginx is up but the Gateway isn't (often mid-restart). openclaw gateway status. If you see exe.dev's welcome page or a 404 instead, the default nginx site is still enabled: ls /etc/nginx/sites-enabled/.

proxy_attribution_required. gateway.trustedProxies is missing 127.0.0.1, or you curled nginx from the VM itself, which is expected to fail; use /healthz for local checks.

The Telegram bot doesn't answer. openclaw channels status --probe shows the channel's state and last error. getMe returned 401 means a wrong or revoked token: get a new one from @BotFather with /token and run openclaw channels add --channel telegram --token ... again. If the bot is silent for you but working, check that channels.telegram.allowFrom holds your numeric user ID (not your @username).

openclaw: command not found. The installer added ~/.npm-global/bin to ~/.bashrc; run source ~/.bashrc or open a new SSH session.

Node ... unsupported. node --version must be 24.16+ or 26.1+. Rerun the installer, which repairs Node, then openclaw doctor --fix.