Como rodar o Hermes Agent 24/7 em uma VPS

Um agente de IA que só trabalha enquanto o teu notebook está ligado não é bem um agente, é um programa aberto 🙂

E isso aparece rápido: tarefa agendada pra rodar de madrugada, mensagem chegando no Telegram a qualquer hora, rotina contínua que não pode ter buraco

A máquina pessoal dorme, cai a rede, tu fecha a tampa e acabou

O Hermes Agent é um agente de IA open source publicado pela Nous Research, no repositório NousResearch/hermes-agent, com site e documentação em hermes-agent.nousresearch.com

A versão mais recente publicada nas releases do repositório oficial é a v0.20.0 (tag v2026.8.3), de 03/08/2026

E ele nasceu pensando em servidor: o site oficial afirma que o Hermes pode viver em uma VPS de US$ 5, em um cluster de GPU ou em infraestrutura serverless que custa quase nada ociosa

Bora ver o caminho completo: o que precisa estar disponível na VPS, o passo a passo até deixar o agente como serviço do sistema, a alternativa em contêiner e o que muda de verdade em relação ao uso local

O que precisa estar disponível na VPS antes de instalar

A lista é bem menor do que parece, e essa é a boa notícia

Plataformas suportadas: Linux, macOS, WSL2, Windows nativo e Android via Termux

Fora do Windows, o pré-requisito de base é o Git

E no Linux entram mais dois: curl e xz-utils, porque o instalador baixa o Node.js como .tar.xz e precisa descompactar isso

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 116 aulas
• 4 projetos
• 9h 23min

Conhecer formação

E o que tu NÃO precisa instalar à mão? Praticamente todo o resto

• Python 3.11 (via uv)
• Node.js v22
• ripgrep
• ffmpeg

Tudo isso o instalador provisiona sozinho

Se tu vem de stacks pesadas, a régua aqui é outra: um agente não é uma loja PHP com cache e fila, então o dimensionamento de VPS para Magento 2 que te assustava não vale como referência de tamanho

A documentação coloca a conta de memória assim: 1 GB de RAM é suficiente sem as ferramentas de navegador

Com automação de browser (Playwright/Chromium), que é o recurso mais pesado, o recomendado é reservar pelo menos 2 GB

Falta um detalhe que derruba muita instalação nova: o modelo escolhido precisa de pelo menos 64.000 tokens de contexto

Janelas menores são rejeitadas no startup, então não adianta plugar um modelinho curto e ficar caçando erro de rede

Passo a passo: instalar o Hermes Agent na VPS e deixar como serviço

A ideia do fluxo é simples: instala, confere dependência, autentica, registra como serviço e sobe

1. Conecte por SSH e rode o instalador de linha única

Não tem app desktop obrigatório nem instalador gráfico, é uma linha só:

curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash

Em servidor sem interface gráfica, use a flag --skip-browser durante a instalação: ela pula o componente de browser, pensado justamente pra deploy headless sem automação de navegador

O erro comum deste passo: rodar isso num Linux limpo sem curl e sem xz-utils e ver a instalação morrer no meio, porque o Node.js vem como .tar.xz

2. Confira as dependências com o doctor

hermes doctor

Esse comando mostra qual dependência falhou, o que economiza um bom tempo de adivinhação

O erro comum deste passo: pular ele e sair debugando o agente quando o problema é uma dependência do sistema

3. Autentique o provedor nativo

hermes setup --portal

Ele faz o OAuth no Nous Portal e habilita o Tool Gateway de uma vez, é o caminho mais curto

"Mas espera, OAuth num servidor sem navegador?"

Aqui tá a sacada: em ambiente headless o Hermes imprime a URL de autorização no stdout/logs em vez de tentar abrir o navegador

Tu copia a URL, abre no teu PC mesmo e pronto

O erro comum deste passo: ficar esperando um navegador que nunca vai abrir na VPS, achando que travou

4. Registre o gateway como serviço do sistema

O Hermes instala a si mesmo como serviço de segundo plano do sistema operacional (systemd no Linux, launchd no macOS, e no Windows via Scheduled Tasks com fallback na pasta de Inicialização, sem exigir admin)

Em VPS e hosts headless a documentação recomenda o serviço de sistema, não o de usuário:

sudo hermes gateway install --system

Por quê? O serviço de usuário é indicado pra laptop e máquina de desenvolvimento

Já o de sistema volta no boot sem depender do lingering do usuário, que é exatamente o que tu quer num servidor

Existe alternativa, se tu não quer envolver root: serviço de usuário com lingering habilitado

Com lingering ativado, as units de usuário do systemd (incluindo hermes-gateway-<perfil>.service) seguem rodando depois que o SSH desconecta e depois de reboot

O erro comum deste passo: instalar como serviço de usuário sem lingering em servidor, fechar o SSH e descobrir no dia seguinte que o agente parou junto com a sessão

5. Suba e confira

sudo hermes gateway start --system
sudo hermes gateway status --system

Pode chamar o status à vontade: ele é idempotente e não derruba o gateway

E pra ler log em tempo real:

journalctl -u hermes-gateway -f

O erro comum deste passo: dar por encerrado sem olhar o log, quando o startup pode estar rejeitando o modelo por janela de contexto curta

Alternativa em contêiner: rodar o gateway com Docker

Se a tua VPS já é toda em contêiner, não precisa fugir do padrão

A imagem oficial é publicada no Docker Hub como nousresearch/hermes-agent

docker run -d --name hermes --restart unless-stopped \
  -v ~/.hermes:/opt/data \
  nousresearch/hermes-agent gateway run

Repara no volume, que é a parte que importa

/opt/data é a fonte única de estado do Hermes: config, .env, perfis, skills, memórias, sessões e logs

Ele mapeia pra ~/.hermes no host, então é ali que mora a tua instalação de verdade

O erro comum deste passo (e esse dói): subir dois contêineres de gateway Hermes contra o mesmo diretório de dados

Nunca faça isso: arquivos de sessão e memória não suportam escrita concorrente

O que muda em relação a rodar o Hermes na sua máquina

A diferença não é de recurso, é de regime de operação

Na VPS o agente vira serviço de sistema, sobrevive a reboot e à desconexão do SSH, e é isso que sustenta qualquer coisa contínua

A autorização deixa de depender de navegador local, porque a URL de OAuth sai no log

E o browser normalmente cai fora com --skip-browser, o que derruba a exigência de memória de pelo menos 2 GB pro patamar de 1 GB

Tem um detalhe de manutenção que muda também

Quando o Hermes roda como serviço e o teu usuário não é root, o hermes update tenta sudo systemctl sem senha

Se não rolar, ele pula o restart e imprime o comando manual, em vez de travar num prompt interativo esperando alguém digitar

Ou seja: update automatizado não fica pendurado, mas tu precisa olhar a saída pra saber se falta reiniciar na mão

E só pra calibrar expectativa de hospedagem: os requisitos de hospedagem de uma VPS pra aplicações web tradicionais são bem mais salgados do que o que um gateway de agente pede

O que só faz sentido com o agente ligado o tempo todo

Aqui é onde a VPS deixa de ser luxo

Agendamento de tarefas:

Quem executa as tarefas agendadas é o daemon do gateway

Ele roda o scheduler a cada 60 segundos e executa os jobs vencidos em sessões de agente isoladas

Os formatos aceitos cobrem bem o dia a dia:

• atrasos relativos (30m)
• intervalos (every 2h)
• expressões cron padrão (0 9 *)
• timestamps ISO

Tem ainda o modo script-only, que roda sem chamar o modelo, com zero gasto de tokens

Muito massa pra rotina mecânica que não precisa de raciocínio nenhum

E existe uma trava importante contra cascata: sessões executadas por cron não podem criar novos jobs de cron, as ferramentas de gerenciamento ficam desabilitadas dentro da execução agendada

Sem isso, um agente distraído montaria uma fábrica de agendamentos sozinho, e aí boa sorte 😅

Mensageria sempre online:

O comando hermes gateway setup faz a configuração interativa das plataformas: Telegram, Discord, Slack, WhatsApp, Signal, Email, Home Assistant e Microsoft Teams

Não adianta ter integração de mensagem se a máquina que responde está desligada, né?

E o custo:

Se tu for pelo OpenRouter como provedor de modelos, a conta tem duas partes: 0% de markup sobre o preço de inferência dos provedores e uma taxa de plataforma de 5,5% na compra de créditos, com mínimo de US$ 0,80

Problemas comuns no deploy em VPS e como resolver

O agente não volta depois do reboot:

Sintoma: servidor reinicia, o gateway some

Causa: serviço de usuário sem lingering habilitado

Solução: instalar como serviço de sistema (sudo hermes gateway install --system) ou habilitar lingering pro serviço de usuário

Como prevenir: em VPS, escolher o serviço de sistema desde o começo, que é o recomendado na documentação justamente por isso

A instalação quebra num Linux limpo:

Sintoma: o script de instalação morre no meio

Causa: falta curl ou xz-utils, e o instalador baixa o Node.js como .tar.xz

Solução: instalar os dois e rodar hermes doctor, que mostra qual dependência falhou

Como prevenir: conferir esses dois pacotes antes de rodar a linha única, porque no Linux eles fecham a lista de pré-requisitos junto do Git

O modelo é rejeitado no startup:

Sintoma: o gateway não sobe e reclama do modelo

Causa: janela de contexto abaixo de 64.000 tokens

Solução: trocar por um modelo que atenda o mínimo

Como prevenir: checar a janela de contexto ANTES de apontar o agente pro modelo, porque janelas menores são rejeitadas no startup e não tem contorno

Sessões e memórias inconsistentes no Docker:

Sintoma: memória do agente bagunçada, sessão estranha

Causa: dois contêineres de gateway rodando contra o mesmo diretório de dados

Solução: manter um gateway por diretório de estado

Como prevenir: tratar ~/.hermes como dono único, porque arquivos de sessão e memória não suportam escrita concorrente

O que eu vi usando o Hermes fora da máquina local

Aqui já é relato, não documentação

No vídeo eu parto de um Hermes Agent já instalado e configurado na VPS, é conteúdo nível dois: quem ainda não montou a base precisa fazer o setup inicial antes, que eu mostrei num conteúdo anterior

O que eu quis testar foi outra coisa: gerenciar esse agente sem ficar entrando no servidor

Instalei o app de desktop no Windows e já emendo o aviso: o instalador não é assinado, então o Windows solta um alerta de segurança que tu precisa dispensar na mão

A instalação em si é next, next e finish, sem mistério

No setup do app eu escolhi a opção de conexão remota em vez da local, e recomendo a remota justamente pelo motivo do post inteiro: a VPS fica ligada o tempo todo e alcança mais serviços

A opção local existe, mas pra mim é mais pra quem só quer testar

Pra preparar o lado do servidor eu entrei pelo console do próprio painel da hospedagem, sem configurar SSH, que era o jeito convencional de mexer no agente antes de existir app nenhum

Editei o arquivo de configuração do agente pelo vim e acrescentei as variáveis de ambiente que habilitam o servidor de API, com host, porta e chave de acesso

A chave eu gerei por linha de comando com openssl e colei no lugar do placeholder, em vez de inventar uma senha na cabeça

E sim, eu defendo configurar a conexão com chave de API em vez de deixar aberta, por segurança

Depois de salvar, subi o gateway e ainda fiz restart e status, pra garantir que a configuração nova tinha pegado

Antes de tentar do PC, validei a porta no próprio servidor com um curl e confirmei o retorno de status ok

Dica de sanidade: se falhar aqui, o problema é no servidor, não no app

Aí peguei o IP do servidor no painel da hospedagem e montei a URL juntando IP e porta no app de desktop

A primeira conversa falhou, e olha que coisa boba: o modelo principal configurado no agente estava dando erro

Troquei o modelo pela própria interface e o agente respondeu normalmente

A autenticação do provedor de modelo eu fiz pelo fluxo de URL mais código exibido na tela, usando a assinatura que eu já tinha, e dá pra colar uma chave de API também

Com a conexão de pé, fiz perguntas simples no chat e o agente respondeu e ainda buscou informação na internet usando ferramentas

O ganho real veio depois: passei a acessar agendamentos, configurações e a visão dos agentes sem entrar na VPS e sem depender de um chat de mensageria

Antes, pra mudar coisa como o modelo, eu tinha que entrar na VPS e editar arquivo no terminal, porque pelo Telegram as opções eram limitadas

Sendo honesto: nem tudo está exposto via API ainda, então parte dos recursos continua indisponível pela interface

E eu sei que aula de setup costuma dar mais problema que outro tipo de conteúdo, então se tu travar em algum ponto, comenta que eu ajudo

Uma última percepção: a falta de interface gráfica era o motivo de muita gente não ter migrado da ferramenta concorrente

No vídeo acima tu vê essa configuração inteira na prática: as variáveis no arquivo da VPS, o teste de porta, a conexão do app com o servidor e o agente respondendo do outro lado

Próximo passo

O veredito é bem direto

Se tu depende de cron e de mensageria contínuos, VPS é o caminho, não tem meio termo: o scheduler roda no daemon do gateway e ele precisa estar vivo

Se o teu uso é pontual, sentar, pedir uma tarefa e fechar, a máquina local resolve e tu economiza a dor de operar servidor

Decidiu pela VPS? O caminho concreto é curto:

1. subir uma VPS pequena (1 GB dá conta sem as ferramentas de navegador)
2. instalar com a flag --skip-browser
3. registrar o serviço com sudo hermes gateway install --system
4. validar com sudo hermes gateway status --system antes de plugar as plataformas de mensagem

Validar ANTES de plugar Telegram, Discord e companhia evita aquele debug duplo, onde tu não sabe se o problema é o agente ou a integração

E se travar em algum passo, hermes doctor costuma ser o primeiro lugar pra olhar

até o próximo post! 😀