SSD Nodes Learn Hosting plans →
Guias Matt ConnorPor Matt Connor · Atualizado 2026-08-24

Como hospedar o Agent Zero com segurança em um VPS

Aprenda a hospedar o Agent Zero em um VPS e proteger sua Web UI. O Docker publica a porta 50001 em todas as interfaces por padrão, expondo shell e navegador.

O que é o Agent Zero e onde está o risco

O Agent Zero é um framework de agentes open source, orientado para Docker. Um agente principal pode iniciar agentes subordinados, cada um a executar no seu próprio contentor Docker isolado. Cada agente pode executar código, controlar um navegador e executar comandos shell. Todo o sistema é controlado a partir de uma Web UI. É uma ferramenta capaz e prática de utilizar. Também funciona em hardware tão pequeno como um VPS de seis dólares. Se pretende a arquitetura multiagente, e não necessariamente o framework, duas sessões do Claude Code no mesmo sistema podem trocar mensagens diretamente, o que é muito mais simples de executar e proteger.

O risco está na Web UI. É o painel de controlo de um sistema que executa comandos e grava ficheiros. Por isso, uma Web UI exposta e sem autenticação fornece um ponto de acesso remoto precisamente a esse sistema. Existe ainda uma armadilha em que muitos guias de configuração colocam diretamente o utilizador: o docker run padrão publica a interface na porta 50001 em todas as interfaces de rede. Num VPS público, isto significa que a interface fica acessível a partir de toda a Internet assim que o contentor arranca. Corrija isto como primeira medida, e não como último passo.

O que você precisa

Você precisa de um VPS com Docker instalado, uma chave de API para um modelo de linguagem ou um modelo local para apontar para ele e alguns gigabytes de RAM para começar. O Agent Zero é executado onde o Docker for executado, desde um VPS pequeno até um servidor com GPU. Se Docker for uma novidade para você, o guia básico do Docker explica os pressupostos dos comandos abaixo.

Instalação com Docker, associado ao loopback

O início rápido documentado consiste num único docker run. A alteração importante em relação à versão para copiar e colar que encontrará noutros locais é o endereço em que publica o serviço. Não publique em todas as interfaces na porta 50001. Publique no loopback:

docker run -d --name agent-zero \
  -p 127.0.0.1:5080:80 \
  -v a0_usr:/a0/usr \
  agent0ai/agent-zero

-p 127.0.0.1:5080:80 associa a interface Web apenas ao endereço de loopback do servidor, por isso ela não fica acessível a partir da Internet. Aceda a ela a partir da sua máquina através de um túnel SSH:

ssh -L 5080:127.0.0.1:5080 you@your-vps

Depois, abra http://127.0.0.1:5080 localmente e configure o fornecedor do modelo na interface. Para uma configuração permanente com vários utilizadores, coloque o serviço atrás de uma VPN ou de um reverse proxy com autenticação. Nunca publique a interface sem proteção na Internet aberta. Este procedimento também deve ser aplicado a qualquer outra ferramenta no servidor cuja interface controle algo sensível. É assim que também deve aceder a um scanner open-kritt autoalojado: através de um túnel para a interface, e não por uma porta publicada.

Onde os outros guias terminam, e por que não deve terminar

Procure como instalar o Agent Zero e encontrará muitos guias, incluindo os de empresas de alojamento, que levam até uma Web UI em execução na porta 50001 e terminam aí. É precisamente nesse ponto que o risco começa, não que termina. São necessárias duas medidas para concluir a configuração. Primeiro, mantenha a UI privada, como indicado acima. Segundo, coloque uma firewall com política default-deny à frente do servidor, para que um contentor iniciado por engano ou um erro futuro não exponha uma porta que se esqueceu de fechar:

sudo ufw default deny incoming
sudo ufw allow 22/tcp
sudo ufw enable

Siga as noções básicas de firewall para obter a visão completa e tenha em atenção a lacuna do IPv6, porque um serviço em :: pode ser acedido através de IPv6 mesmo quando as regras IPv4 parecem rigorosas.

O isolamento de contentores protege os agentes, não o seu servidor

O design do Agent Zero é realmente bom num tipo de isolamento: os agentes subordinados são executados em contentores separados, ficando isolados uns dos outros. Isso é útil. Mas é fácil interpretar isto como “está numa sandbox, portanto estou seguro” e parar aí. O isolamento de contentores protege os agentes uns dos outros. Não protege o seu servidor da Internet nem impede que uma Web UI exposta entregue o controlo a um desconhecido. Essa proteção é da sua responsabilidade, no host. Decida antecipadamente o que um agente pode fazer enquanto ninguém o supervisiona. É o mesmo critério usado nos modos de permissão do Claude Code, em que um servidor sem supervisão deve ter uma configuração mais restritiva do que o portátil à sua frente.

Segredos, utilizadores e o host

Mantenha a chave da API do modelo e quaisquer outras credenciais na configuração do Agent Zero ou num ficheiro de ambiente que apenas a conta correta possa ler. Mantenha-as fora do histórico da shell e de qualquer repositório. O mesmo princípio aplica-se a tudo o que proteja segredos no servidor, porque uma revisão de hardening do Vaultwarden centra-se no token de administrador e no ficheiro de backup, e não na encriptação que a aplicação já implementa bem. Administre o servidor com um utilizador sem privilégios, em vez de root, conforme descrito em utilizadores com privilégios mínimos, e configure o SSH para usar apenas autenticação por chave, como em hardening do SSH. Depois, percorra a checklist abaixo para não deixar nada por verificar.

ToolVPS hardening checklist

Se estiver a comparar agentes, esta é a mesma postura de segurança adotada pelo guia de hardening do OpenClaw e pelo guia do OpenHands: mantenha a superfície de controlo privada, execute o serviço com um utilizador sem privilégios, aplique uma firewall por predefinição e trate o host como um sistema que executa código que não foi escrito por si. Para uma comparação lado a lado dos cinco agentes, consulte os melhores agentes de IA self-hosted em 2026.

Os conceitos subjacentes a qualquer uma destas opções estão descritos em criar o seu próprio agente de IA numa VPS, e Dify é outra plataforma self-hostable que vale a pena comparar.

FAQ

O Agent Zero é seguro para alojar por conta própria?

É, desde que mantenha a sua Web UI privada e reforce a segurança do host. O Agent Zero executa código, um browser e uma shell, e é controlado a partir de uma Web UI publicada por predefinição na porta 50001. Por isso, o risco está na interface exposta, não no próprio framework. Faça o bind da UI ao loopback e aceda-lhe através de SSH ou de uma VPN, configure uma firewall com política de negar por predefinição e execute-o com um utilizador sem privilégios.

O Agent Zero expõe uma Web UI à Internet por predefinição?

A docker run padrão publica a interface na porta 50001 em todas as interfaces de rede. Num VPS público, isto significa que fica acessível a partir da Internet assim que o contentor arranca. Altere o endereço publicado para 127.0.0.1 para que a UI escute apenas no loopback. Depois, aceda-lhe através de um túnel SSH ou de uma VPN.

O Agent Zero pode ser executado num VPS pequeno?

Sim. O Agent Zero é executado onde quer que o Docker seja executado, incluindo num VPS pequeno e económico, embora as tarefas mais pesadas e os modelos locais maiores precisem de mais memória. Se o ligar a um modelo alojado por si, em vez de uma API alojada, dimensione o servidor para o modelo, e não apenas para o Agent Zero.

Qual é a diferença entre o Agent Zero, o OpenClaw e o Hermes?

Sobrepõem-se em alguns aspetos, mas têm objetivos diferentes. O Agent Zero é um framework orientado para Docker, baseado num agente principal que cria agentes subordinados em contentores isolados e é controlado a partir de uma Web UI. O OpenClaw e o Hermes são assistentes pessoais aos quais acede através de aplicações de chat. A postura de segurança é igual para todos: mantenha a superfície de controlo privada e reforce a segurança do host.