Deploy and Host Hermes Gateway via Tailscale on Railway

Deploys a Hermes AI agent as a Slack-native assistant, with Tailscale running inside the container for private SSH access. Each agent registers as its own tailnet node, with persistent memory and skills that survive redeploys via a mounted volume. No public ingress required — Slack runs over Socket Mode, maintainer access is tailnet-only.

About Hosting Hermes Gateway via Tailscale

The template provisions one Hermes service per Railway project. On boot, the container starts Tailscale in userspace networking mode (no NET_ADMIN capability required, no privilege escalation), registers with your tailnet using a reusable auth key, enables Tailscale SSH, then hands off to the upstream Hermes entrypoint. Hermes connects to Slack over Socket Mode with no inbound network surface. State — conversation history, learned skills, Tailscale machine identity — persists at /opt/data/ on a Railway volume across redeploys, so the agent keeps the same MagicDNS hostname and memory between deployments. To run multiple agents, duplicate the service inside the project and override the per-agent variables (TS_HOSTNAME, SLACK_BOT_TOKEN, SLACK_APP_TOKEN, SLACK_ALLOWED_USERS).

Common Use Cases

• Per-person Slack assistants. Give each teammate their own AI agent with a distinct bot identity, isolated memory, and a per-agent allowlist that scopes who can talk to it.
• Internal team operations agents. A shared Hermes agent for on-call triage, ticket summarization, daily status digests, or skill-driven runbook execution — accessible to the whole team via one Slack app.
• Private agent sandbox with maintainer-grade observability. SSH into the running container over the tailnet to inspect Hermes memory, swap models via hermes config, view live logs, or rotate skills — all without exposing anything to the public internet.

Dependencies for Hermes Gateway via Tailscale Hosting

• Tailscale account with a reusable, non-ephemeral auth key. Tags are optional but recommended for ACL targeting.
• Slack workspace with a Slack app installed (Bot Token Scopes for Socket Mode + Event Subscriptions; bot token xoxb-... and app token xapp-...).
• LLM provider key. OpenRouter is recommended for breadth; Anthropic, OpenAI, or Google are supported as direct providers.
• Slack member IDs of the users authorized to talk to the agent (the Slack SLACK_ALLOWED_USERS allowlist — leaving this blank is the most common cause of an agent that looks online but never responds).

Deployment Dependencies

• Hermes upstream repository — the runtime this template wraps. Credit and full env-var reference live here.
• Tailscale auth keys — generate the reusable auth key for TS_AUTHKEY.
• Tailscale SSH documentation — how maintainer access works once the agent registers.
• Slack API — Your Apps — create the Slack app, install it to the workspace, and collect the bot + app tokens.
• OpenRouter API keys — provider key for OPENROUTER_API_KEY (or use one of the direct providers below).
• Anthropic Console / OpenAI dashboard / Google AI Studio — alternative provider keys.
• Railway Volumes documentation — context on the persistent volume mounted at /opt/data.

Why Deploy Hermes Gateway via Tailscale on Railway?

Railway is a singular platform to deploy your infrastructure stack. Railway will host your infrastructure so you don't have to deal with configuration, while allowing you to vertically and horizontally scale it.

By deploying Hermes Gateway via Tailscale on Railway, you are one step closer to supporting a complete full-stack application with minimal burden. Host your servers, databases, AI agents, and more on Railway.