- Para gerenciar serviços do homelab, conectei acesso ao Git no OpenCode Web UI e montei um fluxo em que alterações feitas pela IA são implantadas pelo GitOps após revisão de PR
- Cerca de 12 stacks de docker compose foram migradas para o Arcane e passaram a ser gerenciadas com GitOps, usando ferramentas de IA na manutenção dos serviços
- Ao atualizar contêineres, antes eu gastava horas conferindo notas de versão, verificando breaking changes e fazendo checagens manuais, mas agora leio resumos das release notes em poucos minutos, tornando upgrades de versão mais fáceis e seguros
- O OpenCode roda como servidor e fornece terminal, navegador de arquivos, Git diff e git worktree, além de sincronizar sessões de código persistentes entre vários dispositivos
- A IA não pode acessar diretamente os serviços reais e só pode fazer push para branches Git, criando uma estrutura em que código não revisado não é implantado
Fluxo de gerenciamento do homelab
- Dei ao OpenCode Web UI acesso ao Git para facilitar o gerenciamento do homelab, e quando o OpenCode faz push de mudanças no Git, uma pessoa aprova o PR e depois o GitOps implanta as alterações
- O OpenCode roda como servidor, e sessões de código persistentes são sincronizadas entre vários dispositivos
- Os serviços gerenciados são cerca de 12 stacks de docker compose, recentemente migradas para o Arcane para serem gerenciadas e implantadas com GitOps
- O primeiro caso de uso das ferramentas de IA foi atualização de contêineres
- Antes, era preciso encontrar as notas de versão de cada serviço, verificar breaking changes, executar a atualização e checar manualmente problemas em cada serviço
- Esse processo levava horas, mas agora leio resumos das release notes em poucos minutos, tornando upgrades de versão mais fáceis e seguros
- Usei IA para adicionar healthchecks à maioria dos contêineres, o que ajudou a detectar problemas mais rapidamente
OpenCode
- Eu usava principalmente o Claude Code, mas como os provedores de IA estão reduzindo o valor entregue ao cliente com limites de tokens, passei a procurar outras opções
- A ferramenta que eu queria precisava não ficar presa a um fornecedor específico e oferecer um ambiente de código compatível com os principais plugins
- Depois de testar vários ambientes de código, escolhi o OpenCode, que foi a ferramenta de que mais gostei entre as opções que experimentei
- O fato de o OpenCode ter um servidor web e uma Web UI embutidos foi o que motivou a ideia desta plataforma de desenvolvimento de IA para homelab
Plataforma de desenvolvimento com IA
- Criei uma VM simples no host Truenas com ferramentas básicas de desenvolvimento e adicionei o servidor web do OpenCode como uma unit do systemd
- Esse ambiente oferece terminal embutido, navegador de arquivos, Git diff e suporte a git worktree, permitindo gerenciar várias sessões de código ao mesmo tempo
- A Web UI móvel do OpenCode teve pop-ups de pergunta e resposta muito bons
- No servidor Git, atribuí um usuário dedicado ao OpenCode e uma chave SSH exclusiva
- O OpenCode pode clonar projetos e fazer push de branches
- Ele não pode fazer push direto para a branch de deploy
- O workflow coloca a IA antes da revisão do PR, com o OpenCode escrevendo as mudanças e uma pessoa fazendo o merge diretamente no PR
- Essa estrutura impede que código não revisado seja implantado
- A VM pode acessar a internet e o servidor Git, mas não pode acessar os serviços reais
- Como o raio de impacto é pequeno, considerei aceitável dar ao OpenCode privilégios de root na VM quando for necessário instalar ferramentas de build ou dependências de teste
- Essa estrutura pode evoluir para uma plataforma de desenvolvimento para produção na forma de contêineres temporários para desenvolvedores, com ferramentas pré-instaladas, guardrails de acesso e logs de auditoria
- A configuração atual entrega as funções necessárias sem ter componentes demais
Workflow
- O fluxo básico de trabalho começa com a etapa de planejar uma funcionalidade ou melhoria no OpenCode
- O plano inclui especificação, plano de implementação e auto-revisão
- Sempre que possível, as mudanças são testadas ou validadas
- As partes de que não gosto são ajustadas iterativamente com o OpenCode
- O OpenCode faz push das mudanças para uma feature branch
- Abro um PR a partir dessa branch e, quando fico satisfeito, faço o merge do PR
- Depois do merge, o GitOps assume a implantação
- Mudanças em serviços docker são tratadas pelo Arcane
- Mudanças na configuração do Home Assistant são tratadas pelo plugin GitOps
- Mudanças no blog são tratadas por um worker do Cloudflare Pages
Combinação de Arcane GitOps com OpenCode
- Migrei os serviços do Truenas para um projeto Arcane GitOps, e o principal objetivo era gerenciar, em um repositório baseado em Git, todas as stacks de docker compose que rodavam no Truenas
- Ao adicionar o OpenCode junto, essa abordagem funcionou melhor do que eu esperava
- Agora consigo atualizar o networking de todos os contêineres pelo celular, e gerenciar configurações espalhadas ficou muito mais fácil
- Antes, eu gastava horas percorrendo todas as stacks de compose e rastreando conexões de rede
- Agora posso indicar ao OpenCode a base de código e o objetivo, revisar as mudanças geradas no PR e então fazer o merge
Limitações restantes e controle de acesso
- A maior lacuna que resta é o feedback de CI
- No GitHub, agentes de código conseguem ver logs do Actions para diagnosticar testes com falha, erros de linter, stack traces e mudanças em planos de IaC
- Essa abordagem ajuda a manter um loop de feedback rápido até para mudanças que testes unitários não cobrem
- No Forgejo, esse fluxo é mais difícil
- O Forgejo Actions não expõe logs de jobs por API pública
- Existe uma API não documentada, mas não quero basear a configuração nela
- A configuração atual permite que a IA crie mudanças na infraestrutura doméstica a partir de qualquer dispositivo, sem ter acesso direto aos serviços que estão sendo alterados
- Posso começar uma mudança no computador, revisar o PR no celular e deixar o GitOps cuidar da implantação
1 comentários
Comentários no Hacker News
Ainda estou tentando encontrar a forma de integração de IA certa para o meu ambiente. No momento não há interação entre o Forgejo e o agente de código, e eu também testei o runner do Forgejo Actions, mas o gerenciamento de contexto ficou meio nebuloso
Dá para receber o conteúdo de issues ou PRs, mas quando há várias idas e voltas ou a discussão migra de uma issue para um PR, tudo fica confuso rapidamente
Estou fazendo algo parecido e, em vez de um servidor opencode permanente, uso um fluxo de trabalho que executa o opencode dentro de um runner de ações do Forgejo: https://codeberg.org/dragonfyre13/forgejo-opencode
Ainda estou ajustando, mas a ideia é invocar o Opencode com
/ocdentro de uma issue do Forgejo e ele voltar com um PR pronto para revisãoÀs vezes parece que, no setor de tecnologia, muita gente passa por coisas muito parecidas de forma independente quase ao mesmo tempo, mas pouca gente de fato escreve ou compartilha isso
Eu também estou montando um sistema parecido, e foi divertido ler o post e os comentários vendo que todo mundo está passando pelo mesmo processo
O problema é que passamos 99% do tempo hackeando coisas legais e só 1% falando sobre elas. Precisamos falar mais
Eu estava conversando com um advogado e, quando o tempo já estava quase acabando, tentei fazer “só mais uma pergunta”, e ele respondeu: “marque mais 30 minutos e falamos disso”. É uma forma justa de fazer as coisas
Eu estava procurando motivação para escrever sobre o meu laboratório de IA, e este post foi exatamente o empurrão de que eu precisava
Minha configuração também segue uma ideia parecida, mas usa n8n/git/argo/k3s e é voltada principalmente para fluxos de trabalho de automação que Qwen ou Gemma4 conseguem executar
Queria saber se alguém sabe por que este domínio está sendo bloqueado pelo resolver Quad9. O Quad9 filtra o domínio e não consigo abrir o site
O resultado de
dig @9.9.9.9 rsgm.dev NSmostraEDE: 17 (Filtered)Os dois principais motivos para eu ainda não usar essa configuração são os recursos que eu teria de dar à VM que executa o opencode para compilar o projeto e a questão de testar mais rápido
Eu executo o agente de código pi direto no Mac, junto com todo o pacote de software, como redis, postgres e kratos. Quando o agente de código roda na máquina principal de desenvolvimento, consigo compilar mais rápido e verificar as mudanças mais rapidamente, por exemplo recompilando só o backend, reiniciando e então testando as alterações imediatamente no cliente de UI
Eu também faço algo muito parecido. Executo o OpenCode em um Proxmox LXC e adicionei uma camada Kimaki por cima para integrar com o Discord
Gostando ou não, dá para conversar com a base de código e, se você curte isso, até com mensagens de voz, então ficou bem legal
Excelente. IA para homelab parece algo que vai ficar muito divertido
Agora estou fazendo o Claude gerenciar meu homelab em todos os equipamentos, e a instalação e manutenção do homelab deixou de ser “uma armadilha fascinante por anos, que nunca funciona totalmente direito e consome tempo” para virar “uma ideia realmente boa que amplia minha capacidade”
Funciona bem para tarefas bem delimitadas, como “crie um arquivo docker compose” ou “me dê uma configuração do NSD”, mas mesmo nesses casos você já precisa saber quais tecnologias de base são necessárias e o que perguntar
Parece bem boa a ideia de adicionar acesso ao Git na OpenCode Web UI para facilitar o gerenciamento do homelab, deixar o OpenCode fazer push no Git, eu aprovar o PR e o GitOps implantar as mudanças
Antes de ler, porém, eu queria saber se para fazer algo parecido seria preciso gastar milhares de dólares com RAM e GPU
Nós também fazemos algo parecido, mas permitindo que o agente também abra PRs, e usamos o sistema ReARM para rastrear metadados de release e sessões do agente
Recentemente também lançamos uma opção para o agente rastrear implantações baseadas em Helm via ReARM: https://docs.rearmhq.com/workflows/devops.html
Infelizmente, ao contrário do GitHub, o Forgejo não tem CLI