Evolution Host
Invent the Future
Self-hosting guide
Hermes works best when it stays online. A VPS gives it a persistent home for memory, messaging, automations and tool use, instead of relying on a laptop that sleeps, disconnects or gets shut down.
This page will show you how to install Hermes on Ubuntu and Debian, how to keep it running after reboot and what to secure before exposing it to the public internet.
Hermes can automate repetitive workflow steps, stay online for messaging integrations and give your AI agents a persistent home on a VPS.
Start here
Configuring Hermes correctly on the VPS from the start helps to avoid issues later on.
You want Hermes available over SSH with memory and tools, but no chat integrations yet.
Open the basic install pathYou want Hermes to stay online and respond through one or more messaging platforms.
Open the gateway pathYou want the fastest route using the official Hermes installer and native shell workflow.
Follow the Linux install pathYou want a low-cost box for one user, one provider and a small amount of persistent use.
Check sizing guidance firstYou want Hermes to survive logout, reboot and long uptime without manual restarts.
Open the persistence pathYou want Hermes reachable through channels or services and need to harden the VPS first.
Read the security pathA generic low-end VPS can be enough for testing, but once Hermes is expected to stay online, maintain memory, run scheduled work and handle messaging channels, you should treat it like a persistent service rather than a throwaway terminal session.
Context
Hermes Agent is an open-source persistent AI agent from Nous Research. It is designed to live on your machine or server, remember useful context across sessions, connect to messaging platforms through a gateway, and build reusable skills over time.
In practice, that makes Hermes a much better fit for a VPS than a normal local-only chatbot workflow. If you want an always-on agent that can stay available through CLI, Telegram, Discord, Slack or other channels, a VPS gives Hermes the persistent home it was built for.
Learn more on the Hermes agent site, or view the GitHub repository.
Deployment logic
Hermes can run locally, but a VPS is where it starts behaving like an always-on agent instead of a temporary local session. That matters once you care about uptime, memory continuity, scheduled work and messaging integrations.
A VPS keeps Hermes online after you close your laptop, disconnect SSH or go offline yourself. That makes it a better fit for persistent memory, gateway bots and unattended automations.
It gives Hermes a stable Linux environment, predictable uptime, fixed storage and a clean place to run as a service instead of a one-off shell process.
If you only want to test Hermes interactively for yourself and do not care about 24/7 availability, local install can be fine. The VPS becomes the sensible next step once persistence and availability matter.
Telegram, Discord, Slack and other channel integrations make more sense once Hermes has an always-on home instead of depending on your local machine.
You do not need a huge server to start. Hermes VPS intent is usually about persistence and availability first, not buying the most expensive plan on day one.
Sizing first
Hermes itself is lightweight enough to start small, but the right VPS size depends more on how often it runs, how many channels it connects to and how much tool work you expect it to do.
Channel integrations, long uptime, tool use, logs, background tasks and process supervision all push a deployment beyond a simple shell-only install.
A small VPS is fine for light interactive use. Once Hermes is expected to act like a service, the safer target is more RAM, some storage margin and room for updates, logs and channel adapters.
Use the guide below to size for your use case, then keep the first deployment simple. Upgrade only when your actual workload justifies it.
| Use case | Practical starting point | What it usually means |
|---|---|---|
| Single-user CLI only | 1 vCPU / 2 GB RAM | Good for testing, shell access and light personal use |
| One persistent bot channel | 1-2 vCPU / 2-4 GB RAM | Better for always-on operation with one gateway integration |
| Multi-channel Hermes setup | 2 vCPU / 4 GB RAM | Safer baseline for uptime, logs and several connected services |
| Heavier tool or automation use | 2-4 vCPU / 4-8 GB RAM | More headroom for persistent work and service-style deployment |
Use SSD or NVMe-backed storage where possible. Hermes is not storage-heavy by default, but persistent services, logs, updates and tool output are easier to manage on fast disks.
The goal is a stable deployment, not a giant server. Start with a clean Linux VPS and move up once your real workload shows you need more headroom.
OS choice
Hermes is a natural fit for Linux, and for most VPS users the real choice is not “can Linux run it?” but which Linux baseline gives you the setup style you want.
In practice, Ubuntu 22.04+ and Debian 12+ are both fine choices for a Hermes VPS. The stronger decision is usually not the distro itself but whether you are giving Hermes a clean, persistent environment with proper update and security habits.
Step 1 - Core install
The official Hermes quickstart is straightforward: connect to your VPS over SSH, run the install script, reload your shell, complete setup and then start Hermes.
You are installing Hermes into a Linux environment that will later hold your configuration, memory, provider setup and optional gateway services.
This is the fastest way to get Hermes running on a clean VPS. It gives you a working base install first, so you can confirm the environment is healthy before adding gateways, channels or other extras.
Once Hermes is installed, the next key decision is your provider and whether you want simple CLI use or a persistent gateway bot setup.
ssh root@your.server.ip
curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh | bash
source ~/.bashrc
hermes setup
hermeshermes setup walks you through provider configuration and the basic first-run experience. After that, hermes starts the interactive CLI.
If the installer finishes but hermes is not found, the shell environment often just has not been reloaded yet. Start by running source ~/.bashrc.
Step 2 - Model access
Hermes needs a provider before it can do useful work. That is part of setup, not a later optimisation step, so it belongs in the main deployment flow.
Hermes is the agent runtime, but the actual model responses still come through a configured provider endpoint.
If Hermes is installed but not responding properly, the provider layer is one of the first places to check rather than assuming the VPS itself is at fault.
Use the built-in setup flow first, then switch models or providers later once the base deployment is working cleanly.
hermes setup
hermes modelUse one provider and one working model first. Once the VPS deployment is stable, then add fallbacks, extra providers or more advanced routing choices.
A VPS deployment only feels complete once Hermes can actually answer requests consistently. The server is only one half of the setup; provider configuration is the other half.
Step 3 - Always-on channels
This is where a Hermes VPS starts making obvious sense. Gateway mode lets Hermes stay reachable through supported messaging platforms and services from one persistent server-side deployment.
A local machine can test Hermes, but gateway mode is far more useful when the agent stays online continuously and is not tied to your personal device.
If your goal is Telegram, Discord, Slack or multi-channel access, a VPS is usually the cleanest path because it gives Hermes the always-on runtime those channels expect.
Complete your install and provider setup first, then move into gateway configuration and service installation so Hermes starts automatically after reboot.
hermes gateway setup
hermes gateway
hermes gateway installUse gateway mode once Hermes needs to be reachable outside your SSH session, especially for bots, team workflows or persistent personal assistants.
Collect your platform tokens before you begin. A clean setup is easier when you already know which channels the VPS will host.
Gateway mode is one of the clearest reasons to target “Hermes VPS” as a search term. It connects the technical setup to a real hosting need: an agent that stays online and answers outside the terminal.
Step 4 - Persistence
A VPS is only useful for Hermes if the agent survives more than one shell session. That is why persistence matters as much as the initial install.
A manual terminal session ends when you disconnect. That is fine for testing, but not for an always-on assistant, bot or automation workflow.
If Hermes is meant to remain reachable, you want service management, supervised processes and restart behaviour that does not depend on an open shell.
Use the gateway install path for persistent service-style operation, then confirm Hermes restarts cleanly after reboot before treating the deployment as done.
Do not just confirm Hermes works once. Reboot the VPS, reconnect and verify that the expected services came back without manual intervention.
A laptop can demo Hermes. A VPS can host Hermes. That difference matters once uptime, memory continuity and channel availability stop being optional.
Step 5 - Hardening first
Once Hermes is attached to channels or exposed through service-style workflows, the VPS is not just a personal test machine anymore. Treat it like a real public-facing system.
Public exposure, unattended uptime, stored credentials and connected services all increase the cost of sloppy defaults.
SSH passwords, unnecessary open ports, skipped updates and weak process isolation are bigger risks than the initial install itself.
Lock down the server before you scale the deployment. It is easier to harden a clean VPS early than to untangle a messy public setup later.
Use SSH keys, disable weak login paths and avoid treating root password login as your normal operating model.
Only open what the deployment actually needs. A smaller exposed surface is usually a safer Hermes VPS.
Keep both the OS and Hermes updated, and use sane process boundaries or containers where appropriate for public-facing or more sensitive workloads.
If the VPS is going to host a persistent agent that talks to outside services, security is part of setup, not a later enhancement.
Troubleshooting
Most failed Hermes VPS installs are not mysterious. They usually come down to shell environment issues, missing provider setup, incomplete gateway configuration or expecting persistence from a process that was never installed as a service.
| Symptom | What it usually points to | What to check first |
|---|---|---|
hermes: command not found |
Shell environment has not reloaded | Run source ~/.bashrc and try again |
| Hermes opens but cannot answer | Provider not fully configured | Run hermes setup and confirm model/provider |
| Gateway starts once but not after reboot | No persistent service installation | Use hermes gateway install and test reboot behaviour |
| Bot is connected but not useful | Channel config, credentials or provider path is incomplete | Recheck gateway setup and provider configuration |
| VPS feels cramped under use | Box is sized for testing, not persistent workloads | Review RAM, storage and long-running workload expectations |
Most setup failures are not proof that Hermes needs a bigger server. First rule out missing setup steps, shell path issues and unfinished provider configuration.
A VPS deployment is not really finished until you know Hermes survives logout and reboot in the way you expect.
Common questions
No. You can install Hermes locally for testing or personal interactive use. A VPS becomes the better fit once you want always-on uptime, messaging integrations, scheduled jobs or a persistent home for the agent.
Ubuntu 22.04+ and Debian 12+ are both sensible choices. Ubuntu is often the easier default for many VPS users, while Debian is a strong fit if you want a stable and minimal server base.
For light CLI-only use, 2 GB RAM can be enough. For persistent gateway use or several connected services, 4 GB is a safer starting point. Heavy tool or automation workloads may justify more.
Yes for testing and light use. The real question is not whether it boots, but whether the VPS gives enough headroom for long uptime, logs, integrations and the workflow you expect Hermes to handle.
SSH into the server, run the official install script, reload the shell, then complete hermes setup. That is the fastest route from a clean Linux VPS to a working Hermes install.
Yes. That is one of the strongest reasons to host Hermes on a VPS. Gateway mode lets the agent stay online and respond through supported platforms without depending on your personal machine staying active.
A laptop is fine for local testing, but a VPS is better for uptime, reboot persistence, stable storage and service-style deployments. That matters once Hermes needs to stay reachable 24/7.
Start with SSH keys, firewall rules, update hygiene and limiting exposed services. Once Hermes is attached to outside channels or credentials, basic VPS hardening becomes part of the deployment itself.
Need an always-on home for Hermes
Give Hermes stable Linux hosting, predictable uptime and the headroom to stay online for memory, messaging integrations and 24/7 workflows.