Running a self-hosted AI agent (OpenClaw, Hermes) on your VPS

What this is#

A new class of tool arrived in 2026: the persistent, self-hosted AI agent. Unlike a chatbot you visit, or Claude Code which lives in your terminal for the length of a session, these run as an always-on background service. They keep their own memory across sessions, write and reuse their own "skills", and you reach them through a web control panel and messaging apps (Telegram, Discord, Slack, and others). A VPS is the natural home for one, it's online 24/7, it's yours, and your data stays on it rather than on someone else's cloud.

The two most prominent open-source examples as of mid-2026:

• OpenClaw (openclaw/openclaw, previously known as Clawdbot and Moltbot). A personal assistant with a browser control UI and a broad plugin ecosystem.
• Hermes Agent (Nous Research). Built around persistent memory and self-authored skills that follow an open agentskills.io standard, with a single gateway process fronting the messaging integrations.

Both are open source and free to run; you supply the intelligence behind them (see below). This guide is product-neutral, the setup shape and, crucially, the security posture are the same for these and the agents that will follow them.

Before anything else: the security reality#

This is the most important section on the page, so it comes first. These agents run a control panel as a network service (OpenClaw's, for instance, listens on port 18789), and that panel can do anything the agent can do: run commands, spend your API credits, read the credentials it has stored. In 2026, security firms found tens of thousands of these control panels exposed directly to the public internet with authentication left off, many of them trivially takeoverable, and multiple remote-code-execution vulnerabilities have been published against exposed instances. Infostealer malware now specifically hunts for these agents' files, because their configuration, memory, and chat logs routinely store API keys and passwords in plain text.

None of that is a reason to avoid them. It's a reason to run one correctly, which is genuinely easy:

• Keep the control panel bound to localhost (127.0.0.1). This is the default on current versions, don't change it to 0.0.0.0 (all interfaces) for convenience. A panel bound to localhost cannot be reached from the internet at all, which removes essentially the entire attack surface above.
• Reach it over an SSH tunnel, not an open port. To use the panel from your laptop, forward it through SSH: ssh -L 18789:localhost:18789 [email protected], then open http://localhost:18789 in your local browser. Traffic rides your existing encrypted SSH connection; nothing new is exposed. This is the recommended pattern and it needs no firewall changes.
• Never open the panel's port in a firewall or publish it. If you find yourself running ufw allow 18789 or putting the panel behind a bare public IP, stop, that's the exact mistake behind the mass compromises. If you genuinely need browserless remote access for a team, put it behind a reverse proxy with HTTPS and a strong gateway token (openssl rand -hex 64), never the raw port.
• Treat the machine's secrets as exposed if the agent is. Because keys are stored in cleartext, an agent compromise is a credential compromise. Use scoped, revocable API keys, and rotate them if anything looks off.

The rest of this page assumes you're following the localhost-plus-SSH-tunnel pattern.

Resource requirements: two very different answers#

The honest answer depends entirely on where the model runs, and this is where people over- or under-buy:

• The agent software itself is light. It's a Node.js process (these need Node 22 LTS or newer) plus its memory store. Figure a 2-core, 4 GB VPS with room for the OS, comfortable on any current entry Linux plan, and perhaps 50 to 100 GB of disk if it accumulates a lot of files or logs.
• If you point it at a cloud model API (Anthropic, OpenAI, OpenRouter, and similar), that's all you need. The heavy lifting happens on the provider's servers; your VPS just orchestrates. This is what the projects themselves recommend starting with, and it's the right default.
• If you run the model locally (via Ollama or similar, for zero per-token cost or full privacy), the model's RAM becomes the dominant requirement, and it's large. As a rule of thumb, with the common Q4 quantization: a 7-8B model (Qwen, Mistral Small, and the like) wants ~8 GB RAM all to itself; a 30B+ model wants 16 GB and up. A CPU-only VPS runs these, just slowly; responsiveness improves dramatically with more RAM and, if available, a GPU. Size the plan for the model, not the agent.

In short: cloud API → an entry plan is plenty. Local model → buy RAM for the model. Don't provision a large VPS "for the AI" if the AI is actually running in Anthropic's datacenter.

Installing (as a non-root user)#

The same safety rule as Claude Code applies: run the agent as your everyday sudo user, not root, so a mistake or a compromise is contained to that user rather than owning the box.

Both projects install with a one-line script that fetches Node and their dependencies:

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

# Hermes Agent
curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash

A note on curl … | bash: piping a script straight into a shell means running whatever that URL serves, sight unseen. It's the projects' official method, but the careful habit is to fetch the script first, read it, then run it (curl -fsSL <url> -o install.sh; less install.sh; bash install.sh), especially on a server that holds anything you care about. (OpenClaw also publishes an npm package and Docker images if you prefer those.)

After install, start the gateway/agent per the project's docs, connect your model provider (API key or local Ollama endpoint), and open the control panel through your SSH tunnel to finish setup, linking messaging accounts, granting the permissions you actually want it to have, and no more.

Keeping it healthy on a server#

• Run it under a process manager so it survives reboots and dropped sessions, a systemd service is the clean way; tmux works for a quick trial. Don't leave it tied to an interactive SSH session that dies when you disconnect.
• Give it least privilege. Grant the agent only the integrations and permissions it needs for what you actually use it for. An agent with your email, your shell, and your cloud keys is a large blast radius if it misbehaves or is breached.
• Watch the resources. An agent looping on a task, or a local model, can saturate CPU or RAM; the Graphs tab shows it, and a runaway local model is the classic cause of a small plan going unresponsive.
• Keep it updated. These projects move fast and patch security issues often; update on the project's cadence, the published vulnerabilities above were all against out-of-date, exposed instances.

Still need help?#

Running these is self-managed software, so the specifics live in each project's own documentation, but if the VPS itself is unreachable or misbehaving, open a support ticket. So we can help on the first reply, it's worth mentioning:

• the VPS hostname or IP,
• what you installed and how you're reaching its panel (SSH tunnel, or, we hope not, an open port),
• what the Graphs show if it's a resource problem.

Related questions#

• "Can I run OpenClaw or Hermes Agent on my VPS?"
• "How much RAM do I need for a self-hosted AI agent?"
• "How do I access the AI agent's control panel safely?"
• "Is it safe to expose port 18789 to the internet?" (No.)
• "Do I need a big VPS to run an AI agent?"
• "Should I run the AI model locally or use an API?"
• "How do I keep my AI agent's API keys from being stolen?"