Como Autohospedar um Agente Hermes em um VPS

Olá, eu sou a Lena. Estou rodando Hermes Agent selfhosting em três VPS diferentes há alguns meses, e minha observação honesta é a seguinte: instalá-lo em um servidor leva talvez vinte minutos. Fazer com que ele rode de forma estável por semanas sem precisar cuidar das crianças leva várias iterações. Ainda não tenho certeza se acertei a terceira caixa, na verdade. Essa é a lacuna que este guia trata — não a instalação, mas a camada lenta entre "funciona uma vez" e "confio que ele vai continuar funcionando enquanto durmo."

Se você só precisa do caminho oficial de instalação, a documentação de instalação do Hermes Agent cobre isso. Essa parte é o que vem depois.

Quando autohospedar Hermes faz sentido

Privacidade, continuidade, controle de custos, fluxos de trabalho sempre ligados

Antes de qualquer coisa sobre servidores — autohospedagem é um compromisso, não um atalho. Faz sentido quando você precisa de um ou mais desses:

Privacidade. Suas conversas, memórias e habilidades permanecem na infraestrutura que você controla. As chamadas de API ainda são enviadas para o provedor de modelo que você configurou, mas tudo ao redor delas — histórico de sessões, perfil de usuário, arquivos de workspace — permanece local.

Continuidade. Um laptop que entra em modo de dormência ou fecha mata um agente local. Um VPS não mata isso. Se você quer que o agente responda uma mensagem do Telegram às 3h da manhã ou execute um cron agendado para o qual você não precisou abrir um terminal, você precisa dele em outro lugar.

Controle de custos. A autohospedagem não reduz os custos do modelo — esses são o que o provedor cobra. O que isso muda é o custo geral: sem licenciamento de assento, sem preço por usuário em um plano gerenciado, apenas o custo da caixa mais os tokens do seu provedor.

Fluxos de trabalho sempre ativos. Integrações de gateway (Telegram, Discord, Slack, bots de mensagens) só fazem sentido se o agente estiver sempre ouvindo. O mesmo vale para trabalhos cron.

Se nada disso se aplica e você usa o agente por trinta minutos à noite no seu laptop, honestamente — não faça autohospedagem. A complexidade não vale a pena.

! [imagem] (https://uploads.evomap.ai/blog/ebab901cfe9b4a55.png)

Escolha um VPS e um sistema operacional base para Hermes

Especificações mínimas vs recomendadas

É aqui que quero contestar a abordagem "funciona com um VPS de $5". Tecnicamente verdade. Praticamente frágil. Aqui está o que eu realmente observei:

1 vCPU / 1 GB RAM: Inicializa. Vai travar sob qualquer carga real. Python + Node + os próprios processos do agente consomem RAM rapidamente, especialmente quando o gateway está em execução. Já tive um desses travado durante uma única sessão de depuração.
2 vCPU / 2 GB RAM: Funciona para uso somente via CLI, usuário único, sem gateway. Ainda é apertado. Swap ajuda, mas não resolve.
2 vCPU / 4 GB RAM: Meu mínimo no mundo real para gateway + cron + habilidades leves. É aqui que as coisas param de parecer instáveis.
2–4 vCPU / 8 GB RAM: Confortável para uso com múltiplos perfis, várias plataformas conectadas e espaço para tarefas pesadas ocasionais.

Sistema base: Ubuntu 22.04 ou 24.04 LTS. Eu uso ambos. Debian 12 também funciona bem. Qualquer outro, você está por conta própria nos casos de dependências.

Armazenamento: 30–40 GB é mais que suficiente para o agente em si. Bancos de dados de sessão crescem lentamente — talvez 50 MB por mês de uso ativo. Logs são a coisa que pode surpreender, voltarei a isso.

O que muda quando o gateway e o cron rodam continuamente

Esta é a parte que quase esqueci de aprender da maneira difícil. Executar o Hermes interativamente é diferente de executá-lo como um serviço persistente. Quando o gateway está sempre escutando e o cron disparando tarefas agendadas, você tem:

Residência constante na memória (sem estado ocioso coletado pelo garbage collector)
Volume contínuo de logs
Repetição de rede que pode se acumular durante falhas de provedores
Manipuladores de arquivos que precisam sobreviver a reinícios
Segredos (chaves de API, tokens) que devem estar acessíveis ao serviço, não apenas ao seu shell

Não tenho certeza se estou interpretando corretamente, mas minha impressão é que a maioria dos relatos "meu VPS está ficando sem memória" são realmente "dimensionei para uso interativo e depois liguei gateway + 4 jobs de cron." Planeje para a carga persistente, não para a vazia.

Instalar e reforçar o Hermes em um servidor

Usuário do serviço, layout de diretórios, atualizações, backups

Não execute o Hermes como root. Este é o único ponto não negociável. Crie um usuário dedicado:

Bash

sudo adduser hermes
sudo usermod -aG docker hermes   # only if you plan to use the Docker terminal backend

Então instale como esse usuário. Tudo vai para ~/.hermes/ — configuração, sessões, memória, habilidades. Esse diretório é o seu estado. Faça backup dele.

Meu backup real é simples:

Bash

tar -czf hermes-backup-$(date +%F).tar.gz ~/.hermes/

Execute semanalmente via cron, envie o arquivo tar para fora do servidor (armazenamento de objetos, outro VPS, o que for). O que você quer proteger é config.yaml, o banco de dados de sessões, e MEMORY.md/USER.md. Habilidades são recuperáveis do hub. Memória e configuração não são.

Para atualizações: o instalador vem com um caminho de atualização. Mas aprendi a tirar um instantâneo ou fazer um backup antes de qualquer atualização, porque ocasionalmente uma atualização altera o esquema de configuração e eu não quero descobrir isso no meio de uma conversa. As informações de versão estão visíveis no repositório Hermes Agent no GitHub se você quiser verificar os changelogs antes de aplicar a atualização.

Firewall: mantenha a superfície pública do VPS mínima. UFW é o caminho mais simples — a documentação de firewall do Ubuntu Server explica bem. Minhas regras para uma máquina Hermes-only são aproximadamente assim:

Bash

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow ssh
sudo ufw enable

É isso. Hermes não precisa de nenhuma porta de entrada aberta na maioria das configurações — o gateway se conecta externamente às plataformas de mensagens. Se você adicionar uma interface web ou expor uma API localmente, aí sim abra uma porta específica.

Executando o gateway sob systemd

Esta é a parte que transforma um processo em execução em um serviço. Sem systemd (ou algo equivalente), no momento em que sua sessão SSH termina, também termina hermes gateway. Eu perdi um bot do Telegram por causa disso pelo menos uma vez antes de realmente escrever o arquivo de unidade.

Aqui está o modelo que uso. Salve como /etc/systemd/system/hermes-gateway.service:

TOML

[Unit]
Description=Hermes Agent Gateway
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=hermes
Group=hermes
WorkingDirectory=/home/hermes
ExecStart=/home/hermes/.local/bin/hermes gateway start
Restart=on-failure
RestartSec=10
StandardOutput=journal
StandardError=journal

[Install]
WantedBy=multi-user.target

Então:

Bash

sudo systemctl daemon-reload
sudo systemctl enable --now hermes-gateway
sudo systemctl status hermes-gateway

Alguns detalhes que gostaria que alguém tivesse me dito antes. Restart=on-failure + RestartSec=10 é o mínimo. Sem isso, qualquer erro transitório mata o serviço permanentemente. A página de manual systemd.service tem a lista completa de políticas de reinício — on-abnormal é uma alternativa se você quiser permitir que o serviço escolha sair limpo sem reinício automático.

Além disso — User=hermes está fazendo o trabalho real aqui. Não é apenas segurança. Isso garante que o serviço leia do diretório ~/.hermes/ do usuário hermes e não do root (que não existirá, e você receberá um erro de configuração críptico). Eu errei nisso na primeira vez.

Para fortalecer ainda mais o arquivo de unidade — NoNewPrivileges=true, ProtectSystem=strict, PrivateTmp=true — não vou reproduzir tudo aqui, mas o guia da DigitalOcean sobre unidades e arquivos de unidade do systemd mostra um exemplo endurecido em estilo de produção que vale a pena copiar.

Verificações de produção antes de confiar na configuração

Comportamento de reinício, logs, falha do provedor, persistência de arquivos

Antes de considerar uma máquina "pronta", faço quatro verificações. Nenhuma delas é opcional. Pulei em uma máquina que pensei conhecer e me arrependi.

Reinício sobrevive a um reboot

Bash

sudo reboot
# wait, then:
ssh back in
systemctl status hermes-gateway

Se o serviço não estiver ativo após o reboot, você esqueceu enable. Corrija agora.

Os logs são legíveis e rotativos.

Bash

journalctl -u hermes-gateway -n 100
journalctl -u hermes-gateway --since "1 hour ago"

Importante — defina limites do journal antes que o disco encha. Edite /etc/systemd/journald.conf e defina SystemMaxUse=500M (ou o que for adequado para sua máquina). A página do systemd journal na Arch Wiki explica as opções de rotação e limpeza em mais detalhes do que a maioria dos documentos específicos de distro. Eu aprendi isso rodando uma máquina que ficou sem espaço de disco completamente. Não é divertido.

Falha de provedor é recuperável.

Quebre temporariamente sua chave de API (renomeie a variável de ambiente, revogue o token, qualquer coisa). Envie uma mensagem pelo gateway. O serviço trava? Ele registra o erro? Ele se recupera quando você restaura a chave?

Minha expectativa básica: o agente deve registrar um erro claro e continuar funcionando, não morrer. Se ele morrer, você tem um problema operacional que é melhor descobrir agora do que às 3 da manhã.

Persistência de arquivos entre reinicializações.

Tenha uma conversa. Envie uma mensagem. Reinicie o serviço. Retome a sessão. A memória persiste? A sessão sobrevive? Se não, verifique as permissões ~/.hermes/ — isso quase sempre é uma questão de usuário/grupo.

Erros comuns em VPS

Memória RAM insuficiente, logs fracos, acesso inseguro ao shell, sem caminho de reversão

Os quatro modos de falha que vejo com mais frequência, na ordem aproximada em que eu mesmo os cometi:

RAM insuficiente. Já foi abordado. 2 GB é o mínimo, não a meta.

Logs fracos ou ilimitados. Se você não configurar limites de tamanho do journal, seus logs vão consumir o disco. Quando o disco encher, o agente falha de maneiras estranhas — escritas de configuração falham silenciosamente, skills não podem ser salvos, sessões corrompem. Defina os limites desde o primeiro dia.

Acesso inseguro ao shell para o agente. Se você permitir que o agente execute comandos arbitrários do shell com o backend do terminal configurado para local e estiver rodando como usuário com direitos de sudo, a área de impacto de um erro é toda a sua máquina. Ou use terminal.backend=docker para isolar, ou execute sob um usuário dedicado sem sudo. Eu prefiro ambos.

Sem caminho de reversão. Uma atualização ruim, uma edição de configuração ruim, e você precisa de um caminho de retorno. Faça um snapshot do VPS antes de qualquer mudança grande. Mantenha os últimos três backups tarball. Eu usei eles. Já me salvaram.

FAQ

Preciso do Docker?

Não é obrigatório, mas recomendado para o backend do terminal se você for permitir que o agente execute comandos arbitrários. Sandbox mais seguro.

Posso rodar múltiplos perfis em um VPS?

Sim — hermes profiles create work, depois troque entre eles. Cada um tem configuração, memória e skills isolados.

Como atualizo sem tempo de inatividade?

Você realmente não pode, mas o tempo de inatividade é curto. Pare o serviço, puxe a atualização, reinicie. Um ou dois minutos.

Posso executar o gateway e o CLI** ao mesmo tempo?**

Sim, desde que estejam no mesmo perfil. As sessões são compartilhadas.

E se meu provedor cair?

Não há nada que você possa fazer sobre o provedor, mas se o Hermes estiver configurado para fallback de provedor, ele tentará o próximo. Se você não tiver configurado fallback, o gateway exibirá um erro limpo e se recuperará quando o provedor voltar.

Talvez eu esteja pensando demais nisso, mas o padrão que eu continuo voltando é: o VPS não é a parte difícil. A parte difícil é a descoberta lenta e silenciosa de tudo que pode dar errado ao longo de um mês de tempo de atividade.** Essa é realmente a natureza do self-hosting. Vou continuar observando como minha própria configuração se comporta, e provavelmente atualizarei isso quando eu quebrar algo novo. Por enquanto, é onde vou deixar.