A lot of people will install OpenClaw on a VPS because the install command is almost comically short. That is exactly why the security boundary is easy to miss. The project is a personal assistant that connects models, tools, sessions, and chat channels through one Gateway. If you expose that Gateway carelessly, an incoming message is no longer just text. It can become input to a tool-enabled process running on your host.

OpenClaw project banner

The useful question is not whether OpenClaw works. The README answers that. The useful question is whether your intended setup matches its trust model. The official security guide describes one user and one trust boundary per Gateway. It explicitly does not treat one shared Gateway as a safe tenant boundary for mutually untrusted users. That single sentence should decide how you deploy it.

Here is the setup I would use for a private, single-operator VPS. It keeps the first run boring, makes the control plane local to the machine, and gives you a clear stop sign before you connect a public channel.

A safe first deployment

Start with a fresh Linux VPS under a separate OS user. Do not put the Gateway on the same machine that holds your production database, private SSH keys, or unrelated automation. The point is containment. A cheap VPS is useful here because it gives the assistant a small room to work in. It is a bad bargain if that room also contains your whole life.

Check the runtime before installing anything. The current README lists Node 22.22.3+, 24.15+, or 25.9+ for the published package. Do not assume that the Node version from an old server image is good enough. Version drift is the sort of problem that appears only after the assistant has already become important.

The official installer for macOS, Linux, and WSL2 is:

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

If you already manage Node, the README also documents the package route:

npm install -g openclaw@latest --allow-scripts=openclaw
openclaw onboard --install-daemon

The onboarding command matters more than the install command. The project says onboarding verifies model access, creates the workspace, and configures the Gateway. After it finishes, check the service before adding any channels:

openclaw gateway status
openclaw dashboard

Use the dashboard to send one test message. Keep this first test on the local machine or through a private tunnel. I would not start with WhatsApp, Telegram, Discord, or a public reverse proxy. First prove that the Gateway starts, the model responds, the workspace is where you expect, and the daemon survives a restart.

Then run the project's own audit:

openclaw security audit
openclaw security audit --deep

The second command is the one I would treat as a release gate for the first deployment. Together, these are 2 audit commands, and I would run both before opening a channel. The security documentation describes it as a live Gateway probe, not a decorative status command. Run it again after every change to remote access, channel policy, plugins, or sandbox settings. Save the output with the rest of your server notes so you can tell what changed.

The next step is pairing. OpenClaw's README says DM-capable channels pair unknown senders by default. That is a sensible starting policy, but it is not permission to throw the Gateway onto the public internet. Approve only the sender you intend to use, and treat every message that reaches the assistant as untrusted input. A pairing code identifies a sender. It does not turn that sender into a trusted system administrator.

Before enabling a tool that can execute commands, read the sandboxing documentation and decide where execution is allowed. The security guide calls out a common policy drift problem: an operator may believe a sandbox is active while the effective execution mode is different. That is a configuration bug, not a philosophical detail. If you cannot explain which user, directory, container, or host receives a tool call, you are not ready to expose the channel.

My first useful workload would be something with a narrow workspace, such as summarizing a folder of notes or turning a private RSS feed into a draft. I would grant read access to that one directory, keep write access off, and watch the logs for a day. The goal is to learn what the assistant actually does when the prompt is messy. Demo prompts are too polite.

What broke in this setup? The first temptation is to add every channel during onboarding because the connection wizard makes it easy. That creates a much larger input surface before you know whether the local control plane is stable. The second temptation is to install plugins until the assistant feels magical. Every plugin adds code and configuration to a machine that may already have broad tool access. Start with fewer capabilities than you think you need, then add one at a time.

What breaks when you expose it

The most dangerous mistake is treating the Gateway like a normal web app. The official security guidance says authenticated operator access is a trusted control-plane role. It also says a shared Gateway is not a tenant boundary for adversarial or mutually untrusted users. Those statements rule out a lot of casual architectures.

A public URL plus a chat channel is not automatically a safe personal assistant. If several people can message one tool-enabled agent, they may share the agent's delegated authority. If an attacker can influence the prompt and the agent can reach shell commands, files, browsers, or network services, the assistant becomes a relay between an untrusted message and your host. The model can be clever and still make a terrible security boundary.

This is where the small VPS decision becomes useful. A separate host does not make the configuration safe, but it limits the cost of getting the configuration wrong. Use a dedicated OS user. Keep secrets out of the workspace. Do not mount your home directory into a container just because it makes file access convenient. Do not put cloud credentials with broad permissions in an environment that the agent can inspect.

Remote access deserves its own decision. If you only need private access from your own devices, use a private network or an access layer with an explicit identity policy. If you need a public endpoint, follow the project's Gateway exposure runbook instead of improvising a reverse proxy from a random tutorial. The security docs list remote gateway setup, stable HTTPS URLs, Tailscale, Cloudflare Tunnel and Access, network proxy controls, pairing, sandboxing, and rate limits as separate concerns. A TLS certificate solves encryption in transit. It does not solve authorization or tool abuse.

The failure mode I would watch for is policy drift after a successful demo. Someone enables a plugin, changes a tool profile, turns on remote access, or moves the workspace into a synced folder. The assistant still answers messages, so the change feels harmless. The trust boundary has changed anyway. Run the deep audit after that change, then inspect the effective configuration rather than the setting you remember editing.

There is also a deployment choice that should be made plainly: do not use one Gateway as a multi-user service unless you have intentionally built the isolation around it. The official model is 1 user per Gateway and one trust boundary around that user. Several independent users should get separate Gateway cells, and ideally separate OS users or hosts. If that sounds expensive, the honest answer is that a shared tool-enabled assistant is expensive in a different way.

The rollback plan should be simple enough to use while tired. Disable the channel or private endpoint. Stop the Gateway daemon. Revoke any credentials the assistant could read. Preserve the audit output and logs. Rebuild the workspace from a clean copy if you cannot explain what changed. Do not keep chatting with the compromised instance while trying to persuade it to behave.

The decision I would make

For a personal assistant, I would run OpenClaw on a small, separate VPS, keep the Gateway private during setup, complete onboarding, run both audit commands, and connect one paired channel only after the audit is clean. I would give it a narrow workspace and add tools gradually.

I would not put it in front of a team chat and call the channel boundary security. I would not share one Gateway between users who do not share the same trust level. I would not expose a tool-enabled Gateway before reading the exposure and sandboxing guides. The project itself tells you why: the Gateway is a control plane, and the tools run on the host unless you configure isolation.

Try this tomorrow: create a disposable VPS, install the supported Node version, run onboarding, and stop before adding a channel. If the deep audit produces findings you cannot explain, you have already learned something valuable without giving a stranger a shell.

Sources