Início / Infraestrutura como código
Como trabalhamos

Menos operação manual, mais previsibilidade

A sua infraestrutura deixa de ser um conjunto de servidores configurados à mão e passa a ser código versionado: cada mudança é revisada antes de ir ao ar, aplicada por uma esteira automática e revertida em minutos se der errado. É o mesmo rigor que o seu time de desenvolvimento já usa no software — aplicado à camada que sustenta ele.

apcode@infra:~/infra$
// a infraestrutura tem histórico
$ git log --oneline -4
a91c4e2 sobe limite de memória da API
7d0b118 abre 5432 só para o app
3fe9a05 rotaciona certificado do portal
c15d7aa +2 réplicas no frontend
$ git revert a91c4e2
pipeline #482 · apply concluído em 41s
// "quem mexeu nisso?" tem resposta.

Você reconhece algum destes sintomas?

Nenhum deles é falta de competência do time — são consequências previsíveis de operar servidor por acesso remoto e memória, sem um registro do que foi feito.

Ninguém sabe como aquele servidor foi montadoEle funciona, mas foi configurado há três anos por alguém que não está mais na empresa. Reinstalar do zero é um projeto, não uma tarefa.

Só uma pessoa consegue mexerO conhecimento está na cabeça de alguém. Férias, doença ou desligamento viram risco operacional direto.

Homologação não é igual à produçãoO teste passa, a produção quebra — e a diferença entre os dois ambientes ninguém consegue listar com precisão.

Voltar atrás significa restaurar backupUma mudança ruim de configuração vira madrugada de restauração, porque não existe "desfazer" para o que foi digitado no terminal.

A documentação está desatualizadaO wiki descreve o ambiente de dois anos atrás. Todo mundo sabe disso, e por isso ninguém confia nele.

A auditoria pergunta e você não tem como provarQuem alterou aquela regra de firewall, quando, e com aprovação de quem? Sem registro, a resposta honesta é "não sei".

Descrever, versionar, aplicar

Três tempos, sempre nessa ordem. O que muda em relação ao jeito manual é que nenhuma alteração chega ao servidor sem passar pelos dois primeiros.

01

Descrever

Rede, máquinas, pacotes, usuários, firewall, banco, aplicação: tudo vira arquivo. Terraform para o que é recurso de nuvem, Ansible para o que roda dentro do servidor, manifestos ou Helm para o que roda em cluster.

infra/terraform/ infra/ansible/ infra/k8s/
02

Versionar

Esses arquivos vivem num repositório Git privado seu. Toda mudança entra por revisão: alguém propõe, alguém lê, fica registrado quem aprovou. O histórico do repositório passa a ser o histórico do ambiente.

git commit → merge request → aprovação
03

Aplicar

Quem aplica é a esteira de CI/CD, não uma pessoa logada no servidor. Ela valida, mostra o que vai mudar, espera aprovação quando é produção e então executa — sempre do mesmo jeito, sem passo esquecido.

pipeline: validate → plan → approve → apply
O ganho que aparece primeiro

O código é a documentação — e essa é a única que não envelhece

Toda empresa tem um documento de infraestrutura desatualizado, e todo mundo sabe disso — por isso ninguém confia nele. A diferença aqui é estrutural: o repositório não descreve o ambiente, ele produz o ambiente. Se os dois divergirem, quem está errado é o servidor, e a próxima execução corrige.

A planta baixa sempre atual Servidores, portas, integrações, versões, quem fala com quem. Não é o desenho de como o ambiente foi pensado em 2021 — é o que está no ar agora.
Histórico com motivo Cada linha tem autor, data, justificativa e quem aprovou. "Por que essa porta está aberta?" deixa de ser arqueologia e vira uma consulta de trinta segundos.
Entrada de gente nova Quem chega lê o repositório e entende o ambiente sozinho, sem depender da agenda da única pessoa que sabe. O conhecimento deixa de ser um risco de RH.
Evidência para auditoria Quando perguntam quem alterou o quê e com qual aprovação, a resposta sai do histórico — com registro, não com estimativa.
Automação e documentação são o mesmo trabalho aqui

Este é o ponto que costuma passar despercebido: quando o ambiente é automatizado, documentar deixa de ser uma tarefa separada que alguém precisa lembrar de fazer depois. Escrever o código que aplica a mudança já é escrever o registro do que mudou. Ninguém precisa de disciplina extra — o processo produz a documentação como subproduto, e é por isso que ela não fica para trás.

Onde o seu código de infraestrutura mora

Git privado, no seu servidor: Gitea ou GitLab

O repositório de infraestrutura é a planta baixa da sua rede: nomes de servidor, topologia, regras de firewall, integrações. Ele pode ficar numa nuvem pública de código — mas quando a empresa prefere manter isso dentro de casa, hospedamos um Git privado no seu próprio ambiente, com login integrado ao acesso que o time já usa.

Gitea — leve e direto ao ponto Escrito em Go, roda em um servidor modesto (é o que usamos na nossa própria infraestrutura). Repositórios, revisão de código, issues, registry de contêiner e Gitea Actions — a esteira de CI/CD com sintaxe compatível com GitHub Actions. Manutenção quase nula: um binário e um banco.
GitLab — a plataforma completa Quando o time precisa de mais que Git: CI/CD com runners dedicados, ambientes, aprovações formais, registry, gestão de pacotes, backend de state do Terraform, controles de conformidade. Custa mais recurso de máquina e mais operação — e entrega proporcionalmente mais.
Qual dos dois?

A regra prática: se o que você quer é guardar código com histórico, revisão e uma esteira simples, o Gitea entrega isso com uma fração do consumo e da manutenção. Se o processo interno exige fluxo de aprovação formal, múltiplos ambientes e relatórios de conformidade, o GitLab paga o próprio peso. Nós operamos os dois — e dizemos qual é o seu caso antes de você comprar servidor.

git.suaempresa.com.br
// clone com o login que você já usa
$ git clone https://git.suaempresa.com.br/infra/producao.git
Receiving objects: 100%
$ git push -u origin ajuste-firewall
remote: Merge request #37 criado
// TLS válido, SSO da empresa,
// backup no seu plano de backup.

A esteira que aplica a mudança no seu lugar

Ninguém entra no servidor para mudar configuração. A alteração é proposta no repositório e a esteira faz o resto — na mesma ordem, todas as vezes, com registro de cada execução.

Mudança de infraestrutura
Validação e formataçãoSintaxe, padrão de escrita e análise estática. Erro bobo morre aqui, em segundos, sem chegar perto da produção.
Prévia do que vai mudarO plan lista exatamente o que será criado, alterado e destruído. Essa lista fica anexada ao merge request, para ser lida antes de qualquer aprovação.
Aprovação humana (só em produção)Homologação segue sozinha; produção espera um clique de quem tem autoridade para dar. Fica registrado quem aprovou e quando.
Aplicação e notificaçãoA esteira aplica, guarda o log da execução e avisa o canal do time. Se falhar no meio, o estado real é comparado com o desejado na execução seguinte.
Deploy de aplicação
Build e testesO commit na branch principal dispara build e a bateria de testes do projeto. Sem verde, não há imagem.
Imagem versionada no registry privadoCada build gera uma imagem com tag rastreável até o commit — e ela fica no seu registry, não numa conta pessoal de alguém.
Publicação sem downtimeAtualização gradual no cluster (ou na stack Docker), com verificação de saúde antes de tirar a versão antiga do ar.
Rollback em um comandoA versão anterior continua disponível. Voltar é uma operação de segundos — não uma restauração de backup.
E as senhas, ficam no repositório?

Nunca. O repositório guarda a estrutura; as credenciais ficam num cofre à parte e são injetadas pela esteira no momento de aplicar — inclusive quando a esteira roda sem ninguém olhando. É o ponto que mais falha nas migrações para infraestrutura como código, e por isso ele tem uma página inteira: segurança & gestão de segredos.

O que entregamos

Não é consultoria de slide: no fim do projeto existe um repositório que reconstrói o seu ambiente, e um time seu capaz de operá-lo.

Levantamento do que existe hoje

Inventário dos servidores, serviços, integrações e dependências — inclusive o que ninguém lembrava que estava ligado.

Repositório de infraestrutura

Terraform, Ansible e manifestos organizados por ambiente, com README que explica como aplicar cada parte.

Git privado instalado e integrado

Gitea ou GitLab no seu ambiente, com HTTPS válido, login corporativo, backup e política de branches.

Esteiras de CI/CD prontas

Pipelines de infraestrutura e de deploy de aplicação, com runners configurados e aprovação manual em produção.

Ambientes reproduzíveis

Homologação gerada a partir do mesmo código da produção — as diferenças ficam explícitas em arquivo de variáveis, não em surpresa.

Segredos fora do código

Cofre central integrado à esteira, para que nenhuma senha precise ser commitada nem passada por mensagem.

Padrões de segurança embutidos

Firewall, acesso nominal, TLS e hardening entram como código junto do resto — aplicados igual em todo servidor novo.

Transferência de conhecimento

Sessões práticas com o seu time e runbooks curtos para as operações do dia a dia. O objetivo é você não depender de nós.

Propriedade total do resultado

Repositório, credenciais e servidores são seus, desde o primeiro dia. Não há componente proprietário nosso no meio.

Como a migração acontece

Sem big bang: o ambiente atual continua no ar enquanto vai sendo descrito em código, serviço por serviço.

1
Diagnóstico

Mapeamos o ambiente, os riscos mais urgentes e o que dá mais retorno automatizar primeiro. Sai com um plano priorizado.

2
Fundação

Git privado, esteira, cofre de segredos e o primeiro serviço migrado ponta a ponta — o piloto que prova o fluxo.

3
Migração incremental

Os demais serviços entram no código em ondas, cada onda validada em homologação antes de tocar a produção.

4
Autonomia

Treinamento do time, runbooks e acompanhamento até que uma mudança de rotina role sem a gente na sala.

Tudo aberto, nada proprietário

Ferramentas consolidadas, com comunidade grande e profissionais disponíveis no mercado — para que trocar de fornecedor nunca seja um problema técnico.

Git Gitea GitLab & GitLab CI Gitea Actions Terraform Ansible Docker Kubernetes & Helm HashiCorp Vault Vagrant Make

Perguntas que sempre aparecem

Não. O ambiente atual segue no ar e vai sendo descrito em código em paralelo. Em alguns casos conseguimos até importar recursos que já existem para dentro do Terraform, sem recriá-los. A troca de fato acontece serviço por serviço, sempre com um caminho de volta.

Não — mas a transferência de conhecimento faz parte do escopo, justamente por isso. Na prática, o dia a dia do time passa a ser editar arquivo e abrir merge request, o que é bem mais próximo do que um desenvolvedor já faz do que administrar servidor por linha de comando. As operações rotineiras ficam documentadas em runbooks curtos.

Dá — o Git é o mesmo nos dois, então o histórico dos repositórios migra sem perda. O que exige retrabalho é a esteira: a sintaxe de pipeline do GitLab CI não é a mesma do Gitea Actions. Por isso a escolha vale uma conversa de meia hora no início, e não uma decisão tomada no impulso.

Pode, e para muitas empresas é a escolha certa: menos um serviço para operar. Hospedar internamente faz sentido quando existe exigência de manter código e metadados dentro do país ou da própria rede, quando o custo por usuário pesa, ou quando a esteira precisa alcançar servidores que não estão expostos na internet. Avaliamos os dois cenários com você.

Três coisas: o plan mostra tudo que seria destruído antes de qualquer execução; produção exige aprovação humana explícita; e recursos críticos (banco, volume de dados) recebem proteção contra remoção acidental. Além disso, backup e restauração são testados de verdade, não presumidos.

Serve, e é o caso mais comum. Boa parte dos ambientes que operamos roda servidores configurados por Ansible com Docker Compose, sem cluster nenhum no meio. Infraestrutura como código é o método; Kubernetes é só uma das ferramentas que ele pode gerenciar.

Não. O repositório é seu, roda no seu Git, com ferramentas abertas e documentação em português. Qualquer profissional de infraestrutura consegue continuar de onde paramos — e isso é intencional: a nossa retenção vem do resultado, não de você ficar preso.

Quer saber quanto do seu ambiente já dá para virar código?

O diagnóstico mapeia o que existe hoje e mostra por onde começar, com estimativa de esforço e sem compromisso.

Falar com um especialista