OpenClaw personal gateway setup: install, onboard, dashboard

OpenClaw is a self-hosted multi-channel gateway for AI agents. You run one Gateway process; it becomes the control plane for sessions, channel plugins, and tools. You message it from Discord, Google Chat, iMessage, Matrix, Microsoft Teams, Signal, Slack, Telegram, WhatsApp, Zalo, and other channel plugins, and get agent responses without handing your day to a hosted chatbot SaaS.

Docs: docs.openclaw.ai. Site: openclaw.ai. Licence: MIT; developed in the open with the OpenClaw Foundation (non-profit).

This article gets a personal gateway running. The next articles cover allowlists and pairing and skills, heartbeat, and approvals. For when to choose OpenClaw versus Hermes, see choose by job.

A freshly installed gateway with tools enabled is powerful. Shell, files, and browser capabilities mean a stranger who can message the bot may coerce unsafe actions. Complete install, then apply allowlists and pairing before you connect a public-facing channel or enable elevated tools. See OpenClaw’s security guide.

What the Gateway is (mental model)

Chat apps + plugins → Gateway → agent session / tools
                    ↘ Control UI (browser)
                    ↘ CLI

The Gateway is the single source of truth for sessions, routing, and channel connections. The browser Control UI is for chat, config, and sessions. Config lives at ~/.openclaw/openclaw.json by default.

OpenClaw is not a multi-tenant security boundary for mutually adversarial users sharing one agent. The documented trust model is one trusted operator boundary per gateway. Host multiple trust boundaries as separate gateways (ideally separate OS users or hosts).

Node version requirements

The current Node install docs require Node 22.22.3+, 24.15+, or 25.9+ (which includes Node 26). Node 26 is the documented default/recommended runtime; Node 23 is unsupported. Floors move, so re-check Getting Started and the Node page on install day rather than copying an older snapshot.

Install and onboard

From the current Getting Started path:

curl -fsSL https://openclaw.ai/install.sh | bash
openclaw onboard --install-daemon

onboard --install-daemon runs guided setup and installs the Gateway as a daemon so it survives logout/reboot according to your platform’s service model.

You will need an API key (or local model configuration) for the provider you choose. Prefer a strong latest-generation model for any bot that will use tools; weaker models are easier to social-engineer into unsafe tool use (security guidance).

After onboard, run openclaw security audit (and --deep when you are ready for a live probe). Fix inbound access and network exposure findings before you treat the install as personal-production.

Open the Control UI

Default local dashboard:

http://127.0.0.1:18789/

Or:

openclaw dashboard

Use the UI to send a first message, inspect sessions, and confirm the Gateway is alive. Keep the Control UI on loopback unless you have deliberately set up authenticated remote access. Tailscale and related patterns are documented under OpenClaw’s remote-access guidance; do not expose :18789 to the WAN unauthenticated.

Hardened baseline ideas from the security docs include gateway.mode: "local", bind: "loopback", and token auth for the gateway. Start closed; open deliberately.

Config location and backups

Default config: ~/.openclaw/openclaw.json. Credentials and pairing state also live under ~/.openclaw/. Before experiments:

1. Copy the config file to a dated backup outside the sync folder you share with a team.
2. Note your Node version (node -v) next to the backup.
3. After a bad remote-access change, restore the backup and restart the daemon rather than debugging live with channels open.

Do not commit real tokens to git. Keep a redacted example config in your runbook if multiple operators need the shape.

Common install gotchas

When in doubt, prefer the official Getting Started and troubleshooting entry points over forum folklore.

Provider and model configuration

During onboard you will point the agent at a cloud provider API key or a local/OpenAI-compatible base URL. Practical rules:

• Use the strongest current model you are willing to pay for (or host) whenever tools are enabled. OpenClaw’s security docs explicitly prefer modern, instruction-hardened models for tool-using bots.
• If you use a local endpoint, apply the same private-network and auth discipline as n8n → local OpenAI-compatible endpoints.
• Keep keys out of chat logs and out of committed config samples.

You can refine model choice later; do not postpone pairing/allowlists while you experiment with models.

Daemon, updates, and doctor

--install-daemon matters because a terminal-bound Gateway stops when its terminal or SSH session ends, while the platform service manager can start or restart the Gateway across login or reboot. A sleeping laptop still cannot process messages. Follow the updater for the install method you chose; do not mix package-manager state casually. After an upgrade, run the supported diagnostics:

openclaw doctor --fix   # when docs recommend it for config/monitor drift
openclaw security audit

Read the release notes when you jump major Node or OpenClaw versions. Re-verify the Control UI port and auth settings after any remote-access experiment.

First channel without drama

Telegram is often the fastest channel to wire for a personal smoke test. For that path:

1. Create the bot token using Telegram’s current OpenClaw instructions.
2. For a one-owner bot, prefer dmPolicy: "allowlist" with your explicit numeric Telegram user ID in allowFrom.
3. The default pairing flow remains valid for onboarding. If you use it, approve yourself with openclaw pairing list telegram and openclaw pairing approve telegram <code>.
4. Treat pairing narrowly: it grants DM access only. If no command owner exists, the first approved pairing may also bootstrap commands.ownerAllowFrom; group authorization still comes from explicit config allowlists.
5. Keep groups blocked for the first smoke test. When you enable one, put its stable group chat ID under channels.telegram.groups, keep sender IDs in allowFrom or groupAllowFrom, and retain requireMention: true.

Hardened Telegram starting shape, combining the current channel guidance with the current exec-policy surface (replace the example sender ID and keep the live docs open):

{
  channels: {
    telegram: {
      enabled: true,
      dmPolicy: 'allowlist',
      allowFrom: ['123456789'],
      groupPolicy: 'allowlist',
      groups: {},
    },
  },
  session: { dmScope: 'per-channel-peer' },
  gateway: {
    mode: 'local',
    bind: 'loopback',
    auth: { mode: 'token', token: 'replace-with-a-secret-reference' },
  },
  tools: {
    profile: 'messaging',
    deny: [
      'group:automation',
      'group:runtime',
      'group:fs',
      'sessions_spawn',
      'sessions_send',
    ],
    fs: { workspaceOnly: true },
    exec: { mode: 'deny' },
    elevated: { enabled: false },
  },
}

Details and failure modes belong in allowlists and pairing.

Smoke-test script

1. Open http://127.0.0.1:18789/ and send “ping” to yourself in the Control UI.
2. Confirm a session appears and the model replies.
3. Connect one DM channel and confirm your explicitly allowlisted primary identity can message the agent. If you are deliberately testing pairing instead, approve that primary identity first.
4. Send a message from a second identity you control. With dmPolicy: "allowlist", confirm it is blocked; if you are testing pairing, leave its request unapproved and confirm it cannot start a tool-capable turn.
5. Run openclaw security audit and fix anything marked open+tools or public bind.

If step 4 fails open (the unknown sender gets a full agent turn with tools), stop and fix DM policy before any further integration work.

Where this sits relative to n8n and Hermes

They can coexist. One evaluation architecture is scheduled checks in n8n, judgment in Hermes, and on-call chat through OpenClaw with a tight allowlist. Hermes exposes an OpenAI-compatible API server and a separate signed-event webhook adapter; choose and document one contract instead of treating them as interchangeable.

NVIDIA’s NemoClaw platform-support matrix describes a separate OpenShell-based early-preview alpha. It currently marks OpenClaw and Hermes agent paths as tested, while platform, inference, and deployment rows carry their own limitations. NemoClaw is not a prerequisite for this laptop setup, and NVIDIA does not offer a production SLA.

Personal setup checklist

• Supported Node version installed
• Official installer (or another documented install path) succeeded
• openclaw onboard --install-daemon completed
• Control UI opens on 127.0.0.1:18789
• openclaw security audit reviewed
• First channel uses an explicit DM allowlist or deliberately approved pairing; group authorization is separate
• No WAN bind on Gateway or model ports
• Provider keys stored as secrets, not in chat history
• Second test identity cannot reach tools before approval

Channel history, attachments, and tool outputs may land in Gateway state under ~/.openclaw. Treat that directory like a mailbox and credential store: disk encryption, tight file permissions, and no sync of the state dir into shared cloud folders without a deliberate decision.

What “done” looks like for day one

You can open the dashboard, complete one DM with yourself, and see a session. You have not “finished” until pairing/allowlists are set and you understand which tools the agent can invoke. Setup without a security pass is only a demo.

Next: lock identity and groups, then add skills and heartbeat with restrictive policy for shell and browser actions.