How-To Guide
Deploy Hermes Agent on Any VPS — Complete Guide
Deploy Hermes Agent on a VPS, understand the hidden maintenance cost, and decide when FlyHermes is easier for gateways, memory, and agents.
Quick answer
Deploy Hermes natively with the official installer plus hermes gateway install, or use the official Docker image with host ~/.hermes mounted to /opt/data. Do not use an extra PM2 layer for the current native service or s6-supervised Docker image. Keep dashboard access private, back up the active HERMES_HOME, and verify one real Telegram/Discord delivery after every reboot.
Running Hermes on a VPS means your agent is always on — it works while you sleep, handles scheduled tasks, and stays connected to your channels 24/7 without draining your laptop battery.
Managed cloud · API costs included · Skill library · Cancel anytime
Before you start:
- ☑A VPS with at least 1GB RAM (DigitalOcean, Hetzner, Vultr — $5-6/month is sufficient without a local LLM)
- ☑SSH access to the server
- ☑The Hermes installer handles Node.js and Python automatically
- ☑For v0.16 remote backend and dashboard/admin surfaces, keep Web UI private and verify gateway delivery after every VPS restart
Steps
- 1
Provision a small Linux VPS
Start with a supported Linux host, SSH access, current system packages, and enough memory for your providers, gateways, and browser workloads.
- 2
Install and configure Hermes
Run the official installer, then
hermes setupandhermes doctor. Prove onehermes chat -qrequest works before starting an unattended service. - 3
Choose native service or Docker
Use
hermes gateway installfor the native system service, or the official Docker image with host~/.hermes:/opt/data. Do not stack PM2 on top of the native gateway service or s6-supervised container. - 4
Configure the gateway profile
Add only the provider and channel credentials needed by this VPS profile, set allowed chats/channels, and test topic/thread rules before broadening access.
- 5
Start and verify the native gateway
Run
hermes gateway start,hermes gateway status, andhermes status --all. For Docker, usedocker compose up -dand run the equivalent checks inside the container. - 6
Keep dashboard access private
Bind to loopback and use SSH/Tailscale, or configure Basic Auth, Nous OAuth, or OIDC. Current Hermes fails closed for a non-loopback dashboard without an auth provider.
- 7
Back up state and test recovery
Back up the active
HERMES_HOME, restart the VPS, then verify gateway status, dashboard/profile state, cron next-run times, and one real channel delivery.
Pro Tips
- 💡Set up a daily backup cron to copy ~/.hermes/ to S3 or rsync to another server — losing agent memory is painful
- 💡If Reddit-style setup pain sounds familiar — terminal prompts freezing, dashboard unreachable, Telegram not responding, or multiple bots sharing one server — compare the time cost against FlyHermes before hardening the VPS
- 💡If you enable the Hermes Agent dashboard / Web UI on a VPS, keep it behind HTTPS, auth, and firewall rules instead of exposing a raw admin port
- 💡The optional Web UI --tui browser Chat tab is useful for operators, but it increases the reason to keep the dashboard private because it exposes an interactive agent session.
- 💡If the real goal is dashboard visibility, Telegram/Discord uptime, or browser/mobile access without VPS upkeep, compare FlyHermes before expanding self-hosted infrastructure.
- 💡Use the Hermes dashboard/Web UI as a status checkpoint, but verify success with the real command, channel message, cron delivery, or deployed URL that matters.
- 💡Treat the dashboard port as an admin surface. Keep it on localhost or a private tunnel first; if you need public browser/mobile access without maintaining HTTPS/auth/gateway uptime, choose FlyHermes instead.
- 💡Weekly buyer-demand note (2026-06-22): recent GSC/dashboard searches, Reddit Claude Code monitor/cost threads, YouTube dashboard walkthroughs, and Discord gateway/support clusters all point to the same decision — self-host if you want control, but use FlyHermes when dashboard visibility, Telegram/Discord uptime, provider credits, and VPS maintenance are the work you do not want to own.
- 💡After deployment, open the Hermes dashboard privately to verify profile, provider, memory, cron, logs, and gateway state before relying on an always-on agent.
- 💡If the value you want is uptime, mobile access, and Telegram/Discord delivery rather than VPS maintenance, compare the setup against FlyHermes before adding more server plumbing.
- 💡Before declaring the workflow fixed, open the private Hermes dashboard, select the correct profile, check provider/model/gateway/cron state, and then verify the real channel or scheduled delivery path.
- 💡Write down the remote boundary before launch: dashboard/Desktop traffic uses port 9119, OpenAI-compatible API traffic uses 8642, and Telegram/Discord gateway delivery is verified separately. Do not expose all three by default.
Troubleshooting
❌ VPS firewall blocking Telegram webhooks
✅ Open port 8443 in your firewall: 'ufw allow 8443/tcp'. Alternatively use polling mode which doesn't require inbound connections.
❌ Dashboard or Telegram is unreachable after a VPS deploy
✅ Check the process manager, firewall, active Hermes profile, gateway status, and dashboard port before assuming the bot token is wrong. If you do not want to own this maintenance loop, use the pricing page to compare FlyHermes managed cloud against the VPS route.
❌ The VPS has two gateway processes or duplicate Telegram polling
✅ Choose one service manager. Stop the old PM2/manual process before using hermes gateway install/start, or run the single official Docker service. Then verify only one gateway owns the bot token.
FAQ
When does self-hosting Hermes stop being worth it?
Self-hosting stops being worth it when provider credits, uptime, Docker/VPS maintenance, gateway restarts, logs, backups, and security reviews cost more attention than the agent work itself. Keep self-hosting for control and custom infrastructure; use FlyHermes when managed uptime and mobile/channel access matter more.
Should I use PM2 to keep Hermes running on a VPS?
Not for the current recommended paths. Native installs use hermes gateway install/start, while the official Docker image uses s6 supervision plus Docker restart policy. Adding PM2 creates duplicate lifecycle ownership and can cause polling conflicts.
Which Hermes port should I expose on a VPS?
Usually none publicly. Keep the dashboard on loopback and use SSH/Tailscale. Desktop Remote Gateway uses the authenticated dashboard backend on 9119; the OpenAI-compatible API uses 8642 only when an external API client needs it.