Production Ready: Scale-to-Zero and Platform Updates

The Always-On Gateway Problem

A Hermes gateway that runs 24 hours a day, accepting messages from Telegram, Slack, Discord, and email, is genuinely useful. It is also, if left unmanaged, an always-running server process consuming compute resources at full cost whether anyone is using it or not. For personal deployments on a VPS, this is an acceptable trade-off. For team deployments, scheduled workloads, or any context where usage is bursty and unpredictable, paying for idle capacity is wasteful.

v0.18 addresses this with scale-to-zero: the gateway can detect when it is idle and go dormant, consuming minimal resources until a new message arrives. The feature is new in v0.18 but designed to fit naturally into existing gateway configurations. If you are running a production Hermes gateway today, enabling scale-to-zero requires a small configuration change.

Scale-to-Zero Idle Detection

Idle detection works by monitoring active session count and message activity. When no sessions have been active for a configurable idle period — the default is 15 minutes — the gateway transitions to a dormant state. In the dormant state, the gateway process is still running (it needs to receive the wakeup signal) but is consuming minimal CPU and memory. Connections to messaging platforms are maintained at the protocol level, so incoming messages still arrive; they just trigger an immediate wakeup rather than being immediately processed.

The wakeup path is fast: a typical gateway is back to full capacity within two to three seconds of receiving an idle-state message. For asynchronous communication channels like Telegram and email, this latency is imperceptible. For synchronous integrations with tight SLAs, you may want to disable idle detection or shorten the wakeup path.

Configuration in config.yaml:

gateway:
  idle_detection:
    enabled: true
    idle_minutes: 15

Drain Coordination for Zero-Downtime Deployments

Deploying a new version of Hermes to a running gateway without dropping active sessions requires drain coordination. When you trigger a deploy, the gateway enters drain mode: it stops accepting new sessions but allows existing sessions to complete. Once all active sessions are finished, the gateway shuts down cleanly, and the new version starts.

v0.18 adds external drain coordination — the ability for your deployment pipeline (a CI/CD system, an Ansible playbook, a Kubernetes rolling update) to signal the gateway to begin draining. The gateway exposes a drain endpoint that returns 200 while draining and 204 when draining is complete. Your deployment pipeline waits for the 204 before starting the new version.

Drain coordination plus scale-to-zero together describe what the release notes call "production-grade lifecycle management." The gateway can go dormant when idle, wake up when needed, and accept clean redeployments without dropping active sessions. These are table-stakes features for production services that Hermes has now shipped natively.

Gateway Authentication

The Hermes web dashboard and API, when bound to a non-localhost address, require authentication. Three methods are supported:

• Nous Portal OAuth — recommended for internet-facing deployments. Register via hermes dashboard register. Authentication goes through Nous Research's identity infrastructure. No username or password to manage locally.
• Username and password — configured in ~/.hermes/.env with scrypt hashing. Appropriate for trusted networks (a homelab VPN, a team internal network) where the risk of credential exposure is bounded by the network perimeter.
• Self-hosted OIDC — integrates with Keycloak, Authentik, Auth0, or any OpenID Connect-compatible provider. For enterprises with existing identity infrastructure, this lets Hermes gateway authentication ride on the same system as everything else.

The dashboard binds to 127.0.0.1 by default �� localhost only. Authentication only activates when you bind to a non-localhost address. For local-only deployments (a developer's personal machine with no remote access), the default is fine and no authentication configuration is needed.

Messaging Platform Updates in v0.18

The v0.18 release includes meaningful updates to how the gateway renders content across all major messaging platforms. These updates close long-standing gaps between what Hermes can produce and what each platform can natively display.

Slack — v0.18 adds Block Kit rendering as an opt-in option. Block Kit is Slack's rich component system for building structured messages — sections, images, buttons, and dividers. Hermes can now generate Block Kit payloads for Slack responses when the content structure warrants it (a formatted report, a multi-section status update) rather than falling back to plain markdown.

Discord — Reasoning output (the agent's internal chain-of-thought) is now displayed as subtext in Discord messages. Previously, reasoning was either omitted or included inline with the response, cluttering the message. As subtext, it is visible but de-emphasized — present for users who want to inspect it, unobtrusive for those who do not.

Telegram — The command menu is now configurable. The list of slash commands visible to Telegram users in the chat interface can be customized to show only the commands relevant to your deployment, rather than the full Hermes command set.

WhatsApp — Native media delivery was added. Before v0.18, WhatsApp media had to be sent as links or attachments with reduced quality. The native delivery path sends images, audio, and documents through WhatsApp's native media handling, with full platform quality.

Teams — Parallel to WhatsApp, Teams native media sending was added in v0.18, enabling the same direct media delivery through Microsoft Teams' media handling rather than link-based workarounds.

v0.18 Security Hardening

The P0/P1 cleanup that defines this release included several security-specific fixes. Three are worth knowing for production deployments:

• MCP-config persistence attack surface locked down — prior to v0.18, a specific sequence of MCP configuration changes could persist attacker-controlled config values. The attack surface is now closed.
• Credential exfiltration prevention in cron jobs — cron jobs scheduled to run prompts that included access to environment variables could be crafted to exfiltrate credentials. v0.18 adds explicit scoping to prevent credential access in cron execution contexts that have not been explicitly authorized.
• Slack app-level token redaction — Slack app-level tokens, which have broad workspace permissions, are now redacted in all log outputs and debug reports. Earlier versions logged these tokens in certain error conditions.