# Running a self-hosted AI agent (OpenClaw, Hermes) on your VPS
Source: https://vpsdime.com/knowledgebase/getting-started/self-hosted-ai-agents
Last reviewed: 2026-07-04
Summary: A VPS is a natural home for a persistent, self-hosted AI agent like OpenClaw or Hermes Agent, an always-on assistant with its own memory and a web control panel, reachable from Telegram, Discord, and the like. This covers what they are, honest resource requirements (the agent itself is light; a local model is the RAM-heavy part), how to install them as a non-root user, and the one thing that has compromised tens of thousands of these deployments: exposing the control panel to the internet. Keep it bound to localhost and reach it over an SSH tunnel.

## 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](https://vpsdime.com/knowledgebase/getting-started/claude-code-on-vps) 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](https://github.com/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](https://github.com/nousresearch/hermes-agent)). 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 you@YOUR.VPS.IP`, 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](https://vpsdime.com/knowledgebase/getting-started/one-click-applications) 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](https://vpsdime.com/knowledgebase/getting-started/claude-code-on-vps) applies: run the agent as your **[everyday sudo user, not root](https://vpsdime.com/knowledgebase/getting-started/first-30-minutes)**, 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](https://vpsdime.com/knowledgebase/client-area/services/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](https://vpsdime.com/open-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](https://vpsdime.com/knowledgebase/client-area/services/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?"