OpenClaw on VPS: Complete Self-Hosting Guide 2026

OpenClaw is one of the most exciting trends in self-hosting right now: an autonomous AI assistant that does more than chat. It can process messages, keep stateful memory, run scheduled actions, and trigger real workflows.

That power changes the hosting requirements. Once an agent can access channels, tools, and potentially shell commands, "it runs on my laptop" is not a production strategy. You need uptime, isolation, and strict security boundaries from day one.

This guide walks you through a full OpenClaw VPS setup: architecture decisions, hardware sizing, installation options, channel onboarding, hardening, and realistic operating costs.

1. What is OpenClaw?

OpenClaw is an open-source AI assistant project from the Peter Steinberger (@steipete) ecosystem and adjacent agent tooling community. The broader repos around this space have grown rapidly and are frequently cited at 186k+ combined stars.

What makes OpenClaw different from a normal chatbot:

• It connects LLMs to real channels like WhatsApp, Telegram, Discord, iMessage, and Slack.
• It supports proactive behavior (memory + scheduled jobs + follow-up actions).
• It can be extended via skills and integration modules (often discussed as marketplace-style workflows).

This is where value and risk meet. A plain chat UI is mostly text processing. An agent with tool access behaves more like an automation runtime. Treat it like infrastructure, not a toy app.

2. Why VPS instead of local?

Local hosting (Mac Mini, Raspberry Pi, home server) is fine for prototyping, but production AI agents are more reliable on VPS.

If your agent is channel-first, uptime is not optional. A VPS gives you stable inbound events and predictable operation when your local machine is offline.

3. Hardware Requirements

Resource usage depends mainly on:

1. Number of concurrent channels
2. Team size and interaction volume
3. Cloud API vs local LLM inference
4. Side workloads (queues, logs, browser automation, plugins)

Practical sizing profiles

Important caveat: update-time RAM spikes

Many OpenClaw environments need much more memory during update/preflight build steps than during normal runtime. That's why 4 GB instances can fail with OOM during upgrades.

Set swap early (2-4 GB minimum):

sudo fallocate -l 4G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

4. Installation

You can deploy OpenClaw in three common ways. For production, Docker with strict network boundaries is usually best.

Option A: Manual install (maximum control)

Requires Node.js 22+

# Install Node 22 (Ubuntu example)
curl -fsSL https://deb.nodesource.com/setup_22.x | sudo -E bash -
sudo apt-get install -y nodejs build-essential

# Global OpenClaw install
sudo npm install -g openclaw

# Onboard + daemon install
openclaw onboard --install-daemon

Validate:

systemctl status openclaw
openclaw --version

Pros: full transparency. Cons: more manual lifecycle work.

Option B: Docker (recommended)

Critical point: keep gateway port local-only at first.

services:
  openclaw:
    image: ghcr.io/openclaw/openclaw:latest
    container_name: openclaw
    restart: unless-stopped
    environment:
      - NODE_ENV=production
      - OPENCLAW_HOME=/data
      - GATEWAY_AUTH_TOKEN=${GATEWAY_AUTH_TOKEN}
    ports:
      - "127.0.0.1:3434:3434"
    volumes:
      - ./data:/data
      - /var/log/openclaw:/var/log/openclaw
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:3434/health"]
      interval: 30s
      timeout: 5s
      retries: 5

Start and inspect:

docker compose up -d
docker compose logs -f --tail=100

Option C: One-click templates

Some providers expose OpenClaw-like templates in their marketplace stacks. Great for quick experiments, but always verify:

• Is gateway access exposed publicly?
• Is auth token configured by default?
• Is backup/update behavior documented?

If those answers are unclear, deploy your own compose stack.

5. Connecting channels

Telegram (fastest path)

1. Open @BotFather
2. Run /newbot and create token
3. Store token in OpenClaw secrets
4. Invite bot to the target chats/channels

WhatsApp (QR-based session)

1. Enable WhatsApp connector
2. Pair using QR code
3. Persist session state in durable volume
4. Test reconnect behavior after restart

Discord

1. Create app in Discord Developer Portal
2. Generate bot token
3. Enable required intents only
4. Invite bot with least-privilege permissions

Operational tip: stabilize Telegram first, then add WhatsApp/Discord to isolate integration issues.

6. Security (most important section)

An AI agent with channel and tool access is part of your attack surface. These controls are baseline requirements.

6.1 Never expose gateway publicly

Avoid raw public binding without controls.

Use instead:

• SSH tunnel for administrative access
• Tailscale/WireGuard private overlay
• Reverse proxy with IP allowlists + auth + rate limits

SSH tunnel example:

ssh -N -L 3434:localhost:3434 user@your-vps

6.2 Always set gateway.auth.token

No open gateway, even internally.

GATEWAY_AUTH_TOKEN=long-random-high-entropy-token

6.3 Harden firewall with UFW

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp
sudo ufw allow from 100.64.0.0/10 to any port 3434  # Example: Tailscale range
sudo ufw enable
sudo ufw status verbose

6.4 Use dedicated service identities

• No root process identity for the agent
• No personal tokens in production runtime
• Separate technical accounts per integration

6.5 Prompt injection is not theoretical

Community incident reports already show unsafe tool execution after malicious prompt/context injection (including destructive side effects such as unwanted mailbox actions). Assume this can happen.

Mitigate with:

• strict tool allow/deny lists
• approval gates for destructive actions
• scoped credentials with minimal permissions
• auditable logs and alerting on risky actions

6.6 Model choice for safety-sensitive workloads

For high-risk agent workflows, many teams currently favor models with stronger prompt-injection resistance. In practice, Claude Opus 4.5 is often recommended for this reason. Model choice helps, but architecture controls are still mandatory.

6.7 Minimum production baseline (checklist)

For real production usage, your OpenClaw stack should include at least:

• Network boundary: Gateway reachable only internally (localhost + tunnel/VPN).
• Authentication: Strong gateway token with regular rotation.
• Secrets hygiene: No plaintext secrets in Git; use .env + secret store.
• Least privilege: Dedicated technical identity per integration.
• Action guardrails: Destructive actions require explicit confirmation.
• Audit logging: Store prompt context, tool call, timestamp, and result.
• Alerting: Notify on suspicious behavior (e.g., sudden high tool-call bursts).
• Backups: Daily backup of config, session state, and memory data.

A practical small deployment can stay simple:

1. openclaw container (runtime)
2. reverse-proxy container (internal-only or VPN-protected)
3. optional log-shipper for centralized logs
4. backup-cron for daily snapshots

You do not need enterprise complexity to be safe. But you do need multiple boundaries. In agent systems, safety comes from layers, not from one single toggle.

7. Cost comparison

OpenClaw can be cost-efficient, but only if you include both infrastructure and model/API spend.

If you need channel integrations and operational control, self-hosting usually wins on flexibility per euro.

Realistic monthly scenarios

Many teams underestimate not VPS pricing, but variable model usage. These planning scenarios are useful:

Key tradeoff: local LLMs reduce API spend but increase infrastructure requirements (RAM/CPU, sometimes latency on CPU-only hosts). For many deployments, hybrid routing is best: local for standard tasks, cloud API for complex reasoning.

Hidden costs to account for

• Operations time: updates, incident handling, monitoring
• Backups: snapshot storage or remote backup destination
• Security maintenance: token rotation and access reviews
• Downtime impact: if the agent is integrated into core workflows

These costs do not invalidate self-hosting. They simply make budgeting realistic.

Live VPS offers for OpenClaw-style workloads

Anbieter	Produkt	vCPU	RAM	Storage	Preis/Mo
	VPS 500 G12	2	4 GB	128 GBSSD	5.91	Angebot
	CPX42	8	16 GB	240 GBNVMe SSD	30.33	Angebot
	AMD Ryzen 12 Cores	12	64 GB	1000 GBNVMe SSD	102.82	Angebot

8. Troubleshooting (Top 5)

1) gateway.lock blocks restart

Symptom: process does not come back after crash/update.

rm -f /opt/openclaw/data/gateway.lock
systemctl restart openclaw

2) WhatsApp Error 515

Symptom: repeated disconnects or QR pair loops.

Fix:

• update connector/runtime
• verify persistent session volume
• re-pair cleanly and tune reconnect/backoff

3) OOM during updates

Symptom: container/process killed during build step.

Fix:

• enable swap
• reduce parallel build pressure
• move to 8 GB RAM for frequent upgrades

4) Missing config after interrupted onboarding

Symptom: startup fails because expected config/secret files are incomplete.

Fix:

• wipe broken config directory
• rerun onboarding cleanly
• backup regenerated secrets immediately

5) Discord rate limiting

Symptom: delayed replies or intermittent API errors.

Fix:

• queue outbound actions
• implement exponential backoff
• add per-channel cooldown policies

Bonus: backup and rollback strategy

If OpenClaw supports production workflows, define rollback before updates:

1. Before every update: snapshot data/ + .env
2. Update window: deploy with active log tailing
3. Smoke tests: health endpoint, Telegram ping, Discord test message
4. Fast rollback path: be ready to restore within minutes

Minimal backup command:

tar -czf openclaw-backup-$(date +%F).tar.gz ./data ./.env docker-compose.yml

This gives you a quick, practical recovery baseline for most single-VPS deployments.

First-week launch checklist

For the first 7 days after go-live, run a short daily operations check:

• Day 1-2: Validate channel reconnect behavior after restarts.
• Day 3-4: Review latency spikes and API error rates at peak load.
• Day 5-6: Intentionally test malformed inputs to verify guardrails.
• Day 7: Audit logs and tune cooldowns, timeouts, and rate limits.

This small operating loop catches weak spots early before they become stability or security incidents.

9. Conclusion

OpenClaw on VPS is one of the highest-leverage setups you can build today for practical AI assistants: always-on, multi-channel, and fully under your operational control.

The deciding factor is not installation speed, but safety architecture: private gateway, strong auth, least privilege, and clear observability from day one.

Starting small is not a weakness. In practice, a hardened 4 GB deployment is more valuable than an overprovisioned but weakly secured 16 GB setup. Prioritize reliability and control first, then scale based on measured load.

If you're unsure about sizing, start with the calculator and scale from real traffic.

That way, you build an agent that is not only impressive in demos, but dependable in daily operations.