Production — ถูก เสถียร และออนไลน์ตลอดเวลาProduction — Cheap, Boring, Always On

Ask yourself one question. If the AI agent your team leans on every day died quietly at 3 a.m., who would find out first — your monitoring, you, or a colleague messaging at nine to ask why the bot has gone silent?

That question is the line between a laptop toy and a production system. I drew the same line at the end of this blog's OpenClaw series — OpenClaw #7: Production, where I walked through deploying agents on real infrastructure in some detail. Today the other side gets its turn: Hermes Agent from Nous Research, which I am now examining seriously as the possible next home for an organizational deployment.

Hermes's production pitch is not excitement; it is cheapness, stability, and boredom. The README says it plainly: "Run it on a $5 VPS, a GPU cluster, or serverless infrastructure that costs nearly nothing when idle." The software is MIT-licensed and free — you pay only for LLM API usage — and it ships an ops toolkit unusually complete for a project that launched publicly on February 25, 2026 (a date that rests on consistent third-party reporting, not a fetched Nous announcement). This closing post walks from choosing where to run it, all the way to the sharpest question: should you move your whole organization off OpenClaw?

Where to Run It: From a $5 VPS to Serverless That Sleeps

Hermes treats the execution backend as a pluggable part. The README names all seven: "Seven terminal backends — local, Docker, SSH, Singularity, Modal, Daytona, and Vercel Sandbox" — a range that runs from your own laptop to serverless platforms that bill only while working.

On the perennial "how big a machine" question: official numbers exist only in the Docker documentation (next section). On the VPS side, third-party guides converge on the same answer — a $5–6/month box from DigitalOcean, Hetzner, or Vultr is enough, as long as the models run on someone else's API rather than your own hardware. If your agent only talks Telegram or Discord, you don't even need a domain or SSL; those matter only once you expose a web UI or receive webhooks.

A hosting sub-market is already forming around the project. Hostinger, for one, sells a Managed Hermes Agent plan at $5.99/month for the first term ($11.99 on renewal) — but note that this is Hostinger's own product, not a Nous-confirmed partnership, and the official docs deliberately recommend no hosting provider at all.

The newest option is Hermes Cloud, in public preview since around mid-2026. Nous's own announcement pitches it as: "Spin up agents for everyone at your org with granular access controls and unified billing, all from Nous Portal." Per the Cloud page, deploying requires $10 minimum credits or an active subscription; it is billed hourly from Portal credits and scales to zero when idle. The hourly rate itself is unpublished, so I won't guess at one.

Starting from a bare machine is a one-liner:

# Linux / macOS / WSL2 / Termux — the official installer
curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash

# Windows (PowerShell)
iex (irm https://hermes-agent.nousresearch.com/install.ps1)

The installer wants Python 3.11 (via uv), Git, Node.js v26 (or 22.22+/24.11+), ripgrep, and ffmpeg, and supports Linux, macOS, WSL2, native Windows, and even Android under Termux. For real production, though, skip straight to Docker.

Docker Deployment That Survives Reboots

The best-paved production road is Docker. The nousresearch/hermes-agent image has passed 5 million pulls on Docker Hub at around 909 MB, and its design philosophy fits in one sentence: everything that matters lives in one volume.

# docker-compose.yml — shaped after the official doc
services:
  hermes:
    image: nousresearch/hermes-agent   # 5M+ pulls, ~909 MB
    restart: unless-stopped            # survives every reboot, no extra work
    command: gateway run
    ports:
      - "8642:8642"                    # Gateway API
      - "9119:9119"                    # Dashboard
    environment:
      - HERMES_DASHBOARD=1             # enable the dashboard
    volumes:
      - ~/.hermes:/opt/data            # everything important lives here
    shm_size: "1gb"                    # required for browser automation

The ~/.hermes volume (aka $HERMES_HOME) is the heart of the deployment: config.yaml, the .env credentials file, the SQLite state.db holding every session with FTS5 search, the skills/ directory, the memory files MEMORY.md + USER.md + SOUL.md, plus logs/, backups/, checkpoints/, and profiles/ for multi-profile installs. Back up this one directory and you have backed up the entire system.

Two details people trip over. First, the agent inside the container runs as UID 10000 — if a host-mounted directory throws permission errors, check the ownership of ~/.hermes before blaming anything else. Second, the dashboard on port 9119 supports basic auth, OAuth, and OIDC via environment variables; never expose that port to the internet without configuring one of them. (I go deep on this in #4 Security.)

Update, Backup, Rollback: The Ops Toolkit

What genuinely surprised me while reading the CLI reference is how complete the built-in ops tooling is for a six-month-old public project. Start with updates:

# check whether a new version exists — installs nothing
hermes update --check

# update, taking an automatic backup first
hermes update --backup

The clever part: hermes update auto-detects how you installed — git installer, Docker, or NixOS — and applies the matching upgrade path, syncing updated skills to every profile as it goes. On Docker, upgrading is a pull plus a recreate; since all state lives in the volume, nothing is lost:

# Docker upgrade: pull, then recreate
docker compose pull
docker compose up -d

And you will use this often. Between July 30 and August 31, 2026 — a single month — nine releases shipped (v0.19.1 through v0.21.0), under the project's dual versioning scheme of vX.Y.Z tagged as vYYYY.M.D. At that cadence, updating has to be a routine, not an event: my advice is a fixed weekly slot after reading the release notes, not chasing every tag.

Backups are equally self-contained:

# zip all of ~/.hermes — config, skills, sessions, memory
hermes backup -o ~/backups/hermes-prod.zip

# restore on any machine
hermes import ~/backups/hermes-prod.zip

# export one profile with credentials stripped — safe to hand to a teammate
hermes profile export

My favourite piece is hermes checkpoints — a shadow-git checkpoint store under ~/.hermes/checkpoints/ that powers the in-session /rollback command, letting you unwind whatever the agent just edited without touching your project's real git history. Nightly backups can be scheduled through Hermes's own cron system — an agent that backs itself up at midnight is exactly the kind of boring I want in production.

Observability and Cost Control

A system running 24/7 with nobody watching must be able to answer two questions at any moment: is it still working, and how fast is it burning money. Hermes answers the first with this set:

# follow live logs, errors only
hermes logs -f --level error

# drill into a single session's log
hermes logs --session <SESSION_ID>

# deep health check
hermes status --deep

# diagnose, and auto-fix what can be fixed
hermes doctor --fix

The logs/ directory keeps separate files per component — agent, gateway, errors, GUI, desktop. When you hit something you can't solve, hermes dump produces a support summary, and hermes debug share --nous uploads redacted logs to Nous infrastructure for their team to look at — explicitly opt-in, not stealth telemetry.

The money question has more dedicated tooling than I expected:

# token / cost / activity analytics for the last 30 days
hermes insights --days 30

# inside a session:
/usage      # what this session has spent so far
/compress   # shrink the context before the context shrinks your wallet

# outside a session — offline breakdown of where the prompt budget goes
hermes prompt-size

Recent releases added more cost levers: v0.20.5 (August 19, 2026) introduced a keyless web tier so fresh installs work before any key is configured, and v0.20.6 (August 27) added TTL caching for web operations, which directly cuts repeat calls. A widely used community pattern is assigning a cheap model to background work — compression and summaries — instead of letting your premium model do everything.

Performance moved too: third-party release trackers such as Releasebot record v0.19.0 (July 2026) cutting first-turn time-to-first-token by roughly 80% — from a cold start of about 4.3 seconds down to around 0.9. That is a third-party measurement, not an official benchmark, but it matches the direction visible in the release notes of that period.

Reliability Mechanics: WAL, Compression Lineage, Fallback Chains

Under the hood, several layers make Hermes tolerant of bad days. Summarizing from the official docs plus Arize's architecture deep-dive (that second source is third-party analysis, not official documentation):

• SQLite WAL journaling — every session is written to state.db under a write-ahead log, minimizing corruption when the process dies mid-write, with a fallback mode for filesystems that can't support WAL.
• Lineage-based compression — when context outgrows its budget, the session row is closed and a child session is seeded from a summary sized at roughly 20% of the compressed content, floored at 2,000 tokens and capped at 12,000 (figures per Arize's analysis). I compared this against OpenClaw's approach in #3 Memory.
• Fallback chains — hermes fallback configures an ordered provider chain, tried automatically on 429s and connection errors.
• Credential pools — hermes auth manages pools of API keys with rotation, so one key's rate limit isn't your whole system's rate limit.

For always-on operation, the gateway installs directly as an OS service — systemd on Linux, launchd on macOS — while the FAQ blesses tmux/nohup on WSL2 and Windows Task Scheduler elsewhere:

# run the gateway as a service, and check it
hermes gateway start
hermes gateway status

# crucial on Linux: keep the service alive after reboot, before anyone logs in
sudo loginctl enable-linger $USER

# long tasks on slow models: extend the stream read timeout (seconds)
HERMES_STREAM_READ_TIMEOUT=1800

Finally, secret hygiene — an area moving fast lately. v0.20.6 added OS-keychain encryption for stored secrets, and there's now an option to keep keys out of files entirely:

# pull API keys from Bitwarden Secrets Manager at startup, instead of .env
hermes secrets bitwarden

# event-driven webhooks — returns a URL plus an HMAC secret for verification
hermes webhook subscribe

Paying for Models: BYO Keys vs Nous Portal

Hermes itself is free; the real production cost is models, and there are two roads. The first is BYO keys — plug in OpenRouter, OpenAI, Anthropic, or your own custom endpoints. The README promises "300+ models — pick any of them with /model <name>", switchable at any time without code changes:

# switch models from the CLI, or mid-session
hermes model
/model provider:model

The second road is Nous Portal, which the official docs call "the recommended way to run Hermes Agent" — one OAuth, one bill, the same 300+ models, plus the Tool Gateway: Firecrawl-powered web search and extraction, nine image-generation models, OpenAI TTS, a cloud browser via Browser Use, and an optional Modal cloud sandbox:

# link a Portal account once and be done
hermes setup --portal

A Free tier ($0) exists too, but what exactly it includes is ambiguous between the docs page and the pricing page, so I won't pin it down — check portal.nousresearch.com before deciding. Paid tiers add usage discounts, hosted tools, and higher rate limits.

So what does a total monthly budget look like? Hostinger's cost analysis (August 2026) breaks the self-hosted side down like this — take it as a framing, not a quote:

The lever that moves the number most is matching the model to the job — the same report cites budget models like DeepSeek V4 Flash at $0.14/$0.28 per million tokens — combined with disabling unused tools and prompt caching.

My organizational read: small teams that want billing solved fast should just take Portal — it is the lowest-friction path. Organizations with existing cloud contracts or strict data-path requirements keep more control with BYO keys through endpoints they govern. And because there is no lock-in in the architecture, you can change your mind later.

Migrating an Organization from OpenClaw

Now the question my OpenClaw-series readers ask most. Nous ships the exit ramp as a single command — hermes claw migrate auto-detects ~/.openclaw and carries your world across. The correct procedure always starts with a rehearsal:

# rehearse first — reports what would move, touches nothing
hermes claw migrate --dry-run

# the real thing: API keys only come along with --migrate-secrets
hermes claw migrate --preset full --migrate-secrets

One bonus that quietly lowers migration cost: Hermes natively reads existing context files — CLAUDE.md, AGENTS.md, and .cursorrules, on a first-match priority chain. The context files your organization invested in during the OpenClaw / Claude Code era work on day one.

In fairness, this migration flows both ways: OpenClaw publishes its own official reverse guide, "Migrating from Hermes." This user base is genuinely contested, not a one-way street — which is good news for users, because both sides have to compete on quality rather than on walls.

Lessons from the Wild: Growth Numbers and the YOLO Tale

Why take Hermes this seriously? The growth numbers help: publicly launched February 25, 2026; 57,200 stars in the first six weeks per Hermes Atlas (a community project), faster than OpenClaw at the same stage; about 214,000 by mid-July (per TechCrunch's reporting); and as of September 1, 2026, nearly 240,000 stars with around 48,800 forks per the GitHub API.

The number I weight more than stars is actual workload. MarkTechPost reported Hermes overtaking OpenClaw for #1 on OpenRouter's global daily app rankings around May 10, 2026 (224 billion daily tokens versus OpenClaw's 186B), and a late-August KuCoin report put its all-time total at 33.1 trillion tokens — nearly four times second-place Claude Code's 8.53T. The release side is just as heavy: v0.20.0 "Herald" (August 3) landed with roughly 3,650 commits, and v0.21.0 "Pantheon" (August 31) with roughly 5,800 commits and 2,475 merged PRs from more than 760 contributors. The desktop app has been in public preview since June 2, 2026.

Reading Release Notes Like an Operator

If you run the system, what matters in the last two major releases is the ops-facing material:

• v0.20.0 "Herald" — signed outbound webhooks (receivers can verify signatures), agent-to-agent A2A v1.0, and grounded research with verifiable citations.
• v0.21.0 "Pantheon" — cron jobs that keep memory between runs (a game-changer for scheduled agents), the MCP interface becoming a dashboard with health checks and usage tracking, live steering of subagents, and a CLI command palette. Bot Mode, which had debuted earlier, was formally bundled into the desktop app by this release.

On capital and partners: Nous joined the NVIDIA Nemotron Coalition and, with Nebius, served nemotron-3-ultra:free on Portal from June 4–18 (officially documented), while TechCrunch reports Nous is in talks for new funding at a $1.5B valuation — in talks, not closed; no round has been confirmed.

But this year's most important production lesson came as bad news:

💡 The article is explicit that Hermes is "not a hacking tool, and nothing here is a flaw in it." The sentence that belongs on the ops-room wall is the next one: for self-hosted agents, "no vendor was watching, and there was no account to ban."

That is the essence of self-hosting that people overlook: total freedom means you are your own vendor. Nobody is watching for you; there is no account for anyone to ban. Monitoring, approval policy, and YOLO-mode discipline are entirely your job. (The defensive playbook is in #4 Security — do not run production without reading it.) And for the record, my searches found no official Nous response to this incident, so I won't imply one.

What's Still Missing for Enterprise — and Why There's No Roadmap

One of the most honest facts about this project: Hermes has no official roadmap document. There is no "coming in v1.0" page for your procurement office to staple to a purchase order. What exists instead is a relentless stream of real releases, as this whole post has shown. Anyone quoting a confident v1.0 date is guessing — myself included — so I won't.

From the perspective of someone who runs an organizational deployment, three gaps still stand out on the self-hosted open-source side — and they are the same themes users raise in GitHub issues and community discussion:

• Per-tenant memory isolation — memory and state are designed around a user/profile, not the hard multi-tenant separation a large organization's compliance team expects.
• Structured audit logging — the logs are complete for debugging, but an audit trail that answers "who ordered what, when, under which privilege" still has to be assembled yourself.
• An API-stability contract — nine releases in a month is community strength, but it also means no backward-compatibility promise that other systems can build against.

Interestingly, Nous has started answering this segment from the service side rather than the OSS side: Hermes Cloud's preview explicitly advertises org-level granular access controls and unified billing through Portal. So the blanket claim "Hermes has nothing for enterprises" is no longer quite true — the accurate version is: self-hosters still build it themselves, while a managed alternative is starting to be sold.

One more thread to watch without betting on it: hermes-agent-self-evolution, Nous's official research repo on evolutionary self-improvement using DSPy + GEPA — clearly labeled research, not production-ready.

The Pre-Launch Production Checklist

To close, the checklist I distilled from this whole post — tick every box before calling anything production:

• ☐ Container set to restart: unless-stopped, and on Linux loginctl enable-linger is enabled
• ☐ The dashboard on port 9119 has auth (basic/OAuth/OIDC) — no exceptions
• ☐ hermes backup runs nightly, and you have rehearsed hermes import on a clean machine at least once — a backup that has never been restored is a hope, not a backup
• ☐ A weekly hermes update --backup slot exists, with release notes read first
• ☐ hermes fallback and a credential pool are configured in advance — don't meet your first 429 on a deadline
• ☐ hermes insights is on the weekly calendar, and the team knows /usage and /compress
• ☐ Secrets live in the OS keychain or Bitwarden — never bare in .env
• ☐ No YOLO mode on production machines — full stop, no trailing conditions
• ☐ If migrating from OpenClaw: the cron-jobs/hooks inventory is written down before running migrate

My position as of today: for small-to-mid teams willing to adopt the ops discipline in this post, Hermes is production-ready right now, and cheaper than most people assume. For organizations needing full compliance, I recommend the same formula I used for OpenClaw: pilot on a separate VPS, make backups a day-one habit, use Portal to unify billing, and only commit to the big migration once a real audit passes. The best production system is the most boring one — and Hermes keeps getting better at being boring.