At 11:51 PM on a Tuesday I typed /build a Next.js task tracker with SQLite, deploy it to Vercel into a Discord channel and walked away to make coffee. By the time the kettle clicked off, my Hermes agent had spun up Claude Code as a sub-agent on my Hostinger VPS, scaffolded the project, pushed a first commit to a fresh GitHub repo, and triggered a Vercel deploy. Then it failed, and the failure is the reason this post is worth your time: the loop that recovered from it, unattended, is the actual system. Eight minutes and forty-three seconds after the original prompt, I had a working production URL and had written zero lines of code.
The failure was the specific, predictable way Next.js apps die when they carry SQLite assumptions into a serverless runtime. The build went green, the deploy completed, and the first request to /api/tasks returned a 500 with EROFS: read-only file system. Hermes caught the failure log, fed it back into Claude Code as a follow-up task, and Claude Code spent four minutes swapping the data layer from SQLite to Vercel KV. New commit, new deploy, green. The Discord message waiting for me said, in essence: hit a serverless filesystem issue, swapped to KV, redeployed, demo here.
Why put Hermes on top of Claude Code at all
I asked the skeptic's question myself for three weeks: if Claude Code can already plan, write, run, and deploy code, why add another agent? The answer is that they solve different problems. Claude Code is a brilliant terminal session; Hermes is an operations layer.
Claude Code's strength is depth inside a single task. What it does not naturally do is the messy operational glue: watch its own deployments and react to failures, accept commands from Discord, run on a VPS while you sleep, juggle three projects in parallel, or keep API tokens encrypted on disk instead of pasted into chat. You can build all of that around Claude Code with shell scripts and cron. I tried. The result is a fragile pile of glue you maintain forever.
Hermes Agent, from Nous Research, is that glue as a maintained, MIT-licensed product: messaging integrations for Discord, Telegram, WhatsApp, and Slack, encrypted credential storage via hermes config set, an orchestrator mode that supervises sub-agents, and a learning loop that turns one-off tasks into reusable skills. I run it on the same pattern I described in my two-agent OpenClaw and Hermes system, and the split has a cost logic too: Hermes routes orchestration traffic through cheaper models on OpenRouter while Sonnet-tier Claude ($3 in / $15 out per million tokens) handles only the actual coding. The savings compound with every parallel task.
The VPS foundation
I ran Claude Code locally on my Mac for six months. That broke the moment I wanted three things at once: long tasks that survive closing the laptop, a stable address for webhooks, and parallel agent sessions that do not fight my CPU during video calls. A VPS solves all three.
I use Hostinger because my production sites already deploy there; my GitHub Actions deploy pipeline has pushed this very blog to Hostinger for years, so the operational muscle memory was free. Their KVM 2 plan (2 vCPUs, 8 GB RAM, NVMe) runs about $7 a month introductory, closer to $12 on renewal, which the marketing pages are quiet about. Hermes itself is light; the heavy lifting happens at the model providers, not on the box. Any Ubuntu 22.04+ VPS with SSH, Node 18+, and outbound network access works.
Install is one line from the official docs:
curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash
That creates a ~/.hermes config directory and a first-run wizard for provider keys. I pick OpenRouter here rather than going direct, because it lets me swap models per task without touching config. Then:
hermes config set OPENROUTER_API_KEY <your-key>
hermes config set stores the key encrypted on disk instead of plaintext. That matters more than people realize. I have audited too many tutorials that tell you to export ANTHROPIC_API_KEY=sk-... in .bashrc, which leaves the key in your shell history, your tmux scrollback, and every backup of your home directory.
Claude Code as the sub-agent
Claude Code installs from npm (npm install -g @anthropic-ai/claude-code; the binary is claude). The interesting part on a headless VPS is authentication: the first run prints an OAuth URL and waits. The URL works from any device, so complete the flow on your laptop and the VPS keeps a logged-in Claude Code that survives reboots.
Registering it as a Hermes sub-agent is where the judgment calls live. The settings that matter, whatever your Hermes version's config surface looks like:
- Concurrency cap. I started at one parallel Claude Code session and worked up. At three, my KVM 2 box runs warm but stable. At five, I have watched Node OOM when every session hit
npm installat the same moment. Tune this to your VPS, not to the docs example. - Timeout. I kill any single task at thirty minutes. That sounds aggressive until you have watched an agent wedge itself in a plan-execute-replan loop on a vague prompt and burn tokens all night. Fail fast, surface the problem.
- Tool scope. My allowed list is read, write, edit, bash, glob, grep, and web search. Nothing that can exfiltrate data outside approved channels, no cloud-provider CLIs the project does not need. The narrower the surface, the smaller the blast radius.
GitHub without pasting tokens into chat
Most tutorials tell you to paste a GitHub personal access token into the agent's chat window. That is a recipe for leakage into chat logs, provider history, and debugging screenshots. Instead: generate a fine-grained token scoped to the one repository the agent should touch, with only Contents read/write, Pull requests write, and Metadata read. Store it with hermes config set GITHUB_TOKEN, and let git pull it from the environment at runtime:
git config --global credential.helper '!f() { echo "username=mejba"; echo "password=$GITHUB_TOKEN"; }; f'
Remote URLs stay clean, the token never appears in git config --list, and rotation is one command. The scoping matters as much as the storage: a classic full-repo token hands your automation write access to every private repository you have, client work included. Scope per project. If the VPS is ever compromised, the blast radius is one repo.
The Discord cockpit
The Discord layer is what makes this feel like science fiction instead of cron. Ten minutes of setup: create an application in the Discord Developer Portal, and on the Bot page enable the Message Content privileged intent. That checkbox is the one every tutorial forgets, and without it your bot can see that messages exist but not what they say; you will spend an hour debugging "why does my bot ignore me." Reset and copy the bot token, generate an invite URL with the bot and application-commands scopes plus send-messages and read-history permissions, and authorize it into your server.
Store the token with hermes config set DISCORD_BOT_TOKEN, then enable the Discord transport with two allowlists: authorized channel IDs and authorized user IDs. Those allowlists are the security layer nobody highlights. Without them, anyone who can DM your bot can drive a shell-capable agent on your VPS. With them, the bot obeys only you, only in channels you chose. Restart Hermes, type /status, and when it answers, the loop is closed: Discord to Hermes to Claude Code and back. I drive the same setup from my phone the way I run Claude Code remotely from a phone, and Vercel closes the last mile: auto-deploy on push to main, with Hermes polling the deploy status and reporting back to the channel.
The SQLite lesson, generalized
Claude Code picking SQLite was perfectly reasonable. SQLite is the right answer for almost every small Node project, and on my VPS it would have worked. But Vercel API routes run on AWS Lambda, where the filesystem is read-only outside /tmp and /tmp is ephemeral. SQLite must write its database file; the runtime said no; the deploy "succeeded" while being completely non-functional.
The transferable lesson: the agent does not know the runtime topology of your target unless you tell it. My default prompt template for Vercel work now carries one paragraph: target is Vercel serverless, no filesystem writes outside /tmp, 60-second function cap, no long-running workers, prefer managed stores like Vercel KV or Upstash for state. That block has eliminated the entire category of failure. The agent is not psychic. Tell it what production requires.
The security conversation most tutorials skip
When you let Hermes spawn Claude Code with bash access, you have created an automated agent that can run arbitrary shell commands on a machine holding your GitHub token, your provider keys, and write access to production deploys. Three non-negotiables before flipping that switch. Prompt injection is real: the user and channel allowlists are your single most important defense, because if a stranger can message your bot, you have already lost. A compromised VPS is a compromised everything: key-only SSH, ufw with default-deny inbound, unattended security upgrades, quarterly key rotation. And for client work, I run a separate VPS per high-trust project; twelve dollars a month for two boxes buys isolation that keeps one compromised project from cross-contaminating the rest. If you are not willing to do this work, run Claude Code locally and accept the limitations. That is a legitimate choice.
The speed numbers, honestly
The tutorials that popularized this stack claim 4x to 8x development speed. Measured against my own work, the honest number depends entirely on the category. Greenfield scaffold-and-ship jobs: the compression is real, an evening of setup and deploy debugging now fits in fifteen minutes, call it 10x on that narrow slice. Work bottlenecked on design decisions or domain judgment: 1.5x to 2x at best, because the agent is not faster than me at deciding what to build. Maintenance on existing code: around 3x, slower than greenfield because there is more context to load and I review production changes harder. The composite across my actual mix has been roughly 2.5x throughput. Real, and not the headline.
Whether the orchestration layer is worth it comes down to a simple test: do you need at least two of remote chat-driven control, parallel sessions across projects, scheduled unattended tasks, or encrypted multi-token management? I catalog what those parallel agents actually do all day in my six Hermes use cases. If you are one project at one desk during working hours, skip all of this and open a terminal; learn Claude Code deeply first, then add orchestration when you can name the friction it solves.
Start small either way. VPS, Hermes, one working /status command. Then one trivial sub-agent task. Then the deploy rail. Each layer has its own failure modes, and you want to meet them one at a time. Every agent-infrastructure build I run gets written up the way this one was, EROFS failure and all, and those write-ups live in the projects portfolio.
