OpenClaw is a self-hosted AI assistant you reach from the chat apps your team already uses. Its gateway is the control plane that owns sessions and channel connections, and that shape is what makes channel access the security question that matters most.
OpenClaw is an open-source, MIT licensed self-hosted AI assistant from the OpenClaw Foundation, reachable from messaging platforms such as WhatsApp, Slack, Telegram, Discord, Signal, iMessage, and Microsoft Teams. It runs as a Node.js service in three parts: the gateway, which is the control plane owning sessions and routing, channel plugins for each messaging platform, and the agent itself. You supply the model, either a hosted provider or a local runtime such as Ollama.
Built around a gateway: one control-plane process owns sessions, routing, and every channel connection
Reachable from chat: the interface is WhatsApp, Slack, Telegram, Discord, Signal, and similar
Agentic, so it acts in connected services rather than only answering questions
Self-hosted, so sessions and credentials live on your machine, though channel traffic always leaves it and model calls do too unless you run a local model
A Node.js service that needs a host, updates, backups, and monitoring like anything else you run
THE SETUP GUIDE
Most OpenClaw writing covers the install, which takes about five minutes. The decisions that matter are about who can reach the gateway and what it is allowed to do once they do.
This is the part people miss. Anyone who can send a message into a connected channel can attempt to drive the agent. A shared Slack channel or a WhatsApp number is now an input to something holding live credentials. Decide who is allowed to talk to it before you connect anything.
One process is the single source of truth for sessions and routing, which makes it a single point of compromise. Give it its own machine or its own container and user, not a shared box running unrelated production services. A small always-on VPS is the usual answer, because a laptop that sleeps is a gateway that is offline.
Create a dedicated key or account per integration with the narrowest permission that works. Never connect an admin token because it is quicker. Assume anything the agent can reach through a credential will eventually be exercised.
Multi-agent routing means separate sessions can be kept apart. Use that. A support channel and an internal operations channel should not share context, history, or the same permission set.
Work out which directories hold configuration, session history, and credentials, and put them on persistent, backed-up storage before you need them. Losing the container should not mean rebuilding every channel connection by hand.
Uptime checks, log retention, an update cadence, and an alert when it stops responding. A gateway that quietly died still looks fine in the chat app, which is exactly why nobody notices.
These are the failures worth designing against before they happen, rather than diagnosing afterwards.
Connecting a channel without deciding who is allowed to message it
Running the gateway on a shared host, so one compromise reaches everything
One over-permissioned credential instead of scoped per-service keys
Letting unrelated channels share a session, and therefore share context and permissions
No backup of the configuration, session, and credential directories
Assuming self-hosted means nothing leaves the machine, when model calls and channel traffic both do
No spend limit, so an agent in a retry loop runs up model cost overnight
If you would rather have this running than build it, we set up the OpenClaw gateway on infrastructure you own, connect the channels your team actually uses, and put the access control and monitoring in place from the start.
Talk through your setupHost selection, provisioning, and hardening
Gateway installation, daemon setup, and persistent storage
Channel connection with an explicit decision on who may message it
Scoped credentials for each connected service
Session isolation across channels and roles
Approval gates on outbound actions and restricted-action safeguards
Monitoring, spend limits, alerting, and update cadence
Documentation and handover so you are not dependent on us
An open-source, MIT licensed, self-hosted AI assistant that you reach from messaging platforms and that can take actions in the services you connect. It runs as a Node.js service on your own machine or server, with a gateway process as its control plane. You supply the model, either a hosted provider or a local runtime. The project is maintained by the OpenClaw Foundation.
Not by itself, and it is worth being precise. Sessions, configuration, and credentials are stored on your machine. Messages always travel through the chat platform you connected, so that traffic leaves regardless. Prompts and responses leave only if you point it at a hosted provider: run a local model such as Ollama and inference stays on the host too. Self-hosting removes the vendor from the middle and gives you control over storage and access, and pairing it with a local model is what actually keeps inference off the network.
A current Node.js runtime, a small always-on host, and a model it can call. That is usually a hosted provider key, but a local runtime such as Ollama or a provider using an OAuth sign-in works too, so an API key is not a universal requirement. Installation is quick. The work that actually determines whether it survives is host isolation, channel access control, credential scoping, and backups.
Channel access. Because the interface is a chat app, anyone who can message a connected channel can attempt to instruct an agent that holds live credentials. Treat every connected channel as an untrusted input, restrict who can reach it, and keep approval gates on anything irreversible.
Yes, and for most people a small always-on VPS is the right host. It keeps the gateway reachable for scheduled and triggered work, which a laptop cannot do reliably. Prioritise sustained memory and a predictable network over raw CPU.
These pieces are usually decided together. Getting one right rarely helps if the one underneath it is fragile.
Tell us what you are trying to automate and what you have already tried. You will get a straight answer on the smallest responsible next move, including when the answer is to leave it alone.
Request a systems review