Por que DevStation?

De tempos em tempos, um disco numa máquina que rodava havia anos parava de funcionar, o SO não bootava mais, e lá estava eu de novo: reinstalando, restaurando backups, tentando lembrar exatamente como aquilo tinha sido montado da última vez. O homelab nunca foi um ambiente crítico, o problema é que reconstruí-lo é complexo, e esse trabalho se repetia inteiro a cada falha. O DevStation nasceu como resposta a esse retrabalho. Esta é a história de como ele chegou lá.

Um homelab há mais de quinze anos

Tenho homelab há mais de quinze anos. No começo, o roteador era o firmware: um AMD Geode com 512 MB de RAM rodando BrazilFW como sistema operacional, unindo um link ADSL de 10 Mb e um link a cabo de 2 Mb (este último com IP fixo de um provedor local) em algo estável o suficiente para hospedar servidores de RPG online para os amigos. Ao lado dele, um Pentium 4 com 2 GB rodava um appserver, PHP e Apache, para o jogo e o site.

Com os anos, as máquinas ficaram mais sérias: servidores Linux, mais serviços, e por fim tudo vivendo sobre Proxmox. Mas uma coisa nunca mudou: era hardware doméstico rodando 24×7, fazendo um trabalho para o qual nunca foi dimensionado.

A mesma falha, de novo e de novo

Então os discos morriam. Nada de dramático, era só o desgaste normal de hardware rodando sem parar, e toda vez o mesmo trabalho se repetia.

Eu fazia o que era recomendado: dumps automáticos de banco, rotinas de backup, upload para a nuvem. Depois vieram RAID 1 e SSDs para ganhar resiliência. Nada disso removia o custo real: os dados sobreviviam, mas a máquina não. O arranjo exato de VMs, pacotes, configs e as dezenas de pequenas decisões que faziam tudo conversar se perdia junto. Restaurar um backup era fácil, mas reconstruir o ambiente em volta dele não era.

Com o tempo, o ambiente também escapava da minha cabeça: bastavam alguns meses de estabilidade e eu já não me lembrava mais como o cluster estava configurado exatamente.

Tentando torná-lo reprodutível

Houve também uma época em que tentei tirar tudo de casa. Cheguei a testar EC2, ECS e RDS com Jenkins na AWS, mas os custos ficaram altos demais para projetos de aprendizado. O homelab sempre foi um hobby, então não fazia sentido manter aquela estrutura. Resolvi então ressuscitar meu antigo PC gamer, um Xeon quad-core de 2007 com 8 GB de RAM, e usá-lo como servidor. Tentei instalar o Ubuntu Server, mas depois de algumas tentativas e falhas, provavelmente por incompatibilidade com o hardware antigo, parti para o Debian e tudo correu bem. Em cima dele, uma VM no VirtualBox com metade da memória, deixando espaço para uma segunda caso houvesse necessidade. Para orquestrar os serviços escolhi o K3s, uma distribuição leve do Kubernetes que encontrei depois de pesquisas e conversas com colegas de trabalho: atendia o hardware limitado e ainda tirava o Kubernetes da minha lista de temas para estudar. O GitLab completava o conjunto como CI/CD, conectado ao cluster copiando certificado e token na mão, com manifestos YAML escritos um a um para cada aplicação.

Funcionou por um bom tempo. O detalhe é o que eu precisava fazer para conseguir repetir aquilo: escrevi um artigo em formato de tutorial, passo a passo, para mim mesmo. A reprodução do ambiente era um texto que eu seguia na ordem, e cada decisão, da escolha da distribuição à porta liberada no roteador, vivia em prosa e na minha memória.

Dali evoluí para documentação como código: passei a versionar arquivos docker-compose e manifestos Kubernetes no GitHub, cada um com um README explicando os passos para subir tudo de novo. Ajudou, mas não foi suficiente. Uma reconstrução ainda era um processo manual seguindo aqueles READMEs e, com pouco tempo livre, podia se arrastar por dias.

A primeira versão: Jenkins, Terraform e um problema do ovo e da galinha

A ideia seguinte foi de fato orquestrar aquilo no Proxmox: Terraform para provisionar as VMs, Jenkins para rodar os pipelines que transformavam VMs cruas em serviços no ar. Eu construí, e está num repositório anterior chamado platform.

Era um CLI em Bash com um wizard dialog que dirigia o Terraform (o provider bpg/proxmox) para clonar VMs a partir de um template cloud-init. O Jenkins, definido como código via um seed job com Job DSL, então rodava os pipelines que configuravam cada nó: Docker e Portainer aqui, um control plane K3s com External Secrets e ArgoCD ali, um agente entrando no cluster, e um pipeline de build que gerava imagens e commitava manifestos para o ArgoCD sincronizar. Os segredos vinham do Infisical em tempo de execução.

A ideia se provou, no entanto havia uma falha que eu não conseguia contornar: precisava de infraestrutura no ar para provisionar infraestrutura. Jenkins, Infisical, Portainer, o proxy: todos precisavam estar de pé antes de qualquer automação rodar, e colocá-los de pé era, ele próprio, um bootstrap manual. Quando um disco morria, eu não estava a um comando da recuperação, precisava antes reconstruir a própria ferramenta de reconstrução.

Por que um CLI

Esse ovo-e-galinha é a razão de o DevStation ser um CLI: um binário único e autossuficiente. Um binário começa do zero. Ele não te pede para primeiro subir um control plane, um gerenciador de segredos ou um servidor de CI, ele é a ferramenta que sobe tudo isso. Nada precisa já existir para ele funcionar, algo que o desenho anterior nunca pôde garantir.

É também por isso que um cofre de segredos local é uma feature de primeira classe, não um apêndice. Você precisa de um lugar seguro para guardar credenciais desde o primeiro minuto: antes de haver um Infisical, antes de haver um cluster, antes de haver qualquer coisa. O cofre é local e criptografado em repouso, e uma futura feature de sync em nuvem vai somar mais uma camada de durabilidade sem nunca fazer o primeiro uso depender da rede.

Descreva a topologia uma vez

O formato do DevStation decorre disso. Você descreve sua topologia uma vez (os clusters Proxmox, os nós, as VMs) e os serviços que rodam em cima deles, agrupados no que chamamos de stations.

Uma station é um cluster lógico: um conjunto de serviços que pode ser distribuído por N VMs e tratado como uma unidade. Uma station pode rodar k3s (clusterizado ou standalone) como base e hospedar ArgoCD ou Percona Everest em cima, enquanto outra pode rodar um Nginx Proxy Manager que configura DNS e certificados Let’s Encrypt automaticamente, ou Jenkins sobre Portainer.

Cada serviço nasce de um blueprint: um manifesto declarativo somado a scripts shell, descrevendo juntos como instalar, verificar e remover um serviço. Os blueprints são o que torna um serviço reprodutível, em vez de depender da memória. E porque a topologia inteira é declarada, o DevStation consegue destruí-la e reprovisioná-la sob demanda, de uma única VM ao parque inteiro.

E deixe um agente conduzir

A última peça é que nada disso precisa ser conduzido por um humano no teclado. O DevStation embute um servidor MCP via stdio, então um agente de IA (Claude Code, Codex, qualquer um que fale o Model Context Protocol) pode orquestrar todas as features: listar a topologia, provisionar um nó, instalar um serviço, destruir tudo. A mesma fronteira que eu uso do terminal é a que um agente usa para rodar o ciclo sem supervisão.

Por que “DevStation”

O nome veio antes da ferramenta. Eu tinha registrado devstation.tech anos antes, no começo só para ter um DNS de verdade na frente do homelab, um lugar para expor serviços de trás de uma conexão residencial. Mas a palavra ficou por um motivo: o que eu realmente queria era uma estação de desenvolvimento: um lugar para prototipar projetos pessoais, mexer com automação residencial, subir um ambiente de teste, montar uma prova de conceito e derrubar de novo.

Tornar esse ambiente reprodutível é o primeiro trabalho, mas não é o último. Uma station deve crescer para mais com o tempo: gerenciar ambientes de desenvolvimento e, agora que agentes fazem parte do fluxo, as ferramentas de harness que ajudam a tocar os projetos.

Existe também uma razão mais prática. Um nome que engloba tudo (uma org no GitHub, e-mail com domínio próprio, uma marca só) faz o conjunto parecer um pouco menos uma pasta de hobby e um pouco mais um projeto, e mantém uma distância saudável do meu perfil pessoal.

Reconstrução repetível

Um disco pode falhar de novo. Podemos reduzir esse risco com mais redundância e garantias de disponibilidade, mas o custo cresce junto e muitas vezes deixa de fazer sentido num ambiente doméstico. O que mudou é o que acontece depois: em vez de horas de trabalho manual e memória forçada, reconstruir o homelab passa a depender de uma topologia descrita e de um comando. O objetivo do DevStation é tornar essa reconstrução um processo comum, não um novo projeto a cada falha.