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.

Neste post eu conto como ela está ligada, como fiz o teste, o que a queda de verdade mostrou e qual é o ponto fraco que ainda preciso resolver.

O que está ligado nela #

Na River 3 Plus estão três coisas:

• o modem de fibra do provedor;
• o roteador Wi-Fi;
• a máquina do Proxmox, um Lenovo ThinkCentre M720q.

Somando tudo, o consumo fica entre 30 W e 50 W no dia a dia.

O detalhe que muita gente esquece é o modem. Não adianta o servidor continuar ligado se a internet cai junto com a energia: os serviços que publico pelo Cloudflare Tunnel ficariam fora do ar do mesmo jeito. No homelab, “manter no ar” quer dizer a cadeia inteira até a fibra, não só o servidor.

Por que uma estação portátil no lugar de um nobreak #

Vi a proposta de usar uma EcoFlow como UPS no canal O Dev Aguniado, que venho acompanhando no YouTube, e gostei da ideia.

Um nobreak tradicional resolve o problema, mas para uma carga baixa e constante, como a de um homelab pequeno, a estação portátil tem vantagens claras. Segundo a ficha técnica da EcoFlow, a River 3 Plus tem:

A química LiFePO4 é a parte que mais me interessa. Ela aguenta bem a vida de “fica plugada 24 horas por dia e descarrega de vez em quando”, que é exatamente o uso de um UPS.

O tempo de troca abaixo de 10 ms é o que faz o computador nem perceber a queda. Uma análise independente do StorageReview mediu 9 ms na prática.

O teste das 8 horas #

Eu não confiei só na conta: desliguei a River 3 Plus da tomada com tudo ligado e cronometrei até o fim. Deu 8 horas.

A conta fecha com o consumo que eu vejo. São 286 Wh divididos por 8 horas, o que dá uns 36 W em média, antes de descontar as perdas de conversão do inversor. Isso coloca o consumo durante o teste perto do piso da minha faixa de 30 a 50 W. Com o servidor trabalhando mais, a autonomia cai.

Por isso a minha recomendação é a mesma que eu segui: meça, não calcule. A conta serve para saber se vale a pena comprar. O teste é o que diz quanto tempo você realmente tem. Se for fazer o seu:

1. Carregue a estação até 100% e deixe tudo ligado como no dia a dia.
2. Tire a estação da tomada e anote o horário.
3. Acompanhe a porcentagem de tempos em tempos para saber o ritmo de descarga.
4. Anote quando ela desligar e depois veja se todos os equipamentos voltaram sozinhos quando a energia retornou.

O passo 4 importa tanto quanto a autonomia. Um servidor que não liga sozinho depois da volta da energia transforma uma queda curta em horas de serviço fora do ar.

A queda real de quase 3 horas #

Teste controlado é uma coisa, queda de verdade é outra. Quando a energia caiu aqui por quase três horas, tudo continuou funcionando normalmente: containers, cofre de senhas da família, DNS interno e acesso externo.

Com 8 horas de autonomia medida, três horas de queda usaram bem menos da metade da bateria. É uma margem confortável para as quedas que eu costumo ter. Mas ela não é infinita, e foi aí que percebi os dois problemas que ainda tenho.

O ponto fraco: ninguém me avisou #

O primeiro problema é que o app oficial da EcoFlow não me avisou de nada: nem quando a energia caiu, nem quando a estação passou para a bateria, nem quando a rede elétrica voltou. Para um equipamento vendido como UPS, essa notificação é o mínimo.

Como eu queria saber na hora que o homelab estava rodando na bateria, criei um app próprio para a minha EcoFlow que manda esses três avisos. Ele merece um post só dele, que vem em breve.

E se a queda passar de 8 horas? #

O segundo problema é mais sério. Hoje não existe desligamento automático no meu setup. Se uma queda durar mais que a bateria, o Proxmox desliga de forma abrupta, como se alguém puxasse o cabo da tomada. Na maioria das vezes tudo volta bem, mas é esse tipo de desligamento que corrompe disco e banco de dados.

A boa notícia é que a River 3 Plus tem uma porta USB-B pensada para isso. Segundo a EcoFlow, o software Power Manager dela conversa com PCs e NAS por essa porta e inicia um desligamento seguro quando a bateria fica baixa.

Para quem roda Linux, como no Proxmox, o caminho natural é o NUT (Network UPS Tools). Nele, a estação aparece como um UPS USB comum (HID). O suporte ainda está em andamento:

• na issue #2735 do projeto, há relatos de gente monitorando a River 3 Plus com o driver usbhid-ups;
• alguns valores ainda não são confiáveis;
• o suporte oficial está previsto para uma versão futura do NUT.

Um primeiro teste seguro, que não muda nada no sistema, é ver se o Proxmox enxerga a estação quando você liga o cabo USB:

lsusb | grep -i 3746

Nos relatos da issue, a River 3 Plus aparece com o ID 3746:ffff.

Esse é o meu próximo passo. Quando estiver rodando, conto aqui como ficou.

Se você vai montar o seu #

Resumindo o que aprendi com a River 3 Plus como UPS do homelab:

• Some toda a cadeia: modem ou ONT, roteador e servidor. Sem internet, o servidor ligado serve pouco.
• Use as tomadas protegidas e fique longe do X-Boost.
• Meça a autonomia com a sua carga real. A conta é só o ponto de partida.
• Confira se tudo volta sozinho quando a energia retorna.
• Resolva o aviso e o desligamento automático. Autonomia sem aviso é sorte, e sem desligamento automático é um risco que só aparece na queda longa.

Oito horas de autonomia para um homelab de 30 a 50 W me deram tranquilidade para as quedas do dia a dia. A próxima etapa é saber na hora quando a energia cai e deixar o servidor desligar sozinho e com segurança quando a queda passar da conta.

Ao longo desse tempo eu aprendi muita coisa do jeito difícil. Já sofri com bots batendo na porta 22, já fiquei sem energia e descobri o que aguentava ou não, e já perdi o SSD e o HD de backup no mesmo dia, sem ter como recuperar. Cada um desses momentos me ensinou algo que eu gostaria de ter lido antes.

O Self-Hosted! nasceu para isso: registrar o que funciona, o que quebrou e como resolvi, em português e sem enrolação.

O que você vai encontrar aqui #

Um post por dia, sempre respondendo a uma dúvida concreta, sobre estes assuntos:

• Proxmox: containers, máquinas virtuais e o dia a dia de quem mantém um nó em casa.
• Hardware: mini PCs, memória, discos e o que eu compraria de novo.
• Energia e UPS: como manter tudo de pé quando a luz cai.
• Apps self-hosted: o que eu hospedo, por que ficou e o que eu desinstalei.
• Rede e acesso: publicar serviços sem abrir portas e acessar tudo de fora com segurança.
• Backup e segurança: a parte que ninguém quer fazer até precisar.
• IA no homelab: como eu uso IA para montar e manter as coisas, com limites claros.

Como eu escrevo #

Escrevo a partir do meu próprio homelab. Quando conto que algo funcionou, é porque funcionou aqui. Quando é um caminho que eu ainda não testei, aviso. Comandos e configurações vêm com a versão em que foram testados e com o link da documentação oficial.

O próprio blog é um exemplo do que vou contar por aqui: roda num container do meu Proxmox e sai para a internet por um Cloudflare Tunnel, sem nenhuma porta aberta no roteador.

Se você também mantém um homelab, ou está pensando em começar, seja bem-vindo. O primeiro post de verdade sai hoje, sobre a bateria que segurou tudo na última queda de energia.