The best ways to host Hermes in 2026

The classic self-hosted Hermes setup: a cheap box that is always on, and always yours to babysit.

Best for: A hobbyist running one personal Hermes agent who is comfortable in a terminal. Honestly the best deal at that scale.

A small cloud VPS is the default answer for self-hosted Hermes, and at the one-agent hobby scale it deserves the spot: a few dollars a month buys an always-on Linux box where you install the runtime, start Hermes under systemd or in a container, and reach the dashboard over a tunnel or a reverse proxy. You control everything, you learn how the agent actually works, and nothing about your data leaves a machine you rent directly.

Where it breaks is everything after day one. Nobody restarts Hermes when it dies except you, nobody notices the corrupted config until the agent goes quiet, and every Hermes release is a manual upgrade with no rollback beyond whatever backups you remembered to take. Run one agent for yourself and this is fine. Run five, or run agents for clients who expect them online, and the VPS quietly turns into an unpaid ops job where the customer notices the outage before you do.

Hermes on hardware you own: zero monthly bill, total privacy, home-grade reliability.

Best for: Tinkering, development, and a personal agent whose data you want to keep entirely at home.

Running Hermes on a spare machine or a Mac mini on your desk is the most private option there is: the agent, its state and its gateway never leave hardware you physically own, and the development loop of editing config and watching the dashboard locally is genuinely pleasant. If you already own the machine, the marginal cost is electricity.

The reliability ceiling is your home. Power cuts, ISP hiccups, OS updates that reboot the box, a laptop that sleeps: a Hermes agent that is supposed to be always available inherits all of it, and a Mac mini in a closet is a textbook single point of failure with no failover. For one personal agent that can afford to be offline for an afternoon, that trade is fine and this option is underrated. For anything a client pays for, it is the wrong tool.

Containerized Hermes on your homelab or existing server: tidy isolation, same old ops.

Best for: Someone with a homelab or an always-on server who wants Hermes isolated from the rest of the box.

If you already operate a server, putting Hermes in a container is a clear step up from a bare install: the runtime is isolated, the persistent state lives on a named volume, and a restart policy like unless-stopped brings the process back when it dies. Since the hardware is already running 24/7, the agent costs you nothing extra in idle, which is a genuinely good deal.

Just be honest about what a restart policy covers: it revives a dead process, and that is all. It does not detect a Hermes agent that is up but wedged, does not repair corrupted state (it will happily restart into the same broken config forever), and does not manage upgrades: pulling a new Hermes image is still a manual event with no rollback unless you version the volume yourself. One agent on a box you already tend is a fine home for it. A fleet on that same box is a memory-contention incident waiting for a weekend you had other plans for.

Push a container, get a URL: pleasant deploys for a runtime these platforms were not shaped for.

Best for: Developers who want Hermes in the cloud without doing Linux administration, for one or two agents.

Container platforms like Fly.io and Railway make the first deploy delightful: push an image, attach a volume, get TLS and a URL for the Hermes dashboard in minutes, with crash restarts built in. For a developer who does not want to run a VPS, this is a legitimate middle path and a real quality-of-life upgrade over raw Linux.

The friction is that Hermes is the opposite of the workload these platforms optimize for. They are built for stateless services that scale horizontally and ideally scale to zero; Hermes is a stateful, always-on, single-instance process. So you must pin the persistent state to a volume in one region, disable auto-stop so the agent is not put to sleep mid-task, and accept that an always-on machine plus storage erodes the cheap sticker price. It works, and for one agent it works fine. At fleet scale you are still doing per-agent version management, health interpretation and recovery yourself, just through a nicer CLI.

Maximum control, maximum build: recreate an agent platform from parts.

Best for: Platform teams that need full control, have real infra engineers, and accept building agent operations as a project.

Kubernetes gives you the raw ingredients a Hermes fleet needs: scheduling, restarts, resource limits, secrets, storage classes. If your organization already runs clusters and your data or compliance posture demands full control, it is a defensible foundation, and it is the only DIY option here that structurally scales past a handful of agents.

The catch is that Kubernetes has no idea what a Hermes agent is. A naive Deployment will crashloop a broken agent forever, liveness probes cannot tell a thinking agent from a wedged one, and nothing out of the box versions agent state, repairs configs, manages per-agent Hermes versions, or stops co-located agents from spiking RAM in unison. You end up designing pod lifecycle, state versioning, density control and upgrade pipelines yourself: months of platform engineering before the first client-grade agent, and an ongoing ops commitment after. Build it if agent infrastructure is your product; otherwise you are funding a second company inside your company.