People treat the cloud as a switch: everything local, or everything moved. There is a middle setting: the agent stays on your laptop, its commands run elsewhere. That setting is what most people actually need.
In this pagewhat this setting solves, the seven backends, who it suits. Not in this pagemy remote machines, their addresses or configuration.
An always-on agent has two halves, and they can live in different places:
| Half | Does | Where it wants to be |
|---|---|---|
| The brain | Talks to the model, decides what is next | Local is easiest: your config, your memory, right there to look at |
| The hands | The environment where commands actually execute | Anywhere — and remote has extra upside |
| Upside | Why |
|---|---|
| Isolation | When it wrecks the environment, it wrecks the remote box, not your laptop |
| A clean environment | A dedicated machine, free of your local version conflicts |
| No workflow change | You still type on your own computer. Nothing about your day changes |
Using Hermes as the example — seven execution backends, read along isolation and cost:
| Backend | Isolation | Cost | Suits |
|---|---|---|---|
local | None | Zero | Work you fully trust |
Docker | Process / filesystem | Zero (local resources) | The default choice for local isolation — no extra machine |
SSH | Whole machine | One machine | This page's setting — most natural if you already have a box |
Modal / Daytona | Whole machine | Hibernates idle, near-zero | Infrequent use, isolation still wanted |
Singularity | Container | Depends | Research / HPC environments |
Vercel Sandbox | Managed sandbox | Usage-based | Already in that ecosystem |
Modal, Daytona and similar hibernate when unused, costing almost nothing, then wake with state intact.
That resolves a standing awkwardness with always-on agents: you need "available whenever", not "running always". Traditionally those were the same purchase — either a machine burning money continuously, or rebuilding the environment every time.
If all you want is "do not let it wreck my computer", the Docker backend is enough. No machine, no money.
You only genuinely need a remote box when you also need a fixed egress address, round-the-clock availability, or an independent network position — which is the next page's three tests.
The practical convenience of the SSH backend is that it only needs something you can SSH into: a work dev box, a shared build machine, a temporary cloud instance.
So you need not buy a machine to try this. Use what you already have, confirm the model fits how you work, then decide about buying.
| Not fixed | Why |
|---|---|
| Close the laptop, it stops | The brain is still local. Round-the-clock means moving all of it |
| Scheduled work | Same reason: your machine sleeps, the scheduler sleeps |
| Exposed secrets | The remote holds keys too. What is isolated is the environment, not the secrets — see page 22 |
| The remote getting wrecked | Your laptop is safe; that box still gets wrecked. So do not keep anything irreplaceable on it |
If its purpose is to let an agent make a mess, it has to be rebuildable at will. Anything that would take half a day to reconstruct should not exist only on that machine.
How to get to "rebuild in one command": page 22.