The latest articles on DEV Community by Pedro Almeida (@heyalmeida). https://dev.to/heyalmeida https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F3981772%2F24965000-feb9-4c84-9159-fdb483c88c33.png https://dev.to/heyalmeida en Pedro Almeida Fri, 12 Jun 2026 18:37:45 +0000 https://dev.to/heyalmeida/como-construi-uma-plataforma-de-deploy-com-pipeline-automatizado-docker-isolado-e-logs-em-tempo-c6l https://dev.to/heyalmeida/como-construi-uma-plataforma-de-deploy-com-pipeline-automatizado-docker-isolado-e-logs-em-tempo-c6l <p>Há alguns meses, pagando $7/mês por um servidor de 512MB no Render <br> pra hospedar uma API de um projeto da escola, decidi entender como <br> esse tipo de infraestrutura funciona por baixo — e construir a <br> minha própria versão.</p> <p>O resultado é o <strong>Arctis Deploy</strong>: uma plataforma de deploy <br> contínuo via Git, com Docker isolado por projeto. Esse post é <br> sobre como ela funciona por dentro.</p> <h2> Arquitetura geral </h2> <p>Frontend (Next.js)</p> <p>│</p> <p>▼</p> <p>Backend (Go + Fiber) — Clean Architecture</p> <p>│</p> <p>├──► Deploy-Agent (roda em cada servidor) → Docker</p> <p>└──► Database-Agent (provisiona MySQL/Postgres)</p> <ul> <li>em desenvolvimento, ainda não disponível para usuários</li> </ul> <p>Cada servidor de produção roda um <code>deploy-agent</code> próprio. O <br> backend central envia comandos via HTTPs autenticado e o agent <br> executa o que for necessário — clone, build, container, métricas.</p> <h2> O pipeline de deploy </h2> <p>Todo deploy passa por 5 etapas sequenciais:</p> <ol> <li> <strong>clone</strong> — <code>git clone --depth 1</code>, otimizado pra trazer só o necessário</li> <li> <strong>analyze</strong> — detecta o framework automaticamente lendo <code>package.json</code>, <code>requirements.txt</code>, <code>go.mod</code>, etc.</li> <li> <strong>build</strong> — gera um Dockerfile multi-stage específico pro framework detectado (timeout: 15min)</li> <li> <strong>deploy</strong> — sobe o container na porta alocada, com limites de CPU/RAM aplicados</li> <li> <strong>health check</strong> — faz requisições até o container responder, com rollback automático em caso de falha</li> </ol> <p>Cada etapa emite logs estruturados (<code>info</code>/<code>warn</code>/<code>error</code>), <br> transmitidos via WebSocket em tempo real pro frontend.</p> <h2> Detecção automática de framework </h2> <p>Next.js, React, Vue, Node.js, e sites estáticos. <br> A detecção é baseada nos arquivos do repositório — o usuário só <br> conecta o Git e dá push.</p> <h2> Outros detalhes </h2> <ul> <li> <strong>Pool de recursos</strong>: cada plano define um total de Projetos/CPU/RAM/disco que o usuário distribui livremente entre seus projetos</li> <li> <strong>Auto-sleep</strong>: no free, containers sem tráfego são pausados (<code>docker pause</code>) — não destruídos — e despertam automaticamente na próxima requisição</li> <li> <strong>Domínios</strong>: subdomínio automático ou domínio próprio, com SSL via Cloudflare</li> <li> <strong>Pagamentos</strong>: MercadoPago integrado, planos em real</li> </ul> <h2> Validação inicial </h2> <p>Postei essa história no Tabnews e, em poucos dias, tive mais de <br> 250 pageviews e 65+ visitantes únicos, boa parte chegando até a <br> documentação e o dashboard. Ainda early stage, mas validou que a <br> dor — preço em dólar, pouco recurso — é real pra outros devs também.</p> <h2> Testar </h2> <p>A plataforma está em beta público: <a href="https://launch.arctisdev.com" rel="noopener noreferrer">https://launch.arctisdev.com</a></p> <p>Plano free: 2 vCPUs, 2GB RAM, 4GB disco — sem cartão.</p> <p>Se quiser trocar ideia sobre a arquitetura, decisões técnicas ou <br> tiver sugestões, comenta aqui ou entra no <a href="https://discord.gg/Qshcnfq2B2" rel="noopener noreferrer">Discord</a>.</p> docker automation buildinpublic braziliandevs