Perdi tudo no homelab e a IA me ajudou a reconstruir

Perdi o SSD e o HD de backup juntos, sem git. A IA me ajudou a reconstruir as aplicações. Hoje uso o Claude Code no homelab com regras bem claras.

Publicado
Leitura
5 min
HD aberto depois de um head crash, com um anel riscado na superfície do prato
Um HD depois de um head crash. Foto: Mschau, CC BY-SA 3.0 (original).

Um dia eu perdi, de uma vez, o SSD do servidor e o HD de backup. Não consegui recuperar nada. Os serviços, as configurações e, pior, o código das aplicações que eu mesmo tinha desenvolvido foram embora, porque nada daquilo estava num repositório git.

Recomecei do zero. E quem me ajudou a reconstruir as aplicações foi a IA: busquei o código de novo com ela, aplicação por aplicação, até tudo voltar a funcionar.

Este post é sobre o que aprendi com isso e sobre como uso IA no homelab hoje, com regras claras do que ela pode e do que não pode fazer.

O que a IA fez bem no pior dia #

Quando tudo some, o problema não é só técnico, é de memória. Você sabe o que a aplicação fazia, mas não lembra de cada decisão, de cada arquivo de configuração, de cada detalhe que levou semanas para acertar.

A IA ajudou exatamente nessa parte. Fui aplicação por aplicação, buscando o código de novo com ela, revisando e testando cada pedaço antes de colocar no ar. Não foi mágico nem instantâneo, mas transformou “perdi meses de trabalho” em “tenho trabalho para alguns dias”.

O que eu não gostaria de repetir é a situação que tornou isso necessário.

A lição número um não é sobre IA: é sobre git #

A causa do estrago não foi o disco que morreu. Disco morre. A causa foi o código existir em um lugar só.

Depois do desastre, a regra virou: toda aplicação nasce com repositório. Hoje cada projeto meu tem repositório privado no GitHub, e o deploy é feito por runners do GitHub Actions que rodam aqui mesmo, num container LXC do Proxmox dedicado a isso. Se o servidor morrer amanhã, o código está a salvo, e o caminho para colocar tudo de volta no ar está escrito no próprio workflow.

Este blog é um exemplo: o código fica num repositório, cada push no main dispara um deploy pelo runner self-hosted, e um script do lado do servidor roda os testes, troca a versão e volta para a anterior se algo der errado.

Como eu uso a IA no homelab hoje #

Uso o Claude Code, que roda no terminal e executa comandos de verdade. Isso é poderoso e, por isso mesmo, perigoso sem limites. Na prática, ele me apoia em:

  • montar e manter os containers de serviço;
  • escrever e corrigir o código das minhas aplicações;
  • configurar deploys, timers do systemd e servidores web;
  • investigar problemas lendo logs e configurações.

E não toca em uma coisa: o host do Proxmox. A IA trabalha dentro dos containers e das aplicações, nunca na camada que segura todo o resto. Se algo der muito errado dentro de um container, eu restauro aquele container. Se der errado no host, eu perco o homelab inteiro.

As regras que eu dou para a IA #

Regras claras funcionam melhor do que confiar no bom senso de uma ferramenta. As que eu sigo:

  1. Segredos ficam fora do código. Senhas e chaves vão em arquivos .env dentro de /etc/<app>/, com permissão 600, nunca no repositório e nunca em logs.
  2. Nada sai para fora sem eu confirmar. Publicar algo, criar recurso em nuvem ou gastar dinheiro só acontece depois do meu OK.
  3. Produção não se mexe sem pedir. Aplicações em produção têm um caminho de deploy definido, e a IA não faz atalhos.
  4. Instruções por projeto ficam escritas. Cada repositório tem um arquivo CLAUDE.md com as regras daquele projeto, que o Claude Code lê no início de cada sessão.

O item 4 é o que mais fez diferença. Em vez de repetir as mesmas regras toda vez, elas ficam versionadas junto com o código, como qualquer outra configuração. Aplicar a regra 1 é simples:

install -d -m 750 /etc/minha-app
install -m 600 /dev/null /etc/minha-app/app.env

Depois é só a unit do systemd carregar esse arquivo com EnvironmentFile=/etc/minha-app/app.env.

O que eu ainda não fiz: modelos locais #

Muita gente no mundo self-hosted roda modelos de IA localmente. Eu ainda não testei e, sendo honesto, ainda não sei montar isso bem. Com 24 GB de RAM e sem GPU dedicada no meu ThinkCentre, qualquer coisa nessa linha vai ser limitada, então por enquanto uso um serviço na nuvem com as regras acima.

Também estou testando um agente self-hosted, o Hermes Agent, mas isso ainda está em fase de experimento e merece um post próprio quando tiver conclusões.

Se você quer começar #

O caminho que eu recomendaria, olhando para trás:

  • Coloque tudo no git antes de qualquer outra coisa. A IA ajuda a reconstruir, mas ter o código salvo é muito melhor do que precisar reconstruir.
  • Defina o alcance da IA: containers e aplicações, sim; host do hipervisor, não.
  • Escreva as regras num arquivo do projeto em vez de confiar na memória da conversa.
  • Revise o que ela faz, principalmente comandos que apagam, sobrescrevem ou publicam.

No meu caso, a IA transformou um desastre em alguns dias de trabalho. Mas o que me deixa tranquilo hoje não é a IA, é saber que um disco morto não leva mais o meu código junto.

Fontes e documentação