SEAOTTER

Always-on AI Agents. No servers to run.

Visit Website
August 29, 2026 Made a hosting thing for Hermes agents because I was sick of being on-call for my own VPS

Been running Hermes Agent for myself. Every time it was the same:

rent a box, SSH in, install everything, and now I'm the guy who has

to notice something crashed at midnight because nothing alerted me.

Secrets just sat in a .env file on the box. No rotation, nothing. If

that box ever got popped, that's it, everything's gone.

Built SEAOTTER to get away from that. Each agent gets its own

sandbox and namespace instead of sharing a box or needing its own

VPS. Restart/pause/restore from an API, no SSH. Works with Claude,

Cursor, Codex over MCP.

Also built it thinking about agencies , one isolated agent per

client instead of a VPS per client , but that's a guess at demand,

not something I've had clients ask for yet.

14-day free trial, Hobby plan. Heads up it wants a card at checkout

right now, still figuring out a way around that.

Mostly want to hear from other people running Hermes or something

like it on a VPS - what would make you actually switch off it, and

if you've dealt with the secrets-on-a-box thing, how'd you handle it.

seaotter.dev

5 Comments

  1. 1

    The agency angle is interesting, but I think the bigger opportunity is making isolation operationally effortless.
    One isolated agent per client sounds great, but the real headache may appear when an agency has to manage dozens of agents across clients.
    Centralized health monitoring, secret rotation, audit history, and per-client usage/cost visibility could become just as valuable as the sandbox itself.
    That could turn SEAOTTER from "hosting without the VPS headache" into a real agent operations layer for teams.
    Curious whether multi-agent management is on the roadmap yet?

    1. 1
      Good question — I checked the API docs to answer this properly rather than guess. Turns out most of this is already there, not on a future roadmap. List Agents, per-agent Metrics, Logs, Rotate Credentials, and an org-level Audit Log (list + export) are all live endpoints today, along with per-agent usage tracking. So the building blocks for "operations layer" exist in the control plane right now. What doesn't exist yet, as far as I can tell, is a first-party dashboard that rolls all of that up across an agency's full client fleet in one screen — today you'd compose it yourself via the API (list agents, then pull metrics/logs/audit per agent). So probably a better way to frame it: multi-agent management isn't missing, it's just API-level rather than UI-level right now. Whether a unified fleet dashboard ships natively is the real open question. For reference -> https://docs.seaotter.dev/api-reference/overview
      1. 1
        That’s a much more interesting distinction. If the operational primitives already exist at the API level, the real product opportunity may be turning that complexity into a zero-friction agency experience. I’d be curious whether you see the unified fleet dashboard as the next UX layer especially around cross-client health, incidents, and cost visibility. That could be a strong differentiator for agencies managing agents at scale.
  2. 1
    As a former Hermes user on VPS, I can attest that the reason to consider switching to a managed control plane like SEAOTTER is threefold: 1) ops burden, 2) isolation, 3) secrets management. Having all these packaged into one allows you to focus more on your automations.
  3. 1

    The “become the operator of your own VPS” pain feels like the stronger wedge here.

    Curious what actually makes users consider switching: the operational burden, the isolation model, or the secrets problem.

About

Running Hermes Agent meant owning a VPS — SSHing in at midnight, secrets sitting in a plain .env file. SEAOTTER gives every agent its own gVisor sandbox and namespace, so it's properly isolated without a VPS per agent.