The Purpose of This Article
If you search for information on OpenClaw online, almost everything you find is a basic introduction—”What is OpenClaw?”—covering overviews, use cases, and general features. There is nothing wrong with that.
However, the moment you actually try to host and run it on your own server, the practical information you need is nowhere to be found.
This article is a practical, hands-on memo based on my real experience running OpenClaw in a cross-host configuration on a LAN and integrating it with a Discord Bot. I wrote this as the “next step” for anyone who read an introductory article and thought, “Alright, let’s actually deploy this thing.”
The Gap Between Introductions and Reality
What the Introductory Articles Tell You
- OpenClaw is an open-source AI agent platform.
- You can access multiple agents via the Gateway.
- It integrates with Discord, Telegram, Slack, etc.
- You can interact with it using a CLI (TUI).
All of this is entirely true.
What the Introductory Articles Don’t Tell You
| Real-World Problem | Mentioned in Tutorials? |
|---|---|
The Gateway only binds to 127.0.0.1 by default. | ❌ |
| Connecting from another machine requires changing the bind settings and opening the firewall. | ❌ |
| Remote connections require token authentication. | ❌ |
| New devices cannot connect unless they receive “pairing approval.” | ❌ |
| If you miss the timing for pairing approval, you’re stuck. | ❌ |
Setting a custom bind breaks the TUI on the local machine. | ❌ |
| Discord integration requires CLI actions on the server, not just “Authorizing the app” on Discord. | ❌ |
None of these are bugs—they are by design (specifications). However, the documentation isn’t comprehensive enough yet, leaving you to figure these things out the hard way.
Why You Need This Information
If you are just going to use OpenClaw on a single local machine with default settings, you will rarely run into these issues. You just run openclaw tui and it works out of the box.
However, these problems surface the moment you try any of the following:
- You want to separate the GPU machine from the Bot hosting machine.
- You want to connect from a different host on your LAN.
- You want to run a Discord Bot as an independent process.
- You want to manage it as an auto-starting
systemdunit for production.
In short, the moment you try to use it in a real production environment, you will step on every single one of these landmines.
Overview of the Actual Architecture
Here is the actual configuration running in this repository:
Host A (Linux) Host B (Linux)
┌──────────────────────┐ ┌──────────────────────────┐
│ python src/main.py │── WebSocket ──>│ OpenClaw Gateway │
│ (Discord Bot) │ LAN │ ws://192.168.0.108:18789│
│ 192.168.0.15 │ │ ↓ │
└──────────────────────┘ │ Agent: main │
↑ └──────────────────────────┘
Discord API
↑
User (Discord)
