Toda instalação do Hermes Agent tem um setting de sandbox que decide onde os comandos de shell realmente rodam. A escolha pesa: define qual o raio de estrago de um comando ruim, o quão rápido o agente parece e quanto você paga por hora ativa.
O Hermes traz sete backends. O README lista eles: local, docker, ssh, singularity, modal, daytona, vercel. A v0.14.0 acrescentou o Vercel Sandbox pra fechar o time. Aqui vai a árvore de decisão.
Os 7 backends, em uma tabela
| Backend | Isolamento | Latência | Custo | Persistência | Pra quê serve melhor |
|---|---|---|---|---|---|
| local | Nenhum | <10 ms | Grátis | Sim (seu disco) | Dev sozinho em VM descartável |
| Docker | Contêiner | ~50 ms | Grátis | Por contêiner | Padrão em qualquer máquina de dev |
| SSH | O que a máquina remota tiver | Latência remota | Custo remoto | Sim | Rodando na máquina de outra pessoa |
| Singularity | Contêiner HPC | ~100 ms | Grátis | Por contêiner | Clusters HPC, computação científica |
| Modal | Contêiner serverless | ~200 ms a frio | Pago por segundo ativo | Snapshotável | Computação em rajadas, GPU |
| Daytona | Workspace serverless | ~300 ms a frio | Pago por segundo ativo | Hiberna em idle | Ambientes de agente duradouros, custo idle quase zero |
| Vercel Sandbox | Contêiner serverless | ~200 ms a frio | Pago por segundo ativo | Efêmero | Tooling web, fluxos pesados em JS |
local e docker são grátis e rodam na sua máquina. Os outros cinco rodam em outro lugar — você paga em latência, paga em dinheiro, mas em troca compra alguma coisa.
Quando pegar cada um
local — "Eu confio nesse agente nessa máquina"
O agente roda comandos direto no seu filesystem com suas permissões de usuário. Isolamento zero. Se o agente decidir rm -rf ~/code, vai. Se uma prompt injection cair na saída de uma tool, o comando injetado roda.
Quando essa é a escolha certa: você tá brincando numa VM descartável, o agente tá fazendo coisa que você faria à mão com o mesmo raio de estrago, e a latência baixa pesa mais que a margem de segurança.
Quando é a escolha errada: praticamente todo o resto do tempo.
docker — o padrão certo
Um contêiner na sua máquina, isolado por namespaces de Linux. A visão de filesystem do agente é a do contêiner ; seu /home de verdade fica escondido a menos que você monte.
hermes config set sandbox docker mais hermes setup puxam e configuram a imagem. Daí em diante, toda chamada de tool de shell passa pelo contêiner.
Esse é o padrão certo pra uns 80% dos usuários. O overhead de latência (~50 ms por comando) é invisível no chat. O isolamento é forte o bastante pra um rm -rf / só estourar a visão do contêiner, e o contêiner é descartável. Se você precisa debugar, dá pra docker exec lá dentro.
ssh — "O agente mora numa máquina diferente"
As tools de shell do agente executam via SSH num host remoto. Seu processo Hermes local é o cliente ; o trabalho acontece no remoto.
Essa é a escolha certa quando o trabalho do agente pertence ao remoto — deploy num servidor, debug de logs de produção, rodando migrations. Você não precisa de sandbox local porque o host é a sandbox.
O remoto precisa ser uma máquina onde você tá tranquilo de dar acesso shell ao agente. Trata as credenciais SSH como credenciais de produção, porque é o que são.
singularity — clusters HPC
Singularity (agora Apptainer) é o runtime de contêiner que clusters HPC usam de verdade, porque Docker exige root no host e ambientes HPC não dão isso. Se você roda Hermes num cluster de pesquisa — agendado por SLURM, sem Docker, com vários GPUs — essa é a escolha.
Se você não reconhece as palavras "HPC" ou "Singularity", pula esse item.
modal — computação em rajadas, sobretudo GPUs
O Modal é uma plataforma serverless de contêineres. O Hermes sobe um contêiner Modal por comando (ou por sessão, com reuso), executa, derruba. Você paga por segundo de computação ativa. Existem tiers de GPU.
Quando ganha do Docker: o agente precisa de GPUs ou recursos de computação além da sua máquina local. Quando ganha de outras serverless: o cold start é de uns ~200 ms, aceitável pra uso de tool em ritmo de chat, e o snapshotting é bom o suficiente pra estado em meio de sessão sobreviver razoavelmente.
daytona — duradouro, idle quase zero
O killer feature do Daytona é a hibernação. O ambiente do agente dorme quando nada tá rolando e acorda sob demanda em algumas centenas de ms. Você paga segundos ativos, não segundos de idle.
Efeito prático: dá pra ter um ambiente "meu Hermes" com seus dotfiles, seus skills, seu trabalho em andamento, que vive por meses com custo quase zero porque você só paga quando usa.
Essa é a escolha quando você quer um agente que "mora em algum lugar" sem ficar no seu laptop. A primeira requisição depois de muito idle leva ~300 ms pra acordar ; as próximas vão na velocidade de contêiner.
vercel — Vercel Sandbox (v0.14.0)
O backend mais novo, somado na v0.14.0. Mesmo modelo de contêiner serverless do Modal, mas na infra da Vercel. Se você já tem Vercel como destino de deploy, essa é a escolha com menos atrito pra colocar a sandbox do agente no mesmo provider.
Combina especialmente bem com: fluxos pesados em JS onde você quer que o ambiente do agente espelhe o de produção.
Como trocar
hermes config set sandbox docker
# ou: local, ssh, singularity, modal, daytona, vercel
Pros backends que precisam de credenciais (ssh / modal / daytona / vercel), hermes setup te pergunta ; ou você seta via hermes config set direto, do jeito que a doc indica.
Também dá pra sobrescrever por sessão se for o caso: hermes --sandbox modal pra um run isolado que precisa de GPU, voltando pra sua sandbox padrão depois.
E se for sem sandbox?
Você pode desligar sandboxing por completo (backend local), mas o Hermes coloca em cima uma camada de fluxo de aprovação de comandos: comandos perigosos como rm -rf, curl | sh ou qualquer coisa que mexa em /etc pedem aprovação explícita antes de rodar. A v0.14.0 endureceu essa camada com três fechamentos de bypass de comando perigoso e um bloqueio de força bruta no sudo (#23736, #26829). Então até o local não é "nada" — é "isolamento mais leve, mas com prompts de verdade". Tem o post sobre o modelo de segurança pra uma quebra camada por camada.
A recomendação honesta
Pra maioria das pessoas, na maior parte do tempo: Docker.
Se você quer o agente morando num servidor que não é seu laptop: Daytona (a hibernação quando idle é realmente mágica, e a matemática de custo fecha).
Se você tem cargas com GPU ou o agente faz computação de verdade: Modal.
Se você é pesquisador rodando em cluster: Singularity.
local só se você entende o trade-off. SSH só quando o trabalho pertence ao remoto. Vercel se você já tá na Vercel.