Cada instalación de Hermes Agent tiene un ajuste de sandbox que decide dónde se ejecutan en realidad los comandos de shell. La elección tiene peso: marca el radio de daño de un mal comando, lo rápido que se siente el agente y cuánto pagas por hora activa.
Hermes trae siete backends. El README los enumera: local, docker, ssh, singularity, modal, daytona, vercel. v0.14.0 añadió Vercel Sandbox para cerrar la lista. Aquí va el árbol de decisión.
Los 7 backends en una tabla
| Backend | Aislamiento | Latencia | Coste | Persistencia | Para qué va |
|---|---|---|---|---|---|
| local | Ninguno | <10 ms | Gratis | Sí (tu disco) | Dev solo en una VM desechable |
| Docker | Contenedor | ~50 ms | Gratis | Por contenedor | Por defecto en cualquier máquina de desarrollo |
| SSH | Lo que sea el remoto | Latencia remota | Coste remoto | Sí | Cuando el agente corre en la máquina de otro |
| Singularity | Contenedor HPC | ~100 ms | Gratis | Por contenedor | Clusters HPC, cálculo científico |
| Modal | Contenedor serverless | ~200 ms en frío | Pago por segundo activo | Snapshot-able | Cálculo en ráfagas, GPU |
| Daytona | Workspace serverless | ~300 ms en frío | Pago por segundo activo | Hiberna inactivo | Entornos de agente longevos, coste casi nulo en idle |
| Vercel Sandbox | Contenedor serverless | ~200 ms en frío | Pago por segundo activo | Efímero | Tooling web, flujos pesados en JS |
local y docker son gratis y viven en tu máquina. Los otros cinco corren en otro sitio — pagas en latencia, pagas en dinero, pero te llevas algo a cambio.
Cuándo elegir cada uno
local — "me fío de este agente en esta máquina"
El agente ejecuta comandos directamente sobre tu sistema de archivos con tus permisos de usuario. Cero aislamiento. Si el agente decide rm -rf ~/code, lo hace. Si entra una inyección de prompt en la salida de una tool, el comando inyectado corre.
Cuándo es la decisión correcta: estás cacharreando en una VM desechable, el agente hace cosas que tú harías a mano con el mismo radio de daño, y la latencia a cero te importa más que el margen de seguridad.
Cuándo es la decisión equivocada: prácticamente cualquier otro momento.
docker — el por defecto correcto
Un contenedor en tu máquina, aislado por namespaces de Linux. La vista del sistema de archivos del agente es la del contenedor; tu /home real queda oculto a menos que lo montes.
hermes config set sandbox docker y hermes setup se descargan y configuran la imagen. A partir de ahí, cada llamada a tool de shell pasa por el contenedor.
Esto es el por defecto correcto para el ~80% de la gente. El sobrecoste de latencia (~50 ms por comando) no se nota en chat. El aislamiento es lo bastante fuerte como para que un rm -rf / solo arrase la vista del contenedor, y el contenedor es desechable. Si necesitas depurar, entras con docker exec.
ssh — "el agente vive en otra máquina"
Las tools de shell del agente se ejecutan vía SSH en un host remoto. Tu proceso local de Hermes es el cliente; el trabajo pasa en el remoto.
Esta es la elección correcta cuando el trabajo del agente pertenece al remoto — desplegar a un servidor, depurar logs de producción, correr migraciones. No necesitas un sandbox local porque el host es el sandbox.
El remoto tiene que ser una máquina en la que estés cómodo dándole shell al agente. Trata las credenciales SSH como credenciales de producción, porque eso es exactamente lo que son.
singularity — clusters HPC
Singularity (ahora Apptainer) es el runtime de contenedores que los clusters HPC usan de verdad, porque Docker pide root en el host y los entornos HPC no lo dan. Si estás corriendo Hermes en un cluster de investigación — planificado con SLURM, sin Docker, lleno de GPUs — esta es la opción.
Si no reconoces las palabras "HPC" o "Singularity", sáltatelo.
modal — cálculo en ráfagas, sobre todo con GPU
Modal es una plataforma serverless de contenedores. Hermes levanta un contenedor Modal por comando (o por sesión, reutilizando), ejecuta y desmonta. Pagas por segundo de cómputo activo. Hay niveles con GPU.
Cuándo gana a Docker: el agente necesita GPUs, o recursos de cómputo que exceden tu máquina local. Cuándo gana a otras serverless: el arranque en frío son ~200 ms, asumible para uso de tool a ritmo de chat, y el snapshotting es lo bastante bueno como para que el estado de media sesión sobreviva bien.
daytona — longevo, casi-cero en idle
El asesino de Daytona es la hibernación. El entorno de tu agente se duerme cuando no pasa nada y se despierta a demanda en unos cientos de ms. Pagas los segundos activos, no los de idle.
Efecto práctico: puedes tener un entorno "mi Hermes" con tus dotfiles, tus skills, tu trabajo a medias, que vive durante meses a coste casi nulo porque solo pagas cuando lo usas.
Esta es la elección correcta si quieres un agente que "viva en algún sitio" sin estar en tu portátil. La primera petición tras un idle largo tarda ~300 ms en despertar; las siguientes van a velocidad de contenedor.
vercel — Vercel Sandbox (v0.14.0)
El backend más nuevo, añadido en v0.14.0. Mismo modelo de contenedor serverless que Modal, pero sobre la infraestructura de Vercel. Si Vercel ya es tu objetivo de despliegue, esta es la opción con menos fricción para tener el sandbox del agente en el mismo proveedor.
Para qué va mejor: flujos pesados en JS donde quieres que el entorno del agente refleje el entorno de despliegue de producción.
Cómo cambiar
hermes config set sandbox docker
# o: local, ssh, singularity, modal, daytona, vercel
Para los backends que requieren credenciales (ssh / modal / daytona / vercel), hermes setup te las pide; o las pones tú vía hermes config set siguiendo la documentación.
También puedes hacer override por sesión si te hace falta: hermes --sandbox modal para una ejecución que necesita GPU, volviendo al sandbox por defecto después.
¿Y si paso del sandbox?
Puedes desactivar el sandboxing entero (backend local), pero Hermes pone encima una capa de aprobación de comandos: los comandos peligrosos como rm -rf, curl | sh o cualquier cosa que toque /etc te piden aprobación explícita antes de ejecutarse. v0.14.0 endureció esta capa con tres cierres de bypass de comandos peligrosos y un bloqueo de fuerza bruta para sudo (#23736, #26829). Así que ni siquiera local es "nada" — es "aislamiento más ligero pero prompts reales". El artículo del modelo de seguridad desglosa capa a capa.
La recomendación honesta
Para la mayoría, la mayoría del tiempo: Docker.
Si quieres que el agente viva en un servidor que no es tu portátil: Daytona (la hibernación en idle es genuinamente mágica y las cuentas salen).
Si tienes cargas con GPU o el agente hace cómputo real: Modal.
Investigadora o investigador en un cluster: Singularity.
Local solo si entiendes la concesión. SSH solo cuando el trabajo pertenece al remoto. Vercel si ya estás en Vercel.