DevOps open source em escala: gerir o seu próprio GitLab

O código-fonte é o único ativo que quase todas as empresas de tecnologia consideram crítico, e é também aquele que a maioria guarda em infraestrutura que não lhe pertence, numa jurisdição que não escolheu, ao abrigo de um contrato que não leu com atenção. Na maior parte dos casos, esse arranjo não traz problemas. Ainda assim, vale a pena saber quanto custa a alternativa, porque o GitLab tornou o alojamento próprio de todo o ciclo de desenvolvimento algo realmente viável há mais de uma década.

É também um produto cujo plano gratuito é mais generoso, e cujo peso operacional é maior, do que a maioria das pessoas imagina. Convém perceber as duas coisas antes de avançar. Por isso, este guia explica o que é de facto o GitLab self-managed, o que o plano gratuito oferece realmente e os três problemas operacionais que causam a maior parte das dores de cabeça.

O que é o GitLab

Não é um serviço de alojamento Git com uns extras acrescentados. É uma aplicação Rails, PostgreSQL, Redis, Gitaly para o armazenamento dos repositórios, Sidekiq para as tarefas em segundo plano e um registo de contentores, tudo empacotado num único sistema que cobre controlo de versões, revisão de código, gestão de issues, CI/CD, registos de pacotes e de contentores, análise de segurança e implementação.

Essa abrangência é o argumento todo. GitHub mais Actions mais Dependabot mais um registo de pacotes mais uma ferramenta de gestão de projetos dá um conjunto de funcionalidades comparável, montado a partir de peças soltas; o GitLab é uma só aplicação, com um único modelo de permissões e uma única base de dados. Isso é exatamente o que procura ou mais do que precisa, e a resposta depende de quanto do ciclo de vida tenciona realmente concentrar num só sítio.

O facto arquitetónico decisivo é o mesmo que se aplica a alojar a sua própria análise de tráfego com o Matomo, a sua automação de marketing com o Mautic ou o chat da sua equipa com o Mattermost: corre onde o colocar. Os seus repositórios, os seus registos de CI, os seus artefactos, a sua base de dados.

As licenças, sem rodeios

Este tema é mesmo confuso e merece precisão, porque a confusão vai no sentido contrário ao que se espera.

Há duas distribuições do código-fonte. A Community Edition tem licença MIT. A Enterprise Edition tem uma licença própria, mais restritiva, que abrange o diretório ee/ do repositório. Até aqui, parece o habitual modelo open core.

A parte que surpreende: o pacote Linux que quase toda a gente instala é a compilação da Enterprise Edition e, sem chave de licença, funciona como o plano Free, comportando-se como a Community Edition. Não está a correr a distribuição com licença MIT, a não ser que tenha escolhido deliberadamente o pacote CE. Na prática, isto raramente importa; mas se a razão para alojar o GitLab por conta própria for uma política estrita de open source, e não o controlo dos dados, importa muito, e quase ninguém verifica.

Os planos comerciais são o Free, o Premium, a 29 dólares por utilizador por mês com faturação anual, e o Ultimate, com preço sob consulta. O Premium acrescenta CI/CD avançado, melhor gestão de projetos e suporte prioritário. O Ultimate acrescenta o pacote de segurança e conformidade: testes de segurança de aplicações, segurança da cadeia de abastecimento, análise de dependências. Os dois planos pagos incluem atualmente GitLab Credits para as funcionalidades de IA, 12 dólares por utilizador por mês no Premium e 24 no Ultimate. A página de preços do GitLab apresenta estes créditos incluídos como uma oferta promocional por tempo limitado, sujeita a alteração por decisão do GitLab.

Eis o facto que muda as contas para a maioria das equipas, e o exato inverso do que acontece com o Mattermost: o plano Free em self-managed não tem limite de utilizadores. O limite de cinco utilizadores de que se ouve falar aplica-se apenas a grupos privados no GitLab.com. O Free alojado por si dá-lhe utilizadores ilimitados, controlo de versões, CI/CD e registos, e o armazenamento e os runners ficam por sua conta. Uma organização com cem engenheiros pode funcionar inteiramente com ele.

O que perde é a análise de segurança, os relatórios de conformidade, as regras de aprovação avançadas e o suporte. Se estiver abrangido pelo Regulamento de Ciber-Resiliência e quiser a análise de dependências e a geração de SBOM integradas nos seus pipelines, em vez de montadas a partir de ferramentas separadas, a conversa passa a ser sobre o Ultimate. Para a maioria das outras equipas, o Free não é um período experimental. É uma solução definitiva perfeitamente viável.

A instalação

Uma implementação pequena

O GitLab é mais pesado do que parece. A base documentada para um único nó é de 8 vCPU e 16 GB de RAM e, ao contrário da maioria dos mínimos indicados pelos fornecedores, esse número é honesto e não otimista. É possível espremê-lo em 8 GB, mas vai notar a diferença, e a swap deve estar desligada, porque pôr esta aplicação a usar swap é pior do que não ter a memória.

O PostgreSQL é a única base de dados suportada. A versão depende da versão do GitLab: a 17.x pede PostgreSQL 14.14 a 16.x, a 18.x pede 16.5 a 17.x e a 19.x pede 17.x a 18.x. Recomenda-se o Redis 7.2, sendo o 7.0 o mínimo, e o Valkey 7.2 funciona como substituto. Apenas instâncias autónomas: as variantes de Redis em cluster e serverless não são suportadas.

Instale com o pacote Linux. Há charts Helm, um Operator, imagens Docker e a via da compilação a partir do código-fonte, mas o pacote Linux é a opção mais madura e é nele que corre o próprio GitLab.com. Traz PostgreSQL, Redis e Sidekiq incluídos, o que significa que uma máquina e um ficheiro de configuração chegam para ter uma instância a funcionar.

# /etc/gitlab/gitlab.rb
external_url 'https://git.example.com'

# Let's Encrypt, on by default when external_url is https
letsencrypt['enable'] = true
letsencrypt['contact_emails'] = ['ops@example.com']

# Keep Puma and Sidekiq honest on a small box
puma['worker_processes'] = 2
sidekiq['max_concurrency'] = 9

# Move artefacts and uploads off local disk early
gitlab_rails['object_store']['enabled'] = true
gitlab_rails['object_store']['connection'] = {
  'provider' => 'AWS',
  'region' => 'eu-central-1',
  'aws_access_key_id' => 'REPLACE_ME',
  'aws_secret_access_key' => 'REPLACE_ME'
}

Execute gitlab-ctl reconfigure e tem uma instância. Defina o external_url corretamente à primeira, porque acaba gravado nos URL de clonagem, nos webhooks e nos endereços do registo.

Uma implementação de produção

O GitLab publica arquiteturas de referência de 1000 a 50 000 utilizadores, e vale a pena lê-las mesmo que nunca implemente nenhuma, porque mostram que componente se torna primeiro o ponto de estrangulamento.

O conselho que mais dinheiro poupa é do próprio GitLab, e vai contra a complexidade: abaixo dos 3000 utilizadores, recomenda uma estratégia de cópias de segurança sólida em vez de alta disponibilidade. A documentação é invulgarmente franca neste ponto, ao notar que uma abordagem baseada em cópias de segurança «does have a slower recovery time» (tem um tempo de recuperação mais lento), mas «means you have a much smaller architecture and less maintenance costs» (significa uma arquitetura muito mais pequena e menos custos de manutenção). Acima dos 3000 utilizadores, ou quando uma indisponibilidade faz realmente parar a empresa, a recomendação passa a ser a alta disponibilidade.

Leve isto a sério. Um único nó com boas cópias de segurança e uma reposição testada é, na prática, mais fiável do que um cluster de alta disponibilidade mal compreendido, e muito mais barato.

Passe os artefactos, os uploads, os objetos LFS e as imagens do registo para armazenamento de objetos desde o início. O raciocínio é o mesmo de sempre: mantém o nó sem estado, as cópias de segurança geríveis e a migração possível.

As três coisas que correm mal

Tudo o que ficou dito acima está na documentação. Estas são as que provocam incidentes.

A sua cópia de segurança não contém aquilo que a decifra

Este é o parágrafo mais importante de todo o artigo.

O gitlab-backup create guarda muita coisa: a base de dados, os repositórios, os objetos LFS, os artefactos de CI e os registos dos jobs, as imagens do registo, as wikis, os uploads, o conteúdo das Pages, o estado do Terraform, os snippets. O que não guarda é o diretório de configuração e, em concreto, o /etc/gitlab/gitlab-secrets.json.

Esse ficheiro contém a chave de cifragem da base de dados. A documentação não deixa margem para dúvidas quanto à consequência: «If you lose it, then the GitLab application will not be able to decrypt any encrypted values in the database» (se o perder, a aplicação GitLab não conseguirá decifrar nenhum valor cifrado na base de dados). Isso inclui variáveis de CI/CD, tokens, segredos de autenticação de dois fatores e credenciais de integrações. Fica com uma cópia de segurança que se repõe numa instância incapaz de ler os seus próprios segredos.

Também ficam de fora: o /etc/gitlab/gitlab.rb, as chaves e os certificados TLS, as chaves de anfitrião SSH e o conteúdo do armazenamento de objetos, quando este está configurado. Este último apanha quem fez a coisa certa do ponto de vista da arquitetura e depois assumiu que a cópia de segurança o abrangia.

Faça, portanto, uma cópia de segurança separada do /etc/gitlab e guarde-a num sítio diferente do arquivo, já que é a chave desse arquivo. Depois, reponha tudo numa máquina descartável e confirme que consegue iniciar sessão e ler uma variável de CI. Uma reposição não testada não é uma cópia de segurança e, no caso do GitLab, uma reposição não testada costuma ser uma reposição que não funciona.

Não é possível atualizar de uma só vez

O GitLab tem paragens de atualização obrigatórias, e isto não é uma recomendação. Não as pode saltar. Desde a 17.5, as paragens são previsíveis e caem em x.2, x.5, x.8 e x.11; atualizar da 18.0 para a 19.2 obriga, portanto, a parar primeiro na 18.2, na 18.5, na 18.8 e na 18.11. A 19.0 não é uma paragem, por isso da 18.11 passa diretamente para a 19.2.

Cada paragem envolve migrações em segundo plano que têm de terminar por completo antes de avançar para a seguinte. Começar a atualização seguinte com migrações ainda em curso é a forma de deixar uma instância num estado que só o suporte consegue desfazer. Numa instância grande, essas migrações podem demorar horas.

Daqui resultam duas consequências práticas. Atualize com regularidade, porque um ano de atualizações adiadas é um fim de semana de atualizações em série. E instale sempre a versão de correção mais recente da versão menor de destino, e não a primeira, o que a documentação diz de forma explícita. O GitLab mantém uma ferramenta de caminho de atualização que calcula a sequência por si, e vale mais usá-la do que tentar deduzi-la à mão.

O verdadeiro custo está nos runners

O servidor GitLab não executa a sua CI. O GitLab Runner é um componente à parte que instala, configura e paga, em infraestrutura fornecida por si. O Free em self-managed não inclui quaisquer minutos de computação, porque não há computação incluída para dar: as máquinas são suas.

Normalmente é um bom negócio, já que um runner dedicado sai mais barato por minuto do que a CI alojada a partir de qualquer volume sério, e pode associar-lhe o hardware que cada build exigir. Mas é trabalho de infraestrutura a sério. Vai ter de decidir sobre executores (shell, Docker ou Kubernetes), sobre escalamento automático, para que os runners não fiquem parados às três da manhã, e sobre cache, que é a diferença entre um pipeline de quatro minutos e um de catorze.

Orçamente a frota de runners como uma rubrica própria. As equipas que calculam o custo do alojamento próprio a olhar apenas para o nó do GitLab subestimam-no por larga margem e depois descobrem a diferença sob a forma de uma fila de jobs pendentes.

Migrar do GitHub

O importador do GitHub é bom, bastante melhor do que a maioria das ferramentas de migração dos fornecedores, e traz os dados dos repositórios, os ramos, os objetos LFS, as issues e os pull requests com os respetivos comentários, revisões e respostas nas discussões, as páginas de wiki, as releases e os anexos, as etiquetas, os marcos, as regras de proteção de ramos e os colaboradores, com mapeamento de funções.

As lacunas documentadas merecem planeamento. As organizações e os grupos não são migrados, por isso a estrutura de grupos fica para desenhar de raiz em vez de ser herdada, o que costuma ser uma melhoria. Os workflows do GitHub Actions não são convertidos para GitLab CI. Os comentários em pull requests anteriores a 2017 são importados como threads separadas devido a limitações da API do GitHub, e os repositórios com mais de cerca de 30 000 comentários precisam que o método alternativo de importação de comentários esteja ativo.

Como o GitHub usa # tanto para issues como para pull requests, e o GitLab os distingue, algumas referências cruzadas não vão funcionar. Nada se perde, mas as ligações em discussões antigas podem apontar para o sítio errado.

Encare a reescrita da CI como o verdadeiro projeto, porque é isso que ela é. O resto é uma importação que pode executar e verificar.

A perspetiva europeia

Para as empresas que operam na Europa, há uma dimensão de conformidade que vai além do custo. O código-fonte, os pipelines de build e os artefactos estão entre o que de mais sensível uma empresa de tecnologia possui, e o sítio onde estão é cada vez mais uma pergunta que lhe fazem, e não uma questão a que escolhe responder.

O alojamento próprio coloca-os dentro de um perímetro que controla, o que simplifica de uma assentada a análise de transferências ao abrigo do RGPD e as questões de cadeia de abastecimento da Diretiva NIS 2, e é o mesmo argumento de soberania em torno do qual foi construído o Cloud and AI Development Act.

A ligação mais direta é com o Regulamento de Ciber-Resiliência. Se coloca software no mercado da UE, vai precisar de inventários de dependências, de tratamento de vulnerabilidades e de um processo de divulgação coordenada. Estas obrigações cumprem-se no pipeline de build e não num documento, e ter o pipeline, o registo e a análise num único sistema gerido por si torna a produção das provas muito menos penosa do que juntá-las a partir de quatro fornecedores.

Quando não vale a pena

Se tem menos de vinte engenheiros, nenhuma pressão regulatória e nenhuma preferência forte quanto ao sítio onde o código está, use o SaaS. O GitLab.com e o GitHub são ambos excelentes, e o trabalho operacional vai custar mais do que a subscrição.

Se a sua organização está muito embrenhada no ecossistema do GitHub, faça as contas com honestidade ao que perderia. O Actions, o marketplace e o simples facto de a plataforma ser familiar a qualquer candidato que contrate são ativos reais, e a resposta não é automaticamente que o GitLab ganha.

E se ninguém vai ficar responsável pela instância, não comece. O GitLab recompensa um responsável que aplica as atualizações, vigia a frota de runners e testa a reposição. Sem essa pessoa, degrada-se numa máquina desatualizada que guarda o seu ativo mais valioso, o que é pior do que o SaaS que estava a tentar deixar.

Ajuda

Implementamos e operamos infraestrutura de desenvolvimento alojada pelo próprio cliente para empresas que trabalham na Europa, incluindo as partes de que ninguém gosta: sequências de atualização com paragens obrigatórias, frotas de runners com escalamento automático bem feito, migrações para armazenamento de objetos e esquemas de cópias de segurança que já foram efetivamente repostos.

Se quer uma instância GitLab dimensionada com honestidade, uma migração do GitHub planeada por quem já reescreveu a CI antes, ou uma análise sobre se a sua cópia de segurança atual sobreviveria a uma falha real, escreva para office@c9group.dev. Saiba mais sobre o nosso trabalho de infraestrutura na página de otimização de custos AWS.

Se está a montar uma stack completa alojada por si, o mesmo raciocínio aplica-se à análise de tráfego, à automação de marketing e às mensagens de equipa.

---

Publicado: 8 de agosto de 2026 · Atualizado: 10 de outubro de 2026 Categorias: DevOps, Open Source, Privacidade