How to Run a Free AI Agent on Your VPS with Hermes

I have an agent running 24/7 on a VPS I was already paying for and barely using. It sends me an AI and software news digest every morning through Telegram, it searches Reddit for people who have the problem I solve, and it costs me zero dollars per month on top of the server. Not a trial, not a credit balance that will run out next week. Zero, because the model runs on OpenRouter's free tier and Telegram is free.

This post is the setup, and then the two places where it broke in production, which is the part most write ups skip.

Why self hosted, and when it is the wrong call

Most autonomous agent platforms right now charge a monthly subscription and then limit you twice: execution windows and token consumption. You are buying something described as always on and you are getting a shift. If your use case is a daily cron and a lead monitor, those two limits are exactly the ones that hurt.

Hermes is open source, ships as a Docker image, and runs on your own box. The important architectural detail is that the model itself does not run on your server. Inference stays on OpenRouter's infrastructure, so a small VPS is enough. You are hosting the orchestration, the memory and the tools, not the weights.

The honest counterargument: this is not free, it is unbilled. When the bot stopped answering there was no support, there was a gateway to restart. When the search broke there was no ticket, there was a script to open. If nobody on your side administers a server, the subscription with limits is the correct decision.

The architecture in one paragraph

Multiple channels (Telegram, Slack, Discord, email) enter through a single gateway. Behind the gateway sits a main agent that acts as orchestrator: it reads intent and dispatches to sub agents, each one with a narrow responsibility and its own toolset. In my instance the relevant sub agent is called Radar, and its only job is finding potential clients. Memory is persistent across channels, so the session is about you, not about the app you happened to open.

Two rules I would apply on any instance, and I will come back to the second one:

• The orchestrator decides, the sub agents execute. One responsibility each.
• A sub agent with internet access should not have terminal access.

Setup

The deploy itself is not the interesting part, so, short version:

1. Provision a VPS (I use Hostinger and their template catalog has a Hermes image, so it is a one click container). Set the dashboard username and password at creation time.
2. Create an OpenRouter API key. If you are on Windows, check for trailing spaces after you paste it, this cost me a confused ten minutes.
3. Run the full setup wizard, choose OpenRouter as provider, and pick a free NVIDIA Nemotron model as your main model. Configure a fallback for when the free tier is under load.
4. Keep terminal execution local. There is no reason to route it elsewhere.
5. Connect Telegram through BotFather rather than the QR flow. The QR flow uses your personal account, which is fine for a personal assistant and wrong for anything that other people will talk to.
6. Restrict the channel to your Telegram user id. On a free model this protects your instance, on a paid model it protects your wallet.
7. Restart the gateway. Channels do not pick up until you do.

From there you talk to it. Asking for a daily report in plain language is enough for it to write the cron itself:

me: generate a daily cron at 9am that runs this lead search
agent: created. runs 09:00 UTC daily, writes results to the board and
       sends the digest through telegram

That is the genuinely new part. I did not write a scheduler, I described an outcome.

The Radar profile

The sub agent is created the same way, by describing it. What matters is what goes into the description, and it is not the tone, it is the constraints:

• The ICP in specific terms. Mine: people integrating Twilio, WhatsApp Business API, voice AI, IVR, A2P 10DLC. Vague ICPs are what generate noise.
• An allowlist of subreddits. Nine, in my case.
• A board (kanban) with explicit states: New, Qualified, Contacted, In conversation, Won, Discarded. This is how sub agents hand results back to the orchestrator instead of dumping text.
• A minimum score to qualify, so that filtering is a rule and not a vibe.
• Date rules. This is the one I got wrong, so it gets its own section.

One infrastructure note before that: Reddit now requires app registration through a new platform, and for this use case it is paid. I pointed the agent at Arctic Shift instead, which exposes posts in near real time without authentication. If you are copying this, that swap is the difference between the profile working and the profile asking you for credentials it cannot get.

Where it broke, part one: the agent invented dates

The lead digest came back with a post it described as 30 days old. I opened the link. The post was three years old.

I sent the evidence back and asked where the date came from. It told me the date had been fabricated and that it was an error on its side. Then I asked a better question: what date do you have registered as today? The agent knew. The search script it had written for itself did not.

That is the actual failure. The model was not hallucinating a fact it should have known, it was reasoning on top of a script whose date defaults were never set, and its instinct when a value is missing is to complete rather than to stop. A relative window (last 7 days) computed against a wrong reference produces confident nonsense.

The fix is one line, and it is deliberately not something the agent gets to reason about:

from datetime import datetime, timedelta, timezone

now = datetime.now(timezone.utc)          # system time, at runtime
window_start = now - timedelta(days=7)    # never hardcode a date

params = {
    "subreddit": subreddit,
    "after": int(window_start.timestamp()),
    "before": int(now.timestamp()),
    "limit": 100,
}

Rule I now apply to every agent that touches a relative window: the reference date enters at runtime from the system, on every run, and the filtering happens in code. The model writes the justification for a lead, it does not compute whether the lead is recent.

After that correction the run produced one qualified lead in seven days. A two day old thread from a SaaS founder dealing with 10DLC onboarding for his customers, which is precisely what I sell. One lead is a low number, and I would rather have one I trust than the previous version of this system, built with plain keyword scraping, where roughly 90% of the output was noise from ambiguous keywords firing across every subreddit at once.

Where it broke, part two: the chat interface is a shell

For a single user, giving the agent terminal access is the reason it is useful. It installs its own dependencies and writes its own integrations.

The moment you let other people talk to it, that same interface is a natural language shell on your server with a model deciding what is legitimate. And the risk is not only the message in front of you. A command does not need to run in the conversation to run at all. It needs to be written into a scheduled job that executes on the next cron, when nobody is reading the chat anymore.

Concrete mitigations, in the order I would apply them:

• Allowlist of user ids while the instance is yours.
• Separate agents: whatever browses does not touch the terminal.
• Freeze the toolset before third party access. Build the agent with the tools it needs, then open it. An agent that can still write new capabilities at runtime is not a product, it is a shared server with a chat interface.

What I would actually use this for

Daily digests and monitoring, yes. It is very good at watching something boring on a schedule and telling you when it matters. Prospecting, yes, but with the human in the deciding step, not in the searching step: the agent qualifies and fills the board, I write the first message.

What I would not do yet is let it act on the outside world without review. Not because it is not capable, but because its failure mode is confident completion, and every system I build on communication channels has a cost attached to being confidently wrong in front of a customer.

-Gonza