How to deploy OpenClaw on your own VPS

What deploying OpenClaw actually means

A working OpenClaw deployment is four things bolted together. You have the runtime itself, which is a Node.js process reading a workspace directory. You have at least one channel pointed at it, which is how the agent receives messages. You have a set of skills, which are the capabilities the agent can actually use. And you have credentials scoped tightly enough that a compromise of one skill does not leak the credentials of another.

Most people get the first part working in an hour and then spend a week fighting the other three. Specifically: they run the onboard command, see the agent respond on Telegram, and declare victory. Then they try to add Gmail and Asana and discover they put every token in one global .env file. Then they try to wire it into a group chat and discover they did not sandbox untrusted input. Then an agent run goes sideways and takes down the gateway because systemd was not configured to restart it. This guide is the order I do it in to avoid all of that.

Infrastructure requirements

OpenClaw itself is light. The expensive part is the model provider you point it at, which runs remotely and is not part of the VPS sizing question. On the VPS side, you are sizing for the Node.js runtime, a small amount of local state, and headroom for whatever skills you load.

Minimum viable VPS

• CPU: 2 vCPU is the floor I would actually deploy on. 1 vCPU works in demos and then stutters the first time two messages arrive in the same second.
• RAM: 4 GB. Node.js with a loaded workspace plus a channel or two sits around 500 MB idle and spikes higher during skill execution.
• Disk: 40 GB SSD. OpenClaw state is small but logs accumulate, and if you add anything that touches local files (transcription, document processing) you want room.
• Bandwidth: Any cheap plan is fine. Agent traffic is almost all outbound API calls to the model provider, measured in kilobytes.
• OS: Ubuntu 22.04 LTS or 24.04 LTS. Debian 12 also works. I avoid Amazon Linux and CentOS derivatives for this because the systemd and Node.js packaging are less predictable.

This sizing costs about $20 per month at Hetzner, DigitalOcean, or Linode. On AWS you will pay closer to $30 once you include EBS and bandwidth. The model provider is a separate bill. A low-volume workspace running Claude at xhigh thinking effort usually sits under $30 per month in Anthropic costs and goes up from there with usage.

What you do not need

• You do not need a public IP with open inbound ports for the agent itself. OpenClaw is outbound-only: it opens a socket to Telegram or Slack, then listens on that socket. No inbound firewall rules are required.
• You do not need a domain name unless you are also hosting a dashboard or webhook receiver. For a pure chat agent, just the VPS is enough.
• You do not need Docker. OpenClaw runs as a plain Node.js process under systemd. A container adds a layer of ops without solving a real problem for this workload.

Installation in six phases

This is the exact order I follow when I set up a new client workspace. Each phase is a checkpoint. If a phase breaks, fix it before moving on, do not paper over it.

Phase 1. VPS preparation

SSH in, confirm Node.js 20 or newer is available, confirm npm is available, and create the directory where the workspace will live. I put workspaces under /home/ubuntu/ on personal servers and under /opt/openclaw/ on client servers where a non-login user owns the process.

Phase 2. Install the CLI

Install openclaw globally with npm. If the global install lands in a directory not on PATH, add it explicitly in the shell rc file. The CLI ships with an onboard subcommand that does the heavy lifting.

Phase 3. Run the non-interactive onboard

Run openclaw onboard --non-interactive --accept-risk --workspace <path> --mode local. This creates the workspace with SOUL.md, IDENTITY.md, AGENTS.md, TOOLS.md, USER.md, and HEARTBEAT.md, writes a starter openclaw.json in ~/.openclaw/, and registers a gateway systemd service. Verify the gateway starts with systemctl status openclaw-gateway before moving on. This is the stop point. If the gateway does not come up cleanly here, nothing else will work.

Phase 4. Configure the model provider

OpenClaw supports multiple providers, but I only deploy with Anthropic. Every time I have shipped a mixed-provider fallback chain for a client, the weaker provider silently degrades quality during a real production incident and the client does not notice until a user complains. Pick Claude, stay on Claude.

Two options for Anthropic auth. Either a Claude subscription token from claude setup-token, which requires an interactive browser step, or a raw Anthropic API key. Subscription tokens are cheaper per month for a single agent with reasonable usage. API keys scale linearly with tokens. For client deployments I usually use an API key because the billing is cleaner.

Primary model: claude-opus-4-6. Fallback: claude-sonnet-4-6. Thinking: xhigh. No non-Anthropic fallbacks. Put these in the provider block of openclaw.json.

Phase 5. Connect channels

Channels are how the agent receives input. The three I deploy most often:

• Telegram is the fastest to set up. Get a bot token from @BotFather, paste it into the channel block, and set dmPolicy: "pairing" with allowFrom containing your Telegram user ID. Five minutes.
• Slack needs two tokens, not one. A bot token starting with xoxb- and an app-level token starting with xapp- with the connections:write scope. The app-level token is the thing everyone misses on the first install. You generate it at api.slack.com under App, Basic Information, App-Level Tokens. Without it, socket mode silently fails to connect.
• WhatsApp uses Baileys under the hood. No official API account needed. First run pops a QR code in the terminal that you scan with the WhatsApp app on your phone. The pairing state persists on disk, so subsequent restarts are automatic. WhatsApp has the highest maintenance overhead of the three because Meta occasionally invalidates pairings.

Phase 6. Install skills

Skills are individual capabilities the agent can use. Each skill lives in <workspace>/skills/<skill-name>/ with a SKILL.md describing its purpose and tools. Only install skills the agent actually needs. Every unused skill is attack surface and token bloat in the system prompt.

The credential isolation rule: every skill credential goes in the workspace .env file, not the global one. A Gmail agent does not get Asana tokens. A Thai study agent does not get Airtable credentials. This is the boundary that matters if a single skill gets compromised, because the blast radius is scoped to one workspace.

Production hardening

This is the section that separates a running agent from a deployable one. Skip this and the first incident will take down the whole thing.

• Sandbox untrusted input. Set sandbox.mode: "non-main" in openclaw.json. This runs group chats and webhook traffic in a sandboxed execution context. Direct messages from allowlisted users run in main. Everything else is sandboxed by default.
• Exec allowlist. Set tools.exec.security: "allowlist" and maintain an explicit allowlist of shell commands the agent can run. Allowing arbitrary exec in production is how agents end up rm -rfing things. I have watched this happen. The allowlist is boring to maintain and worth every minute.
• Channel allowlists. Every channel should have dmPolicy and allowFrom set explicitly. Telegram bots are discoverable by anyone with the username. If you do not scope the allowlist, strangers will find your agent and burn your model provider bill.
• Auto-restart. The gateway service ships with systemd integration. Confirm Restart=on-failure and RestartSec=10 in the unit file. The agent will occasionally crash on edge-case inputs, and an auto-restart of 10 seconds is invisible to users.
• Log rotation. Add a logrotate config for the OpenClaw logs. A chatty agent on a small disk will fill it in a week without rotation.
• Backups. The workspace directory is the state. Snapshot it with the VPS provider daily and you can restore an agent in ten minutes.

Common pitfalls I see on client handoffs

These are the five things that break most often when someone deploys OpenClaw without walking through the phases above.

1. Missing Slack app-level token. The bot token alone is not enough. Socket mode will not connect. The error surface is quiet, which is the worst kind of quiet.
2. Global .env for every skill. Every agent ends up with the same credentials. When the time comes to revoke one, you revoke everything at once and every workspace goes down.
3. Exec security left at the default. On a fresh install, tools.exec.security is permissive. Deploying to production without flipping it to allowlist is a footgun. Set it before adding any skill that uses the exec tool.
4. Gateway service not enabled. The systemd unit exists but systemctl enable openclaw-gateway was never run. First reboot and the agent is gone until someone notices.
5. Non-Anthropic fallback. Someone adds an OpenRouter or Kimi fallback thinking it is free resilience. The fallback kicks in during a real incident, responses get silently worse, users notice, you get a support ticket you cannot easily reproduce.

Running cost in practice

For a single agent handling a few dozen messages a day on a 2 vCPU / 4 GB VPS with Claude Opus as primary and Sonnet as fallback, I see monthly bills in this range:

• VPS: $20 at Hetzner or DigitalOcean, about $30 at AWS with EBS and bandwidth included.
• Anthropic: $20 to $60 depending on how heavily the agent actually thinks. xhigh thinking effort is more expensive per message but the quality difference is visible and worth it for production work.
• Channels: Free. Telegram, Slack, and WhatsApp via Baileys have no usage fees.
• Domain: $10 to $20 per year if you want one. Not required.

Total all-in: $50 to $100 per month for a single production agent. Scale is linear with the number of agents, not with the number of users, because most of the cost is the model provider billed per token and that tracks usage rather than seat count.

When you should hire a consultant instead of doing it yourself

I wrote this guide because most of OpenClaw is learnable. If you have a patient afternoon and a Linux VPS, you can follow the phases above and end up with a running agent. For a personal assistant use case, that is usually enough.

There are three situations where hiring a consultant pays for itself. First, when the agent is going to handle workflows that matter financially, hiring someone who has already made the security mistakes for other clients is cheaper than making them yourself. Second, when you need custom skills written for systems that do not have an off-the-shelf integration, skill development is where the knowledge asymmetry is highest. Third, when you have an in-house engineering team that will be maintaining the system, a one-day hands-on build alongside the team shortcuts weeks of reading.

If none of those apply, use this guide and you will be fine. If any of them do, the first consultation call is free anyway, and the worst case is you get a second opinion on your plan.

Related

• OpenClaw Consultant, James Ferrer (home)
• Services and pricing
• Frequently asked questions
• NemoClaw consulting for sandboxed enterprise deployments
• James Ferrer, OpenClaw consultant (personal site)