Hermes Agent Runs My Web App on a $6 VPS — Replacing Vercel, Railway & Supabase

Source: raw/My_Hermes_Agent_Runs_My_Web_App_on_a_6_VPS_And_Replaces_Vercel_Railway.md (video, Team Garage channel)

A YouTube walkthrough (part 1 of 2) showing how the creator runs his live web apps on a single cheap (~$6/mo) VPS with one always-on Hermes agent maintaining them — replacing the usual Vercel + Railway + Supabase starter stack that AI coding tools default to. The featured app is agentwikis.com, a set of 16 public agent-readable wikis where “git is the database.” The agent keeps content fresh via two cron-driven multi-agent loops, each gated by a single Telegram approval. A follow-up video will deploy a database-backed game app onto the same box.

Key Takeaways

• The thesis: a VPS replaces the core of the managed stack. Vercel (front-end deploy), Railway (managed Postgres / backend), and Supabase (Postgres + auth + realtime + row-level security + storage) are all good — but “running them as a stack can get a little bit expensive,” and what they really sell is de-risking and convenience, not irreplaceable capability. A single server covers the core functionality.
• One small box runs everything. A droplet^[inferred: “droplet” is DigitalOcean’s product term; provider not named in the video] with 1 vCPU, 1 GB RAM, 25 GB storage (~$6/mo) already runs the Hermes agent. New sites are tenants on that same box, not new servers.
• Git is the database. For docs / blogs / wikis / marketing pages, the app server renders markdown from disk on every request and keeps an in-memory search index that rebuilds only when files change. git push is the deploy; a git pull on the server is instantly live — no restart, no rebuild. A real database “would have been answering a question this site never asks.”
• Caddy handles TLS + routing. Caddy was already on the box terminating TLS for the agent, so a new site just adds a vhost: agentwikis.com reverse-proxies to a localhost port and Caddy auto-provisions the cert (automatic TLS).
• Workspace layout: everything lives under /srv/agentwikis — the app plus one git clone per wiki (Hermes Agent, Hyperframes, ComfyUI, and others; 16 public wikis at recording).
• Access: SSH by IP as root to the agent (named “Admiral”); always-on because the VPS is always running, reachable via Telegram without keeping a PC/laptop open. A Hermes chat/TUI on the box gives direct file access to edit the site.
• The agent is scoped, not given full reign — only access to the parts of the site it needs (see the security model).
• Maintenance loop (cron-driven): scout + research agents check each wiki’s sources for new releases / versions / changelogs / features / community notes → dedupe → research what’s genuinely new → form a plan → one Telegram approval gate → verify sources, lint, commit to git → live within ~15 minutes, no restart → repeats each cycle. Currently a weekly cron because each loop is token-costly. It is the multi-agent / multi-profile pipeline from the creator’s multi-agent-workflow video, adapted.
• Demand loop (the new feature): agents query the wikis through an MCP server; only a distilled query hits the server — no prompt text, no IP, no identity — logging hit/miss as aggregates only. Repeated misses (same topic/keywords asked at least twice in 7 days) become an authoring backlog → scout-format candidates → research agents → plan → human gate → pipeline writes/verifies/commits → live. The wiki self-evolves toward what agents actually ask for, without reading anyone’s prompts.
• Demo: KB-intake parsed 5 live demand gaps (each scored 88/100), spawning 5 item files + 15 child cards on a Kanban board inside the VPS agent. One gate proposed adding a webhook rate-limit answer to messaging-gateway.md; after approval it lint-verified, committed to a branch/clone, and once the human reviewed the diff and merged to main the server pulled and the live answer appeared (“each webhook route defaults to 30 requests per minute using a fixed window”). Two human gates total: proposal approval, then diff-review + merge.
• Nothing leaves the box. Research, writing, verification, and commit all happen inside the VPS — framed as the differentiator vs. someone building the same wikis elsewhere.
• When one box ISN’T enough (reach for managed services): real auth (password resets, OAuth failure modes); can’t-lose / regulated data → managed Postgres (e.g., Railway); global / viral traffic → Vercel / Cloudflare; email deliverability (self-hosted SMTP lands in spam) → Postmark / Resend; team velocity + preview deploys → Vercel / Railway. The single biggest caution is auth holding real credentials — handle it sensitively to avoid a breach.

Related

• Hermes Masterclass — episode 2 (Deploy to VPS) is the prerequisite this builds on: standing up the Hermes agent on the box first
• Multi-Agent Workflow Template — the multi-agent / multi-profile pipeline the creator adapted for both content loops here
• Agent Wikis — the actual product/site being run on this VPS; the demand loop is its self-evolving authoring engine
• Hermes Security Model — how to scope the agent to only the parts of the site it needs (the “I don’t give him full reign” point)
• Remote Access (Tailscale + Termius + tmux) — complementary: this article hosts on the box, that one secures reaching it from anywhere
• Profiles & Multi-Instance — the per-profile isolation underpinning a multi-profile pipeline on one machine
• Codex App-Server Runtime — runtime/economics option for the agent doing the token-heavy loop work on the box

Implementation

Tool/Service: Hermes agent (Nous Research) on a single VPS; Caddy (reverse proxy + automatic TLS); Git (deploy mechanism + “database”); a custom agent-friendly app server (renders markdown from disk, in-memory search index); an MCP server (agent search + demand logging); Telegram (approval gate); the multi-agent / multi-profile Hermes pipeline (scout / research / writer / lint).

Setup:

• Stand up a Hermes agent on a small VPS (per masterclass ep. 2) and connect Telegram for an always-on control channel.
• Put Caddy on the box terminating TLS.
• Per site, add a vhost that reverse-proxies the domain to a localhost port; Caddy auto-provisions the cert.
• Lay out /srv/<app>/ with the app plus one git clone per content set.
• Build/host an app server that renders markdown from disk per request and rebuilds an in-memory search index only on file change — git push → server git pull = instant live, no restart/rebuild.
• Wire a cron-driven maintenance loop: scout → research → dedupe → plan → Telegram approve → lint → commit.
• (Optional) Add the demand loop: expose search via MCP, log distilled-query hit/miss aggregates only, and convert repeated misses into authoring candidates.

Cost: ~$6/mo for the VPS (1 vCPU / 1 GB RAM / 25 GB) running the agent and all tenant sites — replacing a Vercel + Railway + Supabase stack whose combined cost “can get a little bit expensive.” The real variable cost is tokens: the maintenance loop is “quite costly,” which is why the cron runs weekly rather than daily.

Integration notes:

• Sites are multi-tenant on one box — no per-site server.
• The agent is least-privilege scoped to only the directories/repos it must touch.
• The demand loop is privacy-preserving: distilled query only, aggregates only, no prompt/IP/identity stored.
• Human stays in the loop via two gates (proposal approval, then diff-review + merge); the creator may make the demand loop fully autonomous as confidence grows.

Try It

1. Deploy a Hermes agent on a $6 droplet (1 vCPU / 1 GB / 25 GB) following the masterclass ep. 2; connect Telegram so it is always reachable without keeping a PC open.
2. Install Caddy and point your domain at the box; add a vhost that reverse-proxies to your app’s localhost port and let Caddy auto-issue the TLS cert.
3. For a docs/blog/wiki/marketing site, skip the database: store content as markdown in a git repo, render from disk, and make git push + server git pull your deploy. Keep the search index in memory and rebuild only on file change.
4. Lay the workspace out as /srv/<app>/ with the app plus one git clone per content set; SSH in (root or a least-privilege user) and run a Hermes chat/TUI on the box for direct edits.
5. Scope the agent to only the directories/repos it must touch — see the security model.
6. Add a cron-driven maintenance loop (adapt the multi-agent workflow): scout sources → research deltas → plan → single Telegram approval → lint → commit → live in ~15 min. Start weekly to control token spend.
7. (Advanced) Add a demand loop: serve search via an MCP server, log only distilled-query hit/miss aggregates, and convert topics missed twice or more in 7 days into authoring candidates that flow back through the same pipeline.
8. Keep managed services for the hard parts: real auth / credentials, can’t-lose data (managed Postgres), viral scale (Vercel / Cloudflare), and email deliverability (Postmark / Resend).

Open Questions

• VPS provider not named. “Droplet” plus the $6 / 1 vCPU / 1 GB / 25 GB spec strongly imply a DigitalOcean basic droplet, but this is inferred.
• On-box model is unverified. The model the creator uses in the on-box Hermes chat is auto-captioned “GPT-3.5,” which is almost certainly a caption artifact (date and context don’t fit); the actual model is unconfirmed.
• App-server internals not shown — language/framework of the custom markdown app server and the exact MCP server implementation aren’t detailed.
• Token cost not quantified beyond “quite costly” (hence the weekly cron).
• Part 2 (database-backed game app on the same VPS, replacing Supabase) had not shipped at recording.