Hermes Cloud: start with a hosted agent

A machine you do not own, running the same open-source harness you would otherwise install yourself. The vendor's definition, in its own words: "Hermes Cloud runs your own hosted Hermes Agent on a dedicated cloud instance that stays always on, with its own workspace and dashboard." (the Cloud page, read 6 October 2026.)

It keeps what it learns. The workspace is dedicated and persistent, so "its files, memory, and configuration stay with it and build up over time, whether it is running or stopped" — the same page. Stopping pauses the meter for compute, not the data.

Those rates are the vendor's, read 6 October 2026, and they exclude inference and tool usage, which are "billed separately, on top of the instance price". Run Medium for a month without stopping and it is $16.80 by our arithmetic on the vendor's own daily rate; stopped for the same month it is $0.90. Usage is calculated once a day in arrears, metered to the second of uptime, and charges usually appear within a day or two. Deploying needs $2 of credit or an active subscription.

Three steps. The vendor puts the whole of it at "two clicks and about 60 seconds" — their timing, not our measurement.

• Sign in to the Nous Portal and add credit to the balance. The minimum is $2, or an active subscription.
• Open Cloud, give the agent a name, and choose a model and a size. The size can change later: stop the instance, change the size, start it again.
• Deploy. When provisioning finishes, the dashboard is ready and the agent is running.

You also choose where it sits. The page listed fourteen locations when we read it, among them London, Amsterdam, Paris, Frankfurt, Stockholm, Mumbai, Tokyo, Singapore, Sydney and Toronto.

Then talk to it. Open its dashboard from the portal and chat in the browser, or connect messaging channels such as Telegram and Discord so it reaches you where you already are. Everything is managed from the agent's dashboard — the vendor's sentence, and in practice the page you will keep open for the first week.

Safer than running the same agent on your laptop, because the worst case lands in a container you can throw away rather than in your home folder — and that is the vendor's reasoning, not our reassurance. The docs tell you to turn approvals off only "in trusted environments (CI/CD, containers, etc.)", and note that inside a container destructive commands "can't harm the host", which is why the dangerous-command checks are skipped there (Security, running it safely on a machine that matters).

What holds when the mode does not:

• A floor no setting overrides. rm -rf /, fork bombs and zeroing a disk are refused whichever mode is set: --yolo toggled on, approvals off, a scheduled job running headless, or someone clicking "allow always". The docs say there is no override flag.
• Prompts fail closed. If nobody answers within the timeout, the command is denied rather than allowed.
• Unattended work denies by default. Scheduled jobs, one-shot runs and webhook sessions block a dangerous command instead of waiting for a person who is not there.
• Some files cannot be written at all: your SSH keys, cloud credentials and netrc, /etc/sudoers, the agent's own .env and auth files, and any project .env. The write is refused with no prompt and no override.
• You can narrow it later, and this is the part that builds trust: deny rules that hold even under yolo mode, a write sandbox that pins file edits to a directory, a tool that mines your past approvals into a proposal, and per-session tool lists.

hermes approvals suggest
hermes approvals suggest --apply 1,3

Expect the first hour to be unnerving. A useful agent acts before you have a theory of what it will do, and that is uncomfortable in a way no reassurance fixes. Three things make it bearable: the log, which tells you what it actually did; the deny rule, which is how you answer the one thing that bothered you; and the stop button, which costs $0.03 a day to use.

Two things the vendor's pages do not say, so we will not imply them. They do not state which approval mode a hosted instance starts in — check that first in your instance, rather than assuming. And they never claim a hosted instance is segregated from your own machines; what is documented is its own hardened container, its own persistent workspace, and an image built with the project's own hardening. What connects the instance to your world is what you attach: keys, and messaging channels. Inventory that surface before you widen anything else (API keys and permissions, What to let your agent touch).

An agent, in Hermes, is a profile: its own config file, its own environment file, its own SOUL.md, its own memories, sessions, skills, scheduled jobs and state database (profiles). Making one is a command; changing one is an edit.

• Change who it is by editing SOUL.md, the first thing in its system prompt.
• Give it a job by adding a skill: a folder with a SKILL.md in it.
• Put repeating work on a schedule, and let each job carry its own model, so a cheap model does the watching and an expensive one does the thinking.
• Keep the live copy in Git, because a change to a prompt you cannot diff is a change you cannot undo (Keep your agent in Git).

hermes profile create research --clone

In the Cloud the same idea has an interface: the portal's agents page lists your instances, and a desktop install can register a Cloud instance so its bots appear in one roster beside your local ones — a bot's chats, sessions, memory and routines stay on the machine that owns the profile (multi-connection). You can also drive instances from a local install over MCP: list them, read status and a cost estimate, start, stop, restart, create. The vendor's own limit is worth knowing — such a connection "can only touch instances you already control from the web UI" (the MCP guide).

Reading one is faster than designing one, and three in our catalogue solve their problem three different ways. All are free to download, and each carries the upstream commit it was built from plus the reviewer's notes — including what failed.

What they differ on, which is the useful part:

• Memory. One pack runs a vector store and a notes store side by side; another keeps three tiers of notes and promotes what proves useful; a third writes everything to a file you can grep.
• Data. A product-catalogue knowledge graph in one, paid market-data keys behind a preflight check in another, and no data at all in a third.
• Storage and backup. A queue for everything outbound, cron presets and enablement scripts for the recurring runs, and a test suite that runs before the job does.
• Context. Markdown layers a person can read and edit, rather than a prompt buried in code.
• Permissions. Read-only by default on the risky half, with the reason written down next to it.

The pack's own README usually documents the fastest install, and on a hosted agent the fastest install is the same trick: ask the agent, in its chat, to do the repository work.

Please install the profile from this repository, keep its access read-only,
and show me how to run its main routine when the install finishes.