🇧🇷 Como montei meu homelab Proxmox conversando com o Claude

Uma semana, um servidor esquecido num canto e nenhuma linha de configuração digitada à mão.

---

Eu tinha um mini PC rodando Proxmox VE. Na prática, ele era um daqueles projetos que a gente começa empolgado e larga pela metade: instalado numa rede antiga, com um NVMe de 4 TB cheio de volumes de experimentos que eu nem lembrava mais, um HD USB de 1,4 TB guardando uma VM de Bitcoin abandonada e uma VM do Windows que eu usava de vez em quando, sem saber direito como estava configurada.

A ideia desta vez foi diferente. Em vez de passar fins de semana lendo fóruns, montando discos e editando arquivos de configuração, resolvi fazer tudo conversando com o Claude Code. Eu descrevia o que queria em português, e ele fazia o resto por SSH: inspecionava, planejava, executava, testava e documentava.

Este post conta como foi.

---

Capítulo 1: primeiro, entender a casa

A primeira coisa que o Claude fez não foi mudar nada. Foi olhar. Entrou no servidor por SSH e fez um inventário completo: hardware, versão do Proxmox, discos, rede, VMs e containers. E guardou tudo num lugar que virou a espinha dorsal do projeto: um bundle de conhecimento em markdown no formato OKF (Open Knowledge Format), com um arquivo por assunto, versionado junto com o resto. Para gerenciar esses documentos usamos a OKF gem, uma gem que ajuda a criar, validar e manter documentos OKF. Recomendo o uso para quem quer uma documentação que humanos e agentes de IA leiam da mesma fonte.

Logo de cara ele achou seis problemas que eu nem sabia que tinha:

• O servidor não resolvia nomes. O DNS ainda apontava para o roteador da rede antiga (10.0.0.1), e por isso o apt update travava.
• O /etc/hosts dizia que o servidor tinha um IP que não existia mais.
• O container do Pi-hole tinha um gateway fora da sub-rede.
• Os repositórios enterprise do Proxmox estavam ativos sem assinatura.
• E ~3,6 TB de disco estavam fora do Proxmox, em volumes órfãos.

Em uma tarde, o DNS e o /etc/hosts foram corrigidos, os repositórios trocados pelos gratuitos e o sistema atualizado (182 pacotes e um reboot). Cada correção foi conferida e registrada no bundle, com um log datado.

O que me chamou atenção: o Claude não "chuta". Antes de apagar o NVMe, ele me mostrou o que havia dentro de cada volume (containers antigos de Docker e Transmission, uma VM Umbrel inteira) e esperou eu dizer que podia descartar.

Capítulo 2: os discos

Com a minha autorização, o NVMe Kingston de 4 TB foi apagado e virou um storage lvmthin de 3,57 TB chamado vmdata. Todas as VMs e containers foram migrados para ele.

A VM do Windows deu trabalho. Depois da migração, o disco dela ficou 100% alocado, porque não tinha discard habilitado. O Claude ativou o recurso e tentou o caminho normal (o retrim do Windows), que não funcionou com aquela versão do driver VirtIO. Em vez de desistir, ele fez uma cópia offline de ida e volta pelo outro storage, e o disco caiu de 100% para 28,65% de ocupação.

Eu só acompanhei.

Capítulo 3: uma VM Ubuntu que eu pudesse usar de verdade

Eu tinha criado uma VM com Ubuntu 26.04 e pedi duas coisas: IP fixo e acesso remoto pela área de trabalho.

O IP fixo parecia trivial. O Claude configurou o NetworkManager e, ao testar, percebeu que a VM tinha ficado com dois IPs: o arquivo do instalador mantinha o DHCP ligado por baixo. Corrigido, a VM passou a responder só no 192.168.0.103. Escolhi o final 103 porque é o ID dela no Proxmox, e assim fica fácil lembrar.

O RDP foi uma pequena saga:

1. O Claude ativou o Login Remoto do GNOME. Do meu Mac, o Windows App da Microsoft ficava travado em "Securing connection".
2. Lendo os logs do servidor, ele descobriu que a autenticação funcionava, mas, no redirecionamento para a sessão, o cliente da Microsoft no Mac reenviava as credenciais erradas. É um bug conhecido.
3. Trocamos para o FreeRDP, que também falhou, desta vez antes de sair do Mac. O macOS bloqueia binários fora da Apple de acessar a rede local, e eles nem aparecem na lista de permissões.
4. A solução foi um túnel SSH: o FreeRDP conecta em localhost, e o túnel leva até a VM.
5. Para não depender de comando, o Claude criou um script rdp-ubuntu (abre o túnel, busca a senha no Chaveiro do macOS, conecta e fecha tudo ao sair) e depois um app com ícone na pasta Aplicativos.

Hoje eu clico num ícone e estou no Ubuntu.

Capítulo 4: o HD USB vira servidor de torrents

Pedi que o HD USB de 1,4 TB fosse usado só para downloads de torrent, com interface web. A primeira coisa que o Claude notou: o HD estava numa porta USB 2.0. Troquei de porta, ele mediu a leitura (117 MB/s no início do disco) e seguimos.

Aqui apareceu algo que eu não teria planejado sozinho: o HD pode ser desplugado. Então o desenho inteiro foi pensado para isso:

• O HD é repassado para a VM como dispositivo USB, e não como disco. Assim a VM liga mesmo sem ele.
• O qBittorrent só roda com o HD montado. Se o HD sai, ele para sozinho, e nada é gravado no disco do sistema.
• Um comando ejetar-torrents para tudo com segurança antes de tirar o cabo.
• Ao replugar, o HD monta e o qBittorrent volta sozinho.

Testamos tudo: download real com checksum conferido, desplugue simulado, replugue e boot com e sem o HD.

Capítulo 5: acessar os arquivos de qualquer jeito

Eu queria enviar, baixar e apagar arquivos pela web e também ver as pastas direto no Finder.

Pela web, o plano era o File Browser. O Claude instalou e, ao subir o serviço, leu o aviso que o próprio programa imprimia: o projeto tinha sido arquivado um mês antes, com falhas de segurança sem correção. Uma delas apagava pastas quando um upload falhava. Ele parou, me explicou o risco e me deu três alternativas ativas. Escolhi o copyparty, que foi validado com um upload e um download de 6 GB, checksum conferido, retomada no meio e tudo.

No Finder, entrou o Samba. O servidor aparece sozinho na barra lateral do Mac. E aí veio o momento mais tenso da semana: no meio do teste de cópia de 6 GB, o servidor inteiro sumiu da rede. Tive que desligar e ligar no botão.

Quando ele voltou, o Claude leu os logs e achou a causa em minutos: a placa de rede Intel I219 do mini PC tinha travado (Detected Hardware Unit Hang), um bug conhecido desse chip sob tráfego pesado. A correção foi desligar duas otimizações da placa (TSO/GSO). Para garantir, ele criou um vigia que reseta a placa sozinho se ela travar de novo. O mesmo teste de 6 GB passou depois sem nenhum travamento.

No mesmo dia ele achou mais um problema sutil: o ejetar-torrents às vezes remontava o HD sozinho logo depois de desmontar. A causa era uma interação do systemd com o fstab, disparada por um timer que roda a cada 10 minutos. Uma opção (noauto) resolveu de vez.

Capítulo 6: um painel para ver tudo

Para fechar a parte do servidor, pedi um dashboard. O Claude instalou o Glance em http://192.168.0.103, sem porta:

• ícones e status de cada serviço;
• ocupação dos discos, CPU e RAM da VM;
• velocidade dos torrents;
• um resumo do host Proxmox, com CPU, RAM e estado de cada VM, lido por um token só de leitura. Ele testou que o token não consegue desligar nada.

No teste com o HD ejetado, o painel mostrou "13 GB de 128 GB" no lugar do HD. Estava lendo a pasta vazia no disco do sistema. O Claude não aceitou o número errado: criou um pequeno coletor que informa o estado real, e agora o painel mostra "● HD desconectado" quando é o caso.

O método por trás da mágica

Olhando para trás, o que fez isso funcionar não foi o Claude "saber Linux". Foi o jeito de trabalhar:

• Planejar antes de executar. Toda tarefa maior começava com um plano gravado em plan/aaaa-mm-dd.md, com decisões, motivos e caixinhas de cada fase. Eu aprovava e acompanhava o andamento ali.
• Testar tudo, de verdade. Nada era dado como pronto sem teste: checksums de arquivos de 6 GB, desplugues simulados, reinícios com e sem o HD.
• Documentar como código. O bundle de conhecimento (configuration/), no formato OKF, é atualizado a cada mudança e validado automaticamente com a OKF gem, que confere a estrutura dos documentos e aponta links quebrados e índices desatualizados. Qualquer sessão futura começa sabendo o que já foi feito.
• Perguntar antes do irreversível. Apagar um disco, formatar o HD, remover arquivos: sempre com a lista exata do que seria afetado e a minha confirmação. Quando um pedido meu era ambíguo e casava com mais de uma coisa, ele perguntava qual antes de apagar.
• Segredos fora da conversa. Senhas geradas e guardadas no Chaveiro do Mac, passadas aos serviços sem aparecer na tela.

O que deu errado (e por que isso me deu mais confiança)

Não foi tudo perfeito, e eu acho que essa é a parte mais importante deste post:

• A queda do servidor foi provocada por um teste do próprio Claude. A diferença é que ele diagnosticou, corrigiu e blindou o problema em seguida.
• Ele errou datas na documentação uma vez e corrigiu ao perceber.
• Uma conclusão apressada: a primeira vez que o HD remontou sozinho logo depois de ejetar, o Claude atribuiu o caso a um efeito colateral do teste anterior, porque não conseguiu reproduzir. Quando aconteceu de novo, ele mesmo voltou ao assunto, admitiu que a explicação estava errada, cruzou os horários com os logs e achou a causa real (o timer de 10 minutos e o fstab). O primeiro método dele para simular o desplugue do HD também não funcionava, e ele percebeu e trocou por um que funcionava.
• No começo eu colei uma senha na conversa. O Claude usou, mas recomendou trocá-la. Troquei, e desde então tudo passa pelo Chaveiro.

Um assistente que nunca erra eu não teria como avaliar. Um que encontra os próprios erros, explica e documenta como evitar é um que eu deixo mexer no meu servidor.

Em números

• 1 servidor saneado: DNS, repositórios, atualização e 4 TB de NVMe recuperados.
• 6 serviços novos na VM Ubuntu (RDP, qBittorrent, copyparty, Samba, Glance e o coletor de status do painel), mais o vigia da placa de rede no host.
• 3 problemas de hardware e software que eu não conhecia: a porta USB 2.0, a placa de rede que travava e a remontagem fantasma do HD.
• 1 bundle de documentação, 4 planos de execução e zero arquivos de configuração editados por mim.

Conclusão

Eu não deixei de entender o meu servidor. Pelo contrário: hoje ele está mais bem documentado do que qualquer coisa que eu já montei sozinho. A diferença é que eu passei a semana decidindo o que queria, e não brigando com como fazer.

Se você tem um homelab parado por falta de tempo, a minha dica é: abra um terminal, conecte o Claude ao seu servidor e comece pedindo para ele olhar e documentar antes de mudar qualquer coisa. O resto vem conversando.