Day 0: Por que DevStation?

Quase sempre acontecia de madrugada. Um disco numa máquina que rodava havia anos silenciosamente desistia, 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 DevStation nasceu como resposta a essa madrugada recorrente. 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 de verdade, 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 dramático — só a morte lenta e comum de hardware que nunca descansa. E toda vez, a mesma noite se repetia.

Eu fazia as coisas responsáveis. Dumps automáticos de banco, rotinas de backup, upload para a nuvem. Depois RAID 1 e SSDs para comprar resiliência. Nada disso removia o custo real: os dados sobreviviam, mas a máquina — o arranjo exato de VMs, pacotes, configs e as dezenas de pequenas decisões que faziam tudo conversar — não. Restaurar um backup era fácil. Reconstruir o ambiente em volta dele, não.

E o ambiente escapava da minha própria cabeça. Bastavam alguns meses de estabilidade e eu já não sabia dizer, de memória, exatamente como o cluster estava organizado.

Tentando torná-lo reprodutível

A primeira tentativa honesta foi documentação como código: comecei a versionar arquivos docker-compose e manifestos Kubernetes no GitHub, cada um com um README guiando o eu-do-futuro pelos passos para trazer tudo de volta. Ajudou. Também não bastou. Uma reconstrução ainda era uma marcha manual por 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í — está num repositório anterior chamado platform.

Funcionava assim. Um CLI em Bash com um wizard dialog 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.

Provou a ideia. E tinha uma falha que eu não conseguia projetar para longe: 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; estava a um comando de reconstruir a coisa que reconstrói a coisa.

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 — exatamente o que o desenho anterior nunca pôde afirmar.

É 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; 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; 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 lembrado. E porque a topologia inteira é declarada, o DevStation consegue destruí-la e reprovisioná-la — uma única VM ou o parque inteiro — sob demanda.

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. 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.

Há uma razão mais prosaica também. 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.

Day 0, repetível

O disco vai morrer de novo. Essa parte não mudou e provavelmente nunca vai. O que mudou é o que acontece depois: em vez de um fim de semana perdido e uma memória forçada, reconstruir o homelab é uma topologia descrita e um comando. O Day 0 — o dia em que você sobe tudo do nada — costumava ser o pior dia. O objetivo inteiro do DevStation é torná-lo um dia comum.