"Multica no Hetzner: Diário de instalação de Claude Agents auto-hospedados"

"## Hospedei o Multica num VPS Hetzner. Este é o diário de instalação.\n\nA notificação de fatura do Claude Managed Agents chegou à minha caixa de entrada às 23:03 de um sábado. Três sessões que tinham ficado a correr mais tempo do que pretendia durante um sprint com um cliente — uma delas estava "inativa mas tecnicamente em execução" durante um período que eu, na minha infinita sabedoria, não tinha pausado. A fatura não foi catastrófica. Foi suficiente, contudo, para me fazer parar e colocar uma pergunta que tinha estado a evitar durante duas semanas: se vou usar agentes de código como colegas de equipa, preciso mesmo da cloud da Anthropic para isso?\n\nUma nota rápida sobre o nome antes de continuar. O resumo em vídeo com que estava a trabalhar chamava a esta ferramenta Multimodal. O projeto real no GitHub, o que instalei, chama-se Multica — o repositório é multica-ai/multica, o binário da CLI é multica e o daemon é multica daemon. Para o resto deste artigo, usarei o nome verdadeiro para que os comandos neste diário sejam copiáveis em vez de meramente aspiracionais.\n\nO Multica apresenta-se como uma plataforma de agentes geridos de código aberto: uma camada que transforma agentes de codificação de terminal como Claude Code, Codex CLI e OpenCode em colegas de equipa colaborativos a quem podes atribuir issues, com quem podes conversar diretamente e para quem podes agendar trabalho recorrente. Tudo é auto-hospedável. Tudo corre em Docker. E tudo, assim que o pus a funcionar, substituiu cerca de 80 % do que pagava ao runtime gerido da Anthropic — ao custo de um VPS de 4,49 € e de uma solução alternativa de autenticação ligeiramente irritante.\n\nEste é o diário de instalação. O servidor Hetzner que escolhi, a inicialização do Docker Compose, a edição exata do ficheiro env que me permitiu ultrapassar o ecrã de login quebrado, a invocação de multica daemon, o primeiro agente que criei, o cron do Autopilot que configurei para substituir uma Claude Routine, e a comparação honesta no final. Se algo na minha máquina se comportou de forma diferente do que a documentação prometia, assinalo isso em vez de fingir que o caminho foi tranquilo.\n\n## Por que deixei de confiar na fatura do Managed Agents\n\nO Claude Managed Agents entrou em beta pública a 8 de abril de 2026. Duas semanas depois tinha quatro rotinas a executar segundo um horário, um agente a responder a webhooks e uma linha de faturação por horas de sessão que se comportava de forma muito diferente de uma cobrança típica de API. O Managed Agents fatura em duas dimensões — tarifas de token padrão mais 0,08 $ por hora de sessão de tempo de execução ativo — e a segunda é a que nos apanha. Os tokens do Sonnet 4.6 custam 3 $ de entrada / 15 $ de saída por milhão. Isso é previsível. Uma sessão que permanece em "running" enquanto um agente aguarda um git clone lento — esse é um contador que não vejo a correr.\n\nNada disto é um escândalo. A Anthropic é transparente quanto aos preços e o contador de runtime pausa quando a sessão não está a trabalhar ativamente. O problema não é a equidade. O problema é o controlo. Queria saber, até ao watt, quanto custavam os meus agentes e o que faziam. Queria poder deixar um a correr durante seis horas sem olhar para um painel de controlo. Queria apontá-lo a um repositório privado sem conceder acesso a uma cloud gerida. E queria poder trocar o modelo subjacente — Claude, GLM-4.6, seja o que for o modelo furtivo da semana do Open Code Zen — sem mudar de plano.\n\nO Multica resolve os quatro pontos. Executas a plataforma no teu próprio hardware. Instalas as CLIs de agentes de código nesse hardware. Dás ao Multica as chaves de API. Ele atribui os teus issues aos agentes. Observas o trabalho. A tua fatura é o que o modelo subjacente custa mais o VPS.\n\n## Por que o Hetzner — e qual servidor escolhi\n\nJá tentei executar este tipo de carga de trabalho em servidores mais baratos. O droplet de 4 $/mês que usei no outono passado para um daemon do Claude Code não tinha RAM suficiente para executar três contentores Docker mais um agente a lançar um espaço de trabalho Node. A stack padrão do Multica são três contentores — um backend em Go, um frontend em Next.js/TypeScript e uma instância Postgres para armazenamento de sessões — e quando uma tarefa é atribuída a um agente, o daemon cria o processo da CLI na mesma máquina. A questão do dimensionamento não é "consegue iniciar a stack?" mas "consegue iniciar a stack e também fazer o Claude Code construir uma aplicação React sem que algo seja eliminado por OOM?".\n\nEscolhi o Hetzner por duas razões. Primeiro, a relação qualidade-preço em 2026 continua absurda. Segundo, as novas máquinas de vCPU partilhada do plano CX correm em silicon ARM Ampere Altra e os irmãos maiores Intel/AMD no lado x86, pelo que podia escolher o que melhor se adequasse à minha cadeia de ferramentas. Após o ajuste de preços do Hetzner de 1 de abril de 2026, o CX22 passou de 3,29 € para 4,49 €/mês — ainda 2 vCPU, 4 GB RAM, 40 GB NVMe, 20 TB de tráfego — e o nível seguinte, CPX21 em AMD dedicado, ronda os 7,99 €/mês. Comecei no CX22 apenas para ver se a máquina mais barata realista conseguia sustentar a stack.\n\nResposta curta: sim, para um ou dois agentes de cada vez. Se planeias executar quatro sessões de Claude Code em paralelo, passa para o CPX21 ou superior. O CX22 funcionou bem para um único agente de recuperação a puxar de um repositório privado do GitHub, mas durante uma segunda tarefa simultânea começou a paginar para swap.\n\nAntes de instalar qualquer coisa, fiz o que costumo esquecer e depois me arrependo: bloqueei o SSH. Apenas chaves, login por password de root desativado, ufw a permitir apenas 22, 80, 443 e a porta que o frontend do Multica iria expor. Também instalei o Docker Engine 27.x (LTS atual em abril de 2026) usando o script de conveniência oficial, não a versão do repositório Ubuntu, porque o ficheiro compose do Multica usa sintaxe de healthcheck mais recente.\n\n## A inicialização: três contentores, um ficheiro env, um login quebrado\n\nO README do Multica dá-te dois caminhos de instalação. O primeiro é o previsto — instala a CLI localmente, aponta-a para a UI alojada na Multica Cloud e deixa-os tratar do backend. Esse é o caminho sem fricção. Também não é o caminho para que eu estava aqui.\n\nO segundo é o auto-alojamento completo. Clonas o repositório, personalizas um ficheiro env e inicias toda a stack com Docker Compose.\n\nbash\ngit clone https://github.com/multica-ai/multica.git\ncd multica\ncp .env.example .env\ndocker compose config\ndocker compose up -d\n\n\nOs três serviços: db (Postgres 16), backend (API em Go, porta 8080), frontend (Next.js, porta 3000). Os healthchecks encadeiam-nos corretamente.\n\nA primeira inicialização demorou cerca de noventa segundos. docker compose ps mostrou os três como saudáveis. Abri o frontend em http://<vps-ip>:3000 e obtive um ecrã de login.\n\nFoi aqui que bati numa parede. O fluxo de autenticação padrão do Multica envia um "código recente" através do serviço cloud. Quando estás completamente auto-alojado, esse código nunca chega. Ficas a olhar para um campo de entrada de seis dígitos que nunca se resolverá.\n\nA solução alternativa: abre .env e define dois valores:\n\nbash\nAPP_ENV=development\nRECENT_API_KEY=\n\n\nAPP_ENV=development diz ao backend para ignorar a verificação do código cloud e aceitar qualquer código de seis dígitos. Deixar RECENT_API_KEY em branco remove a credencial cloud. Juntos, colocam-te num modo de login de desenvolvimento em que o primeiro e-mail cria uma conta e qualquer código de seis dígitos funciona.\n\nApós guardar: docker compose down && docker compose up -d. Escrevi 123456 e entrei.\n\nVale a pena dizer explicitamente: APP_ENV=development não é um modo de autenticação para produção. Está bem quando o VPS está numa rede VPN Tailscale sem tráfego público a chegar à porta 3000. Não está bem quando o frontend está exposto à Internet aberta.\n\n## Registar o daemon e os runtimes\n\nCom a UI em funcionamento, o passo seguinte é ligar a camada de trabalho real. A UI é onde defines agentes e issues; um processo daemon separado recolhe o trabalho e executa as CLIs dos agentes de codificação.\n\nbash\ncd /opt/multica\nsudo cp ./bin/multica /usr/local/bin/\nmultica --version\nmultica auth login --server http://localhost:8080 --token <API_TOKEN>\nmultica daemon\n\n\nNo primeiro arranque, o daemon deteta automaticamente quais as CLIs de agentes instaladas. Suportadas: claude, codex, openclaw, opencode, hermes, gemini, pi, cursor-agent. Instalei o Claude Code e o OpenCode. Ambos apareceram como "connected" em cinco segundos.\n\nO modelo de token de API permite-te executar o daemon em várias máquinas contra uma única UI — uma frota de agentes multi-máquina real sem tocar na cloud de ninguém.\n\nEnvolvi o daemon numa unidade systemd:\n\nini\n[Unit]\nDescription=Multica agent daemon\nAfter=docker.service\nRequires=docker.service\n\n[Service]\nType=simple\nUser=mejba\nWorkingDirectory=/home/mejba\nExecStart=/usr/local/bin/multica daemon\nRestart=always\nRestartSec=5\n\n[Install]\nWantedBy=multi-user.target\n\n\nbash\nsudo systemctl daemon-reload\nsudo systemctl enable --now multica-daemon\n\n\n## O meu primeiro agente: um bot de recuperação para as minhas próprias notas\n\nConstruí um NotesBot — um agente com acesso ao meu repositório privado de notas do Obsidian que responde a perguntas sem que eu tenha de vasculhar ficheiros Markdown.\n\nCriar um agente requer dois campos: um nome e um system prompt.\n\n\nYou are NotesBot, a focused retrieval agent working against a cloned\ncopy of my private notes repository located at /workspaces/notes.\n\nWhen I assign you an issue, treat the issue body as a question. Your\njob is to:\n\n1. Grep the repo for the most relevant notes (use ripgrep, not find).\n2. Read the top 3-5 candidate files in full before answering.\n3. Respond with: a direct answer, the filenames you used as sources\n (as relative paths from the repo root), and a \"confidence\" line\n that is one of: high / medium / low.\n4. If you can't find anything relevant, say so explicitly and suggest\n three adjacent queries I might try instead.\n\nNever modify files. Never create new notes. You are read-only.\nUse opencode with the zen big-pickle model unless told otherwise.\n\n\nPara o NotesBot, apontei-o para o OpenCode com GLM-4.6 (contexto de 200K, gratuito durante a janela atual), utilizando o identificador de modelo zen/big-pickle. O daemon resolve isto em algo como:\n\nbash\nopencode run --model zen/big-pickle --non-interactive \\\n --workspace /workspaces/notes-<task-id> \\\n --prompt-file /tmp/multica-<task-id>-prompt.txt\n\n\nO Multica não é um novo runtime — é um orquestrador que delega em runtimes que já conheces.\n\nO meu primeiro issue: "Quais das minhas notas abordam a distinção entre 'open loops' e 'pattern interrupts' na estrutura de artigos?" O agente pegou nele em quatro segundos, e vinte e dois segundos depois o NotesBot publicou a sua resposta com três nomes de ficheiro de origem e uma marca de confiança "high".\n\n## Configurar o Autopilot: o equivalente open-source das Claude Routines\n\nAs Claude Routines (lançadas a 9 de abril de 2026) executam prompts agendados na infraestrutura da Anthropic — de hora a hora, diariamente, em dias úteis, semanalmente ou em eventos de webhook/GitHub. Limitadas a 5/15/25 execuções por dia para Pro/Max/Team.\n\nA resposta do Multica é o Autopilot — um agendador de tarefas recorrentes ligado ao sistema de issues.\n\nA minha configuração:\n- Agente: NotesBot\n- Prompt: Scan notes modified in the last 24 hours. List any tool or product name mentioned for the first time in my notes history. For each, give a one-line context of where it appeared.\n- Cadência: 0 9 * * * (diariamente às 9h)\n- Fuso horário: Europe/London\n\nSendo honesto sobre o que o Autopilot não tem: apenas acionadores agendados. Sem acionador de webhook de API, sem acionador de evento GitHub. E os agentes movem as tarefas para In Review mas não para Done — o humano tem de finalizar.\n\n## Comparação honesta: Multica auto-hospedado vs Claude Managed Agents\n\nCusto: O auto-alojamento vence de forma decisiva. VPS de 4,49 €/mês, sem contador de 0,08 $/hora de sessão. Com o meu uso, o VPS paga-se na primeira semana.\n\nControlo: O auto-alojamento vence. Posso pausar o daemon, inspecionar a tabela de sessões do Postgres, ler os logs do daemon linha a linha e intervir em tarefas bloqueadas. Sem acesso de terceiros a repositórios privados.\n\nSuperfície de acionadores: Claude Managed Agents vence. As Routines suportam agendamento + webhook + acionadores GitHub. O Autopilot do Multica suporta apenas agendamento.\n\nPolimento de UX: A interface do Claude está mais polida. O Multica parece estar numa fase mais inicial.\n\nMulti-agente / multi-máquina: O auto-alojamento vence por design. Aponta vários daemons de VPS para uma única UI do Multica.\n\nFiabilidade: O runtime do Claude é o runtime da Anthropic — um uptime que não consigo igualar num CX22.\n\nOnde usaria cada um: Claude Managed Agents para fluxos de trabalho de eventos GitHub. Multica auto-hospedado para custo, controlo e cenários com dados privados.\n\n## Segurança: a única coisa que tens de fazer bem\n\nAPP_ENV=development na Internet aberta aceita qualquer código de seis dígitos. Isso é pior do que não ter autenticação.\n\nCaminho um: VPN mesh Tailscale. Instala o Tailscale (curl -fsSL https://tailscale.com/install.sh | sh), configura o ufw para que as portas 3000/8080/SSH só sejam acessíveis através de tailscale0. O frontend em http://100.x.y.z:3000 só é acessível a partir dos teus próprios dispositivos.\n\nCaminho dois: completamente local. Executa toda a stack num portátil ou servidor doméstico que nunca toque a Internet pública.\n\nSeja qual for o caminho que escolhas: mantém as imagens Docker atualizadas, mantém o kernel do host com as últimas correções e trata APP_ENV=development como exclusivo de rede privada.\n\n## O que construiria a seguir\n\n(1) Ligar o CI à API de criação de issues do Multica para que as compilações falhadas gerem issues de depuração automaticamente. (2) Executar um segundo daemon VPS dedicado a um agente "revisor" com um modelo diferente para revisões de segunda opinião sobre PRs de agentes.\n\nA fatura do Claude Managed Agents desceu 60 % desde que movi o trabalho de recuperação e de prompts agendados para o Multica. O contador de horas de sessão é uma rubrica muito menor.\n\nSe tens estado a fazer a mesma pergunta que fiz naquela noite de sábado — preciso mesmo desta cloud para fazer este trabalho? — a resposta, para pelo menos 80 % do trabalho, é não. Precisas de um VPS, Docker, Tailscale e cerca de duas horas.\n\nO terminal está à espera.\n\n## Vamos trabalhar juntos\n\nQueres construir sistemas de IA, automatizar fluxos de trabalho ou escalar a tua infraestrutura tecnológica? Adoraria ajudar.\n\n* Fiverr (soluções personalizadas e integrações): fiverr.com/s/EgxYmWD\n* Portfolio: mejba.me\n* Ramlit Limited (soluções empresariais): ramlit.com\n* ColorPark (design e branding): colorpark.io\n* xCyberSecurity (serviços de segurança): xcybersecurity.io"