Implante um Agente IA no VPS Hetzner: Guia 2026

Por que a Hetzner sempre aparece para agentes self-hosted

Se você já passou algum tempo no canto self-hosted do dev.to, do Medium ou nos grupos indie de IA no Telegram, notou o mesmo padrão: quando alguém pergunta onde rodar um agente IA sempre ligado por menos do que dois cafés, a resposta mais votada é Hetzner Cloud. A comunidade continua chegando lá por dois motivos estáveis há anos: desempenho real de CPU por euro e um Cloud Firewall limpo que dá pra configurar antes do servidor sequer ligar.

Este passo a passo é para quem já decidiu hospedar o próprio agente IA (Hermes Agent, OpenClaw, uma configuração n8n com um nó LLM, ou qualquer coisa que chame uma API de modelo a partir de um servidor sempre ligado) e quer fazer isso na Hetzner sem pular as partes que importam às 3h da manhã. Dimensionamento, hardening, Docker Compose, um teste com Telegram e a lista honesta de coisas que vão quebrar cedo ou tarde.

Se você ainda está decidindo qual VPS barato usar, nossa comparação de VPS baratos cobre o cenário inteiro. Este post assume que você já escolheu Hetzner.

Passo 1: Escolha o plano certo

A Hetzner Cloud, em meados de 2026, divide os planos de vCPU compartilhada em três linhas:

CX (Intel) - vCPUs Intel mais antigas, sendo retiradas em algumas regiões
CPX (AMD EPYC) - o x86 padrão atual, melhor desempenho de uma thread
CAX (ARM Ampere) - a linha mais barata, ótimo desempenho por euro

Para um agente IA orientado a API (que chama OpenAI, Anthropic, OpenRouter ou seu próprio Ollama e orquestra as ferramentas localmente) o plano que você quer é o menor de qualquer uma dessas linhas:

| Plano | vCPU | RAM | NVMe | Preço UE | Notas | |---|---|---|---|---|---| | CAX11 (ARM) | 2 | 4 GB | 40 GB | ~€3,79/mês | Opção viável mais barata | | CX22 (Intel) | 2 | 4 GB | 40 GB | ~€3,79/mês | Sendo retirado em algumas regiões | | CPX11 (AMD) | 2 | 2 GB | 40 GB | ~€4,59/mês | Melhor single-thread x86 | | CPX21 (AMD) | 3 | 4 GB | 80 GB | ~€7,55/mês | Folga para segundo agente ou navegador headless |

Os preços nas regiões dos EUA são um pouco mais altos (cerca de USD 4,59 a 4,99 para o equivalente ao CX22). A Hetzner reajustou preços em 15 de junho de 2026 - novos pedidos usam a nova tarifa, servidores existentes mantêm a antiga até você redimensionar.

Recomendação: comece pelo CAX11 ou CX22. Dois vCPU e 4 GB de RAM bastam para um único agente, um gateway de Telegram, um pequeno reverse proxy e o daemon do Docker, com folga para a ocasional tarefa com navegador headless. Se você planeja rodar múltiplos agentes, scrapear páginas com Playwright ou disparar skills em lote durante a noite, suba para o CPX21.

Se o runtime do seu agente ainda não publica imagem ARM, fique no CX22 ou CPX11. A maioria dos runtimes populares (Hermes Agent, OpenClaw, n8n) já publica imagens linux/arm64, então a linha CAX costuma estar disponível.

Passo 2: Provisione e tranque o servidor antes do SSH

Esse é o passo que mais se pula e que mais morde depois. A Hetzner te dá dois firewalls (o Cloud Firewall na borda e o UFW no host). Use os dois. O Cloud Firewall vale configurar antes do servidor subir, para que ele não aceite um único pacote em uma porta que você não quer abrir.

No Console da Hetzner, crie um Cloud Firewall com estas regras de entrada:

TCP 22 somente do seu IP (ou de um CIDR pequeno se você tem uma faixa fixa de escritório)
TCP 80 de 0.0.0.0/0, ::/0 (apenas se for rodar um reverse proxy nesta caixa)
TCP 443 de 0.0.0.0/0, ::/0 (apenas se precisar de HTTPS para webhooks ou uma UI web)
ICMP de 0.0.0.0/0, ::/0 (para ping funcionar no monitoramento)

Saída: deixe o "permitir tudo" padrão - o agente precisa alcançar a API do modelo.

Agora crie o servidor, associe o firewall e escolha Ubuntu 24.04 LTS. No painel de chaves SSH, adicione a chave pública do seu notebook. Não permita login por senha.

Painel de controle escuro fotorrealista com um ícone de escudo de rede verde brilhante, representando proteção de firewall em nuvem

Assim que o servidor subir, entre via SSH como root e faça imediatamente quatro coisas:

# 1. Atualize
apt update && apt upgrade -y && apt install -y ufw fail2ban unattended-upgrades

# 2. Crie um usuário não root
adduser --disabled-password --gecos "" agent
usermod -aG sudo agent
mkdir -p /home/agent/.ssh && cp ~/.ssh/authorized_keys /home/agent/.ssh/
chown -R agent:agent /home/agent/.ssh && chmod 600 /home/agent/.ssh/authorized_keys

# 3. Tranque o SSH
sed -i 's/^#*PermitRootLogin.*/PermitRootLogin no/' /etc/ssh/sshd_config
sed -i 's/^#*PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config
systemctl restart ssh

# 4. Firewall do host (UFW), redundante com o Cloud Firewall mas uma rede de segurança útil
ufw default deny incoming && ufw default allow outgoing
ufw allow OpenSSH && ufw allow 80/tcp && ufw allow 443/tcp
ufw --force enable

Em seguida, ative atualizações de segurança automáticas e o fail2ban com padrões razoáveis:

dpkg-reconfigure -plow unattended-upgrades   # responda Yes
systemctl enable --now fail2ban

Por padrão, o fail2ban bane IPs após 5 tentativas falhas de SSH em 10 minutos. O Cloud Firewall já descarta a maioria na borda, mas o fail2ban pega o que passa (um colega, um runner de CI mal configurado, você).

Saia como root, entre novamente como agent e continue de lá.

Passo 3: Instale o Docker

Docker é a forma mais limpa de rodar um agente IA em um VPS em 2026. O agente fica isolado, as dependências não poluem o host e as atualizações são um pull && up.

# Como usuário agent, com sudo
curl -fsSL https://get.docker.com | sudo sh
sudo usermod -aG docker agent
newgrp docker
docker run --rm hello-world

Se o hello-world imprimir, o Docker está pronto.

Passo 4: Suba o agente com Docker Compose

Crie ~/agent/docker-compose.yml no servidor. O exemplo abaixo é para Hermes Agent, mas a estrutura é idêntica para OpenClaw, Open WebUI + um provedor LLM ou qualquer outro runtime de agente em contêiner.

services:
  agent:
    image: ghcr.io/your-runtime/agent:latest
    container_name: agent
    restart: unless-stopped
    env_file: .env
    volumes:
      - ./data:/data
      - ./skills:/skills
      - ./memory:/memory
    ports:
      - "127.0.0.1:8080:8080"   # UI web restrita a localhost

Depois crie ~/agent/.env:

# Provedor do modelo (BYOK - bring your own key)
OPENAI_API_KEY=sk-...
# Ou qualquer um de:
# ANTHROPIC_API_KEY=...
# OPENROUTER_API_KEY=...

# Gateway de mensageria
TELEGRAM_BOT_TOKEN=...
TELEGRAM_ALLOWED_USERS=12345678   # seu ID de usuário no Telegram

# Persistência
DATA_DIR=/data
MEMORY_DIR=/memory

chmod 600 .env para que outros usuários da caixa não consigam ler suas chaves, e suba:

docker compose up -d
docker compose logs -f agent

A política restart: unless-stopped é o que mantém o agente vivo entre reinícios. Se você prefere uma instalação nativa em vez de Docker, o equivalente é uma unit systemd com Restart=always e WantedBy=multi-user.target.

Passo 5: Conecte o Telegram e teste

Se você foi de Telegram como superfície de mensageria (a maioria de quem hospeda o próprio agente vai, porque a Bot API é grátis e instantânea), o loop de teste é curto:

Fale com @BotFather no Telegram, rode /newbot, salve o token no .env.
Fale com @userinfobot para pegar seu ID numérico do Telegram e coloque em TELEGRAM_ALLOWED_USERS.
docker compose restart agent.
Abra seu novo bot no Telegram e mande "olá".

Você deve ver resposta em poucos segundos. Se não, docker compose logs -f agent quase sempre aponta direto para o problema (token ausente, ID de usuário errado, provedor de modelo retornando 401).

Para um passeio bem mais profundo pelo lado do Telegram (grupos, tópicos, modo voz, troubleshooting), veja como construir um agente IA no Telegram.

Close-up fotorrealista de um smartphone exibindo um balão de chat em tema escuro com um acento verde

Passo 6: Backups e monitoramento (a parte que todo mundo pula)

Duas coisas baratas que se pagam na primeira vez que algo quebra:

Snapshots da Hetzner: no Console, ative um snapshot diário do servidor. Cerca de €0,012/GB/mês, uns €0,50/mês para um disco de 40 GB. Marque um como "before-update" antes de qualquer docker compose pull.
Um ping de uptime: grátis com BetterStack ou UptimeRobot. Que bata em https://seu-dominio/health (ou um check TCP) a cada 5 minutos. Na primeira vez que o gateway do Telegram cair às 3h da manhã, você fica sabendo antes do almoço, não no almoço.

Para o estado do próprio agente (arquivos de memória, skills, histórico), coloque um cron de uma linha que empacote o volume montado em /var/backups/agent-$(date +%F).tar.gz e rotacione cópias antigas. Rsync semanal para fora da caixa, para um segundo VPS barato, um bucket compatível com S3 ou seu notebook.

Passo 7: Atualizações

Uma vez por semana, com o snapshot já feito:

cd ~/agent
docker compose pull
docker compose up -d
docker image prune -f

Tudo costuma levar menos de um minuto. Se a nova imagem quebrar, restaure o snapshot pelo Console da Hetzner - a única coisa que você perde são as conversas entre o snapshot e agora, que ficam no volume de memória do agente.

O que quebra cedo ou tarde

Uma lista curta e honesta:

Quedas de long-polling do Telegram em blips longos de rede. A maioria dos runtimes reconecta sozinha, mas se o seu não, o ping de uptime é quem avisa.
docker compose pull traz uma mudança de config incompatível. Fixe a tag da imagem em uma versão específica em produção em vez de :latest.
O provedor do modelo te limita e o agente para de responder sem erro óbvio. Logue sempre o HTTP status do provedor e prefira provedores com painel de uso.
Um disco enche porque uma skill escreve em /tmp sem rotação. du -sh /* e docker system df precisam estar na sua memória muscular de debug.
Você esquece a regra do firewall ao adicionar um segundo serviço. Os dois firewalls (Cloud + UFW) precisam da nova porta, ou você perde 20 minutos depurando "connection refused" a partir do endereço certo.

Nenhum desses é específico da Hetzner. É o imposto de rodar qualquer coisa você mesmo.

Quando a conta do VPS para de fechar

Se você está lendo isto e os passos acima soam interessantes - ótimo, esse é exatamente o fluxo para o qual a Hetzner é boa. Barato, rápido, transparente.

Se eles soam como um imposto sobre um fim de semana, a comparação muda. A hospedagem gerenciada troca €4/mês e uma tarde de domingo por um setup que já inclui o gateway do Telegram, BYOK no seu provedor, volumes de memória persistente, snapshots e "simplesmente continua de pé". Nosso guia hospedagem vs self-hosting faz toda a conta, incluindo quanto vale seu tempo.

Comece com a Hermify se quiser o caminho gerenciado - um agente em infraestrutura de produção em menos de 30 minutos, sem Cloud Firewall para configurar e sem fail2ban para ajustar. Se preferir fazer você mesmo na Hetzner, este guia deve te levar até lá.