Kaizen AI Lab · Internal Research Brief

Hermes Agent: Hosting, Templates & Distribution

Self-hosting Percy on Railway, and what Hermes's Profile Distributions mean for Kaizen's per-client agent strategy. The Sharklab-equivalent question, answered.

Prepared for: Don Ho Prepared by: Sebastian 🦀 Date: June 6, 2026 Source: Nous Research official docs + Railway template audit

§TL;DR

  • Hosting: Use the official Railway one-click template. ~$5–10/mo container cost. Under 5 minutes to live.
  • Pre-configured env vars (PORT=9119, HERMES_HOME=/opt/data): Leave them as-is. They describe the container's internal environment, not your Mac or Railway account.
  • Template repo (shruti060701/hermes-agent-railway): Audited and clean. 12-line Dockerfile, 4-line start script, wraps the official nousresearch/hermes-agent image. No secrets, no exfil, no funny business.
  • Sharklab equivalent: Yes — and arguably better. Profile Distributions let you package a complete agent (persona, skills, crons, MCP, config) as a git repo. One-command install. Memory-preserving updates. No proprietary registry.
  • Strategic upshot: Profile Distributions are the cleanest path yet for the per-client Sebastian play from Colony PRD v4.0.3.
1Hosting on Railway 2Env-var sanity check 3Template repo audit 4Templates & distribution 5Hermes vs Sharklab 6Strategic plays 7Next steps

1.Hosting Percy on Railway

Nous Research publishes an official Railway one-click template. You don't need to write a Dockerfile, configure volumes, or wire SSL — it's a button.

What gets deployed

Cost & footprint

Deployment steps

1
Mint an OpenRouter API key at openrouter.ai/keys. Add ~$10 credit. Alternatives: OpenAI, Anthropic, Nous Portal, NVIDIA NIM all supported natively.
2
Open the template: railway.com/deploy/hermes-agent-3 → click Deploy Now.
3
Railway provisions: container, persistent volume, HTTPS endpoint. Build time ~2 minutes.
4
Open the Railway URL → lands on Hermes WebUI /setup. Add LLM provider key, pick default model, configure messaging gateways (Discord, etc.).
5
(Optional) Migrate Mac Percy's existing state by tarring ~/.hermes/ and uploading into the Railway volume. Or start fresh — 3 days of trial context isn't much.
6
Stop the Mac gateway (hermes gateway stop) so two Percys aren't racing for the same Discord events.

2.Env-var sanity check

The Railway template ships two pre-configured environment variables. The question that came up during deploy: "Should these match my Mac or my Railway account?"

Answer: No. Leave them exactly as shown. They describe the container's internal environment.
VariableValueWhat it actually means
PORT 9119 The port Hermes binds inside the container. Railway's edge proxy maps it to your public HTTPS URL on 443. start.sh hardcodes 0.0.0.0:9119 — change it and the WebUI becomes unreachable.
HERMES_HOME /opt/data The path inside the container for SQLite DB, skills, sessions, config. Must match the volume mount path (also /opt/data). On your Mac it's ~/.hermes/ because that's where the macOS installer put it — different OS, different path.

3.Template repo audit — shruti060701/hermes-agent-railway

Verdict: Safe Clean thin wrapper. No shenanigans. Deploy with confidence.

Full contents

Dockerfile (12 lines):

FROM nousresearch/hermes-agent:latest   # official Nous image
USER root
ENV HERMES_HOME=/opt/data
ENV PORT=9119
COPY start.sh /opt/hermes/start.sh
RUN chmod +x /opt/hermes/start.sh
EXPOSE 9119
CMD ["bash", "/opt/hermes/start.sh"]

start.sh (4 functional lines):

#!/bin/bash
set -e
hermes gateway run &                                                       # messaging gateway in background
exec hermes dashboard --host 0.0.0.0 --port "${PORT:-9119}" --no-open --insecure

Why this is clean

  1. Official base image. FROM nousresearch/hermes-agent:latest — pulled directly from Nous's Docker Hub.
  2. No extra code execution. The startup script runs only two documented Hermes CLI commands. No curl | bash, no surprise package installs, no telemetry callbacks.
  3. No secrets baked in. No API keys, no tokens, no hardcoded credentials anywhere in the repo.
  4. No suspicious COPY targets. Single file copied (start.sh) to a non-system path.
  5. The --insecure flag is correct. It tells Hermes to bind plain HTTP because Railway's edge handles TLS — same pattern the official docs recommend for hosted deploys.
One mild caveat: Supply chain The repo owner is an individual (shruti060701), not Nous Research. You're trusting that (a) they don't push a malicious update later, and (b) Railway doesn't auto-redeploy from a future bad commit.

Mitigation: After your first successful deploy, disconnect the GitHub source in Railway → Settings → Source. Railway keeps running the image it already built. Or fork the repo to dhoesq/hermes-agent-railway and point Railway at your fork (~30 seconds).

4.The big question — templates & distribution

Does Nous Research allow creating high-level shareable agent "templates" similar to OpenClaw's Sharklab? Yes — and the design is more open.

Hermes has a three-tier sharing system:

Tier 1

Skills Taps — share capabilities

You publish a GitHub repo of skills (each with SKILL.md + scripts + references). Others run:

hermes skills tap add yourorg/skills

Their Hermes picks up all your skills automatically. A community skills hub already exists (HermesHub).

OpenClaw equivalent: sharing individual skills.

Tier 2

Personality Presets — share voice

A standalone SOUL.md file defines persona, gets baked into a profile. Light-touch sharing — just identity and tone, no skills/crons/MCPs.

OpenClaw equivalent: sharing a SOUL.md.

Tier 3 ★ The Sharklab Equivalent

Profile Distributions — share a whole agent

A profile distribution packages a complete Hermes agent — personality, skills, cron jobs, MCP connections, model config — as a git repo. The agent-as-product.

Repo structure:

my-agent/
├── distribution.yaml    # manifest: name, version, required env vars
├── SOUL.md              # persona / system prompt
├── config.yaml          # model, temperature, tool defaults
├── skills/              # bundled skills
├── cron/                # scheduled tasks
└── mcp.json             # MCP server connections

One-command install for recipients:

hermes profile install github.com/kaizen-ai-lab/percy-cos --alias percy

Recipients fill in their own API keys (.env.EXAMPLE → .env) and the agent runs against their infrastructure with their memory, sessions, and costs.

Authors push updates via git tags:

git tag v1.1.0 && git push --tags
# Recipients run:
hermes profile update percy
# Their memory + sessions are preserved. Only persona/skills/crons update.

5.Hermes Profile Distributions vs OpenClaw Sharklab

OpenClaw SharklabHermes Profile Distributions
Distribution mediumSharklab registryGit repo (GitHub / GitLab / private / any)
Update mechanismPush to Sharklabgit tag + push
VersioningSharklab version fieldGit tags (SemVer-style)
Private templatesSharklab-controlledFree — any private git repo + SSH / HTTPS auth
Recipient memory preserved on updateVariesYes Explicit guarantee
What's bundledSkills + configSkills + cron + MCP + SOUL + config
What's explicitly excluded—Secrets (.env, auth.json) + user memory/sessions
Marketplaceclawhub.comHermesHub (community) + any public git repo

Verdict: Hermes's model is more open than Sharklab. No proprietary registry, no company in the middle. The repo is the template.

The tradeoff: recipients need git installed. On any machine running Hermes in 2026, that's already true.

6.Strategic plays for Kaizen AI Lab

Three concrete moves this unlocks:

Play 1

Internal Percy template

Build kaizen-ai-lab/percy-cos as a private GitHub distribution. Every Kaizen team member installs Percy with one command. Updates ship via git tag. Obvious immediate win — gives Percy version control, easy redeploy if Railway eats the volume, and a clean handoff pattern for Carson.

Play 2

Per-client Sebastian — Colony PRD v4.0.3 vision, realized

The Colony PRD already calls for "Sebastian as a multi-instanced UI persona, each client gets their own." Hermes Profile Distributions make this trivial.

Each client gets their own profile distro — e.g. kaizen-ai-lab/sebastian-acme-corp as a private repo shared only with that client. You ship updates via git tag. Their memory stays intact across updates. Their secrets never touch your infra. Per-client isolation by architecture, exactly as the PRD requires.

Play 3

Public Kaizen agent product

You could ship kaizen-ai-lab/kai-public as an open-source distribution — a starter "AI Chief of Staff" template anyone can install. Lead-gen via the install command. Premium skills / MCP integrations gated behind a paid tier. A clean product wedge that didn't exist on OpenClaw.

7.Recommended next steps

  1. Now: Click Deploy on the Railway template. Env vars are correct as shown. Repo is clean. Use OpenRouter as the LLM provider for fast first light.
  2. Within 24 hours: Configure Percy's WebUI dashboard, wire Discord gateway to #hermes-agent, retire the Mac gateway.
  3. Within 48 hours: Fork shruti060701/hermes-agent-railway to dhoesq/hermes-agent-railway (eliminates supply-chain risk).
  4. Within the week: Spike on a Percy Profile Distribution (distribution.yaml + repo layout). Even private-only, gives version control + redeploy safety.
  5. End of June review: When the Hermes-vs-OpenClaw long-term decision lands, the per-client Sebastian play (Profile Distributions) should be a factor in the verdict.

§Sources