Como separar perfis do Hermes Agent na VPS (trabalho e pessoal) sem misturar memória e credenciais

Fala aí, beleza? Se você quer rodar o Hermes Agent na VPS para trabalho e para uso pessoal sem que um lado enxergue a memória ou as chaves do outro, a solução são os perfis 🙂

Cada perfil é uma home Hermes separada em ~/.hermes/profiles/<nome>/, com config.yaml, .env, SOUL.md, memórias, sessões, skills, cron jobs, banco de estado e logs próprios

O caminho é criar perfis vazios com hermes profile create (sem --clone), configurar chave de API e token de bot em cada um, e decidir o gateway: por padrão um único gateway multiplexado atende todos os perfis que tiverem token próprio, mas dá pra forçar um gateway dedicado por perfil quando precisar

Mas se liga desde já: perfil organiza dados, ele NÃO é fronteira de segurança do sistema operacional

Se você ainda está entendendo como o Hermes Agent funciona, vale passar por lá antes 🙂

O que você precisa antes de criar os perfis?

Você precisa do Hermes Agent já instalado e funcionando na VPS

Ponto de partida: VPS com template Hermes na Hostinger

Se você ainda não tem servidor, a VPS com o template Hermes da Hostinger encaixa bem nesse cenário (é link de afiliado da Hostinger)

O motivo técnico: o template Hermes Agent pode ser escolhido já na contratação da VPS, ou, numa VPS que você já tem, pelo caminho VPS > OS & Panel > Operating System > Change OS (buscando por Hermes Agent); depois o projeto aparece em Docker Manager > Projects, como mostra o tutorial da própria Hostinger

E aqui vai um ponto importante: é uma VPS autogerenciada com Docker e acesso root

A Hostinger fornece o ambiente Docker, mas a administração do servidor (perfis, serviços, atualizações) fica com você

Isso NÃO é o mesmo produto do Managed Hermes Agent, que é uma oferta gerenciada separada

Checklist antes de começar:

• Hermes Agent instalado e respondendo na VPS
• Uma chave de API ou provedor para cada perfil (OpenRouter, OpenAI, Anthropic ou um endpoint de LLM próprio)
• Um token de bot DIFERENTE para cada perfil que for responder por um bot (Telegram, Discord ou Slack)

Tome cuidado se você usa a imagem Docker

Na imagem Docker oficial, o HERMES_HOME fica em /opt/data, montado do host, que a documentação chama de fonte única de todo o estado do Hermes: .env, config.yaml, SOUL.md, sessions, memories, skills, cron, logs e state.db

Ou seja, os caminhos com ~/.hermes deste post podem não bater com o que você tem aí dentro

Confira onde os perfis estão sendo gravados antes de seguir: o hermes profile show (que aparece na checagem lá embaixo) exibe o diretório home de cada perfil

E se liga em outro detalhe: a instalação do gateway como serviço no Passo 5 (systemd de usuário ou sudo hermes gateway install --system) pressupõe o Hermes rodando direto no sistema da VPS, fora de container, com systemd e sudo disponíveis

Dentro da imagem Docker oficial, o gateway run é supervisionado pelo s6-overlay: perfis nomeados comuns se ligam ao gateway raiz (o mesmo comportamento multiplexado padrão), e só perfis com gateway.standalone: true no próprio config.yaml usam um slot de processo próprio

Confira na documentação Docker como esse encaixe funciona no seu caso antes de forçar instalação de serviço por perfil

Passo a passo: perfis de trabalho e pessoal com memória e credenciais separadas

Bora ver na prática? Vou usar os nomes trabalho e pessoal, troque pelos que fizerem sentido pra você

1. Crie os perfis vazios (sem clonar nada):

hermes profile create trabalho
hermes profile create pessoal

Resultado esperado: dois diretórios novos em ~/.hermes/profiles/, cada um já com as skills empacotadas, e dois comandos novos no shell, trabalho e pessoal

Cada perfil vira um comando próprio com todos os subcomandos do Hermes (trabalho chat, trabalho setup, trabalho gateway start e por aí vai)

Erro comum deste passo: usar --clone ou --clone-all

O --clone copia do perfil atual o config.yaml, o .env, o SOUL.md, as skills e a memória curada (memories/MEMORY.md e memories/USER.md)

Já o --clone-all copia tudo: config, chaves de API, personalidade, todas as memórias, skills e plugins. Ficam de fora o histórico de sessões, o state.db, backups/, state-snapshots/ e checkpoints/: e também os cron jobs, o perfil novo começa com cron/ vazio mesmo nesse modo

Ou seja, com qualquer um dos dois a memória e as chaves de API de provedor já nascem misturadas entre trabalho e pessoal, que é exatamente o que você quer evitar. Vale uma ressalva: nenhum clone copia os canais de mensagem (tokens de bot, allowlists) por padrão, eles só entram se você pedir explicitamente com --clone-channels. Então o token do bot de cada perfil continua precisando ser configurado à parte no Passo 2, mesmo clonando

2. Configure cada perfil com a própria chave e o próprio token:

trabalho setup
pessoal setup

O setup pede chaves de API, modelo e tokens do gateway: as chaves de API e os tokens (dados sensíveis) vão para o .env daquele perfil, enquanto o modelo escolhido fica guardado no config.yaml do mesmo perfil

Resultado esperado: ~/.hermes/profiles/trabalho/.env e ~/.hermes/profiles/pessoal/.env com credenciais diferentes

Erro comum deste passo: colar a mesma chave de API nos dois perfis quando a ideia era separar a cobrança

Funciona, mas aí o gasto de trabalho e o pessoal caem na mesma conta do provedor e a separação vai embora

E se o comando trabalho não for encontrado? O alias é um script wrapper em ~/.local/bin/<nome>, e dá pra recriar com:

hermes profile alias trabalho

Outra saída é usar a flag -p, que tu vê no próximo passo: hermes -p trabalho setup

3. Escolha qual perfil está em uso:

hermes profile use trabalho

Isso define o perfil ativo fixo (sticky default): todo hermes sem -p passa a rodar nele

Pra rodar algo pontual em outro perfil sem mexer nesse padrão, use a flag global -p:

hermes -p pessoal chat

Erro comum deste passo: esquecer qual perfil ficou fixo e rodar hermes achando que está no outro

Já vi muita gente salvar coisa de trabalho no lado pessoal por causa disso haha

Na dúvida, chame o perfil pelo alias (trabalho chat, pessoal chat) e acabou o problema

4. Entenda o gateway padrão: multiplexado por perfil de token

Hoje o Hermes liga o multiplexing por padrão (gateway.multiplex_profiles: true)

Um único gateway, o do perfil padrão, atende as mensagens de todos os perfis, desde que a verificação prévia passe: dois ou mais perfis existem, nenhum perfil secundário já roda gateway próprio, nenhum token de bot está duplicado entre perfis, e nenhuma plataforma que faz binding de porta está sem o ingress /p/<profile>/ configurado

Na prática: se trabalho e pessoal tiverem tokens de bot diferentes no próprio .env, o gateway do perfil padrão já responde por ambos, sem precisar instalar nada a mais

Cada turno de conversa usa a config, as skills, a memória, o SOUL e as chaves de provedor do perfil para o qual a mensagem foi roteada: as credenciais nunca são compartilhadas entre perfis, mesmo com um gateway só

Se precisar pausar só um dos perfis sem desligar o gateway host nem afetar o outro, hermes -p <nome> gateway stop estaciona (park) aquele perfil dentro do multiplexador, e gateway start reativa

Pra conferir ou fixar esse comportamento no perfil padrão:

hermes config set gateway.multiplex_profiles true
hermes gateway restart

Erro comum deste passo: usar o mesmo token de bot nos dois perfis

Dois adaptadores com o mesmo token disputam o long-poll, e no gateway multiplexado o adaptador duplicado fica estacionado

A regra é simples: um bot pertence a um único perfil

5. Alternativa: gateway próprio por perfil (standalone)

Se você quer separação de processo de fato: por exemplo, tirar o perfil pessoal do ar sem afetar o de trabalho no nível de sistema: dá pra forçar um gateway dedicado por perfil

Rodar gateway install ou gateway start num perfil nomeado é recusado por padrão, por causa da checagem de multiplexing, a menos que você use --force ou defina gateway.standalone: true no config.yaml daquele perfil:

trabalho gateway install --force
trabalho gateway start --force
pessoal gateway install --force
pessoal gateway start --force

Resultado esperado: cada perfil ganha a própria entrada de supervisor: um serviço systemd de usuário chamado hermes-gateway-trabalho.service e hermes-gateway-pessoal.service (ou, com sudo hermes gateway install --system, um serviço de sistema que roda como o usuário que chamou o comando, via User=), conforme o guia de gateways com vários perfis

Pra tirar o gateway standalone do pessoal do ar e religar depois, sem afetar o de trabalho:

hermes -p pessoal gateway stop
hermes -p pessoal gateway start

Atenção: aqui o pessoal já tem gateway próprio (standalone), então esse stop/start para e reinicia só o processo daquele serviço específico. Não confunda com o "estacionar" (park) do Passo 4: aquele é exclusivo do perfil que está sendo servido pelo gateway multiplexado (host); no standalone não existe esse marcador, o comando liga e desliga o processo mesmo

Erro comum deste passo: esquecer o --force (ou o gateway.standalone: true) e achar que o comando travou: ele só está respeitando a checagem de multiplexing

6. Defina o diretório de trabalho de cada perfil

Aqui mora uma pegadinha

O diretório onde os comandos de terminal começam é definido por terminal.cwd (ou pelo diretório de lançamento quando o cwd é "." no backend local), e NÃO segue o HERMES_HOME automaticamente

Então ajuste terminal.cwd no config.yaml de cada perfil, apontando o de trabalho pra pasta dos projetos de trabalho e o pessoal pra pasta pessoal

Erro comum deste passo: achar que trocar de perfil troca a pasta em que o agente executa comandos

Não troca, quem manda nisso é o terminal.cwd

Como conferir que cada perfil está isolado e o gateway certo está rodando?

Com estes comandos tu confere tudo

Listar os perfis (o ativo aparece marcado com *):

hermes profile list

Ver os detalhes de um perfil: diretório home, modelo configurado, status do gateway, número de skills e status dos arquivos de configuração:

hermes profile show trabalho
hermes profile show pessoal

Atenção: hermes profile sem subcomando NÃO mostra nome, caminho, modelo e status do perfil atual: ele mostra só a ajuda, com a lista de subcomandos disponíveis. Pra saber qual perfil está ativo, use o profile list acima (o * indica)

E rodar a verificação de cada perfil com o comando global hermes doctor, apontando o perfil pela flag -p:

hermes -p trabalho doctor
hermes -p pessoal doctor

Resultado esperado: cada perfil com home própria em ~/.hermes/profiles/<nome>/ (ou o caminho equivalente no seu container), o modelo certo e o gateway ativo

Erro comum na checagem: dois processos do agente apontando para o mesmo perfil, ou seja, a mesma home

Os dois gravam memória automaticamente e cada um passa a carregar o que o outro gravou, como alerta a documentação de perfis do Hermes

Regra de ouro: um processo do agente por perfil

Manutenção dos perfis:

• hermes profile rename <atual> <novo> renomeia e já atualiza o diretório e o alias (se havia um serviço de gateway instalado com o nome antigo, ele é removido, sendo preciso reinstalar com hermes -p <novo> gateway install)
• hermes profile delete <nome> apaga o perfil e remove o alias (com --yes ou -y pula a confirmação)
• hermes profile alias <nome> --remove remove o wrapper em ~/.local/bin, e --name <alias> cria o atalho com outro nome

Tome cuidado com o delete -y: ele apaga o perfil inteiro, com memória e .env juntos

Perfil separa dados, não protege o sistema: quando usar usuário ou container?

Perfil é organização lógica, não isolamento

Perfis não colocam o agente em sandbox nem restringem o acesso ao sistema de arquivos no backend local

E o SOUL.md? Ele orienta o modelo, mas não impõe limite de workspace nenhum

É tipo deixar um bilhete na geladeira dizendo "não mexa": funciona com quem respeita, mas a porta continua aberta xD

Cenário 1: trabalho e pessoal do mesmo dono, na mesma VPS

Aqui os perfis bastam

Você separa memória, chaves de API, bots e cobrança, e nenhum perfil carrega a memória do outro

Como os dois lados são seus, ninguém está tentando ler o que não deve

Cenário 2: um perfil NÃO pode ler os arquivos do outro

Pensa em dados de cliente, de empresa ou qualquer coisa sensível

Nesse caso perfil sozinho não resolve: como já vimos, no backend local o agente herda o mesmo acesso a arquivos da sua conta de usuário no sistema operacional, e perfil nenhum muda isso

Pra um limite que o sistema garanta de fato, a saída passa por fora do conceito de perfil:

• Um usuário do sistema operacional por contexto, cada um com a própria instalação do Hermes
• Containers Docker distintos para cada contexto

Perfil continua útil dentro de cada um desses ambientes, só não é ele quem segura a porta

Quanto custa: servidor e provedor de IA são contas diferentes

São duas contas separadas, e misturar as duas é o erro mais comum na hora de planejar

A assinatura da VPS cobre o servidor

O uso do modelo é cobrado pelo provedor que você configurou em cada perfil: o Hermes funciona com OpenRouter, OpenAI, Anthropic e endpoints de LLM personalizados, conforme a página do Hermes Agent na Hostinger

E aqui os perfis ajudam MUITO: com uma chave própria em cada perfil, você acompanha o gasto de trabalho e o pessoal separados, direto no painel de cada provedor

Dá até pra usar provedores diferentes, um modelo mais caro no trabalho e outro mais barato no pessoal

E os créditos de IA da Hostinger?

Os créditos de IA da Hostinger migraram do nexos.ai para o Hostinger AI Router, segundo o aviso oficial de migração

O saldo foi mantido, a base URL passou de https://api.nexos.ai/v1 para https://router.hostinger.com/v1 e a chave agora é uma chave Hostinger que começa com sk-hstgr-, com o saldo convertido na proporção de 1 crédito para 100, sem mudança de valor

A migração é escalonada: quem ainda tem saldo e usa a chave com frequência continua na chave atual até o saldo acabar; contas pouco usadas são migradas automaticamente e a chave antiga para de funcionar depois disso

Se você usa esses créditos num app do Docker Catalog, a troca é pelo painel: Docker Manager > Manage > Environment, atualizando a base URL e a chave, e depois Deploy

Em apps gerenciados (como o Hermes Agent gerenciado da Hostinger) não é preciso fazer nada: a própria Hostinger cuida da troca: e instalações novas já saem apontando direto para o AI Router

Só não conte com crédito de IA incluso como garantido: a contratação da VPS com Hermes na Hostinger cobre o servidor, e o consumo do modelo é planejado à parte

Quer ver o Hermes com interface gráfica?

Aqui no canal tem um vídeo sobre o Hermes Desktop, o app que dá interface gráfica ao Hermes Agent

É um complemento massa pra quem administra o Hermes num servidor e quer sair um pouco do terminal 😀

Próximo passo

Cria o segundo perfil vazio agora, roda o setup dele com uma chave e um token só dele e confere com hermes profile show <nome>

Se aparecer a home própria, o modelo certo e o gateway ativo, tá feito

Se a separação precisar ser de segurança (cliente, empresa, dado sensível), o próximo passo é avaliar um usuário separado no sistema ou um container, não mais um perfil

E se você ainda vai dimensionar a VPS, o guia de requisitos do Hermes aqui do blog ajuda nessa conta

Já se a máquina começar a apertar com vários gateways rodando, vale investigar a memória antes de aumentar o plano, a lógica de diagnóstico é a mesma

Até o próximo post!

Quer aprender mais sobre inteligência artificial e programação na prática? Conheça o canal Hora de Codar no YouTube e acompanhe os próximos vídeos.