GitLab vs. GitHub: qual a nossa pequena equipe deve usar?

Na semana em que você contratar o sexto desenvolvedor, o grupo privado de nível superior que guarda seu código no GitLab.com Free passa de cinco usuários. A documentação do limite de usuários gratuitos do GitLab diz que o grupo então fica somente leitura. No GitHub Free para organizações, o novo contratado entra sem problemas, já que os colaboradores são ilimitados, mas você vai esbarrar em outro limite na primeira vez que quiser proteger o main. Os repositórios privados do GitHub Free não podem usar branches protegidos nem proprietários de código.

Os planos pagos que você compararia em seguida são o GitHub Team, anunciado a US$ 4 por usuário/mês for the first 12 months, e o GitLab Premium, a US$ 29 por usuário/mês com cobrança anual. Há também uma opção sem nenhuma taxa de licença, o GitLab Community Edition. O CE roda em servidores que você controla, um para o GitLab e outro para o runner que executa seus jobs de CI, e a tabela abaixo dá a ele uma coluna própria.

Como os planos se comparam em um repositório privado

Todas as linhas abaixo consideram um repositório privado de equipe. As informações dos planos vêm da página de preços ou da documentação de cada fornecedor.

Planos e preços conforme listados em github.com/pricing e about.gitlab.com/pricing em 28 de setembro de 2026, sem alterações quando consultamos as duas páginas de novo em 21 de outubro. A página do GitHub não informa quanto o Team custa depois dos primeiros 12 meses. A linha de armazenamento não compara itens equivalentes: a franquia do GitHub cobre pacotes e artefatos do Actions, e a do GitLab cobre o armazenamento de repositório Git e LFS em cada projeto.

Se sua equipe quer que alguém aprove antes que um deploy chegue à produção, leia a linha de deploy antes da linha de preço. No GitHub Free, Pro e Team, revisores obrigatórios para ambientes de deploy só funcionam em repositórios públicos, o que coloca essa trava um nível acima da revisão obrigatória de merge para quem tem código privado. O GitLab coloca as duas no Premium, onde ambientes protegidos definem quem pode fazer deploy e quem precisa aprovar. Se seu código é público, a maioria dessas diferenças desaparece no GitHub: branches protegidos e revisores de deploy funcionam em repositórios públicos sem plano pago.

Qual combina com a sua equipe

Na nossa avaliação, o GitHub é mais difícil de deixar quando seus pipelines dependem do Actions, já que migrar significa adaptar ao GitLab CI os workflows do Marketplace que você usa.

O que o GitLab CE deixa de fora e o que ele mantém

No CE, um dos seus líderes técnicos pode fazer merge de uma solicitação que ninguém revisou, e o GitLab não vai impedir. As aprovações no nível gratuito, que é o conjunto de recursos que o CE roda, “são opcionais e não impedem o merge sem aprovação”. Tudo na lista What needs Premium abaixo aparece com o selo Premium na documentação do GitLab.

Se a revisão acontece antes continua dependendo dos seus Maintainers. Se um contrato com cliente ou uma auditoria de conformidade exige que nenhuma mudança vá ao ar sem uma segunda aprovação, o CE não consegue garantir isso, e as regras de aprovação do Premium conseguem.

Você não precisa migrar para tê-los. A documentação de conversão do GitLab orienta instalar o pacote Enterprise Edition (EE) por cima do CE e depois adicionar uma licença. Até você adicioná-la, o EE roda os mesmos recursos Free sem custo. Os recursos do Premium são liberados quando você ativa uma licença paga.

O que é preciso para rodá-lo por conta própria

Um administrador de CE no GitLab Forum, que mantém uma instância com cerca de 40 usuários cadastrados, cerca de cinco deles ativos, cuida da rotina toda segunda-feira:

Seu plano precisa de um pouco mais:

• Aplicar as atualizações do GitLab em um cronograma fixo, em um horário tranquilo. Depois de uma inicialização a frio, nossa instância de teste levou cerca de 2 minutos até a página de login responder
• Fazer backup em algum lugar fora do servidor e restaurar uma cópia de vez em quando para provar que funciona. O backup do GitLab deixa de fora gitlab.rb e gitlab-secrets.json, e a documentação de backup manda copiar os dois por conta própria
• Atualizar também o GitLab Runner no servidor dele
• Definir uma segunda pessoa que consiga fazer tudo isso quando a primeira estiver ausente

Veja quanto um ano de assentos custa a preço de tabela, antes de contar qualquer gasto com servidores:

Isso é US$ 29 e US$ 4 por usuário por mês, vezes 12. Nosso guia sobre custos por usuário do GitLab e do GitHub comparados a um servidor GitLab CE calcula a conta completa, com servidores. Com a mediana salarial de 2025 nos EUA para desenvolvedores de software, analistas de QA e testadores, de US$ 64,44 por hora, segundo o Bureau of Labor Statistics, 10 assentos Premium custam por ano quase o mesmo que 54 horas do tempo de um desenvolvedor, e 10 assentos do GitHub Team, cerca de 7 horas.

Para comparar essas horas com o custo dos assentos na sua equipe, pegue um ano de assentos Premium, subtraia o custo dos dois servidores e divida pelo seu próprio custo por hora. O resultado é quantas horas de manutenção por ano você poderia gastar antes que o CE custe mais que o Premium. Essa conta considera só o custo, já que o CE não exige aprovações como o Premium. Se o GitHub Team é sua outra opção, faça a mesma conta com o preço de US$ 4 por assento. Nesse preço, os assentos demoram muito mais para somar o custo de dois servidores e da manutenção deles.

Na GitLab VPS da DreamHost, a DreamHost dá suporte 24/7 ao hardware, à rede e à conectividade, e a página do produto diz que você mesmo cuida das atualizações de software e da configuração. Os backups também ficam por sua conta, como diz a lista acima.

Quanto servidor o GitLab precisa

A página de requisitos do GitLab define 8 vCPU e 16 GB de memória como base para uma instalação de nó único. Os planos de GitLab VPS da DreamHost incluem o Stack 16 (4 vCPU, 16 GB) e o Stack 32 (8 vCPU, 32 GB). O Stack 32 é o primeiro plano que atende a essa base. O Stack 16 atinge os 16 GB, mas tem metade das 8 vCPU, então fica abaixo da base, e os planos menores ficam ainda mais abaixo. O guia para memória limitada do GitLab vai bem mais baixo, para até cinco desenvolvedores. Nenhuma das páginas menciona uma equipe de 10 ou 20 pessoas.

Esses números são para o próprio GitLab. Os jobs de CI ficam em outro lugar: a página de instalação do runner do GitLab diz para instalar o GitLab Runner em uma máquina separada da que hospeda sua instância do GitLab. O GitLab não publica um tamanho para essa máquina. A página de requisitos do runner diz que isso depende de quanta CPU e memória seus jobs usam, quantos rodam ao mesmo tempo e quantas pessoas trabalham em paralelo. Nossa estimativa o coloca no Stack 8, com 2 vCPU e 8 GB, o mesmo do runner hospedado padrão do GitLab.com.

Páginas de requisitos do GitLab consultadas em 28 de setembro de 2026, e páginas do runner em 20 de outubro de 2026. As especificações dos planos Stack vêm da página de GitLab VPS da DreamHost.

A documentação do GitLab não diz em que ponto 4 vCPU deixam de ser suficientes para uma equipe do seu tamanho, e nós também não medimos isso, então o teste abaixo roda o GitLab no Stack 16 e o acompanha enquanto os pipelines rodam. Se os jobs ficarem na fila durante o teste, verifique a configuração de concorrência do runner e o uso de CPU nos dois servidores antes de culpar o plano. Um servidor GitLab com a CPU perto do máximo enquanto os pipelines rodam é o sinal de que você encontrou o limite, e o Stack 32 atende aos dois números-base da página de requisitos. O disco cresce com seus repositórios, imagens de contêiner e artefatos de CI, então confira o espaço usado no fim do teste e projete o crescimento.

O que o GitLab CE usou na nossa VM de teste

As páginas de dimensionamento do GitLab dão uma base para uso real e um piso para pouca memória, mas nenhuma medição do que uma instalação vazia realmente usa. Então rodamos a imagem oficial do GitLab CE 19.5.0 em uma VM de teste com 2 vCPU e 8 GB, mais ou menos o tamanho do servidor de runner acima, e medimos a memória 10 minutos depois que ela estabilizou. Depois rodamos três pipelines de um pequeno projeto Node.js, com o GitLab Runner na mesma VM.

Nos números de CPU, 100% equivale a uma vCPU, então o job e o GitLab juntos precisaram de mais do que as duas da VM. Essas execuções não tiveram usuários e só um projeto pequeno, então não servem para definir um tamanho de equipe. Mas mostram a memória do GitLab em repouso em cerca de 4.285 MiB com as configurações padrão e cerca de 2.657 MiB com as de pouca memória, cerca de um quarto dos 16 GB do Stack 16 ou menos, o que deixa as 4 vCPU como o número a acompanhar. Então, durante o teste, acompanhe a CPU nos dois servidores enquanto seus próprios pipelines rodam.

Como testar o CE por um sprint

Espelhe seu código no servidor de teste e deixe o original onde está. Assim, se o teste não der certo, não há nada para trazer de volta.

1. Copie um repositório real

   Escolha um repositório com um pipeline funcionando e o histórico real, para que o teste reflita o tamanho e os tempos de build reais do seu projeto. O importador de GitHub do GitLab traz o repositório, as issues e os pull requests.

2. Defina a regra de merge

   Proteja main com Allowed to merge definido como Maintainers e Allowed to push and merge definido como No one. Depois, veja se seus líderes técnicos se sentem à vontade com aprovações que o GitLab não impõe.

3. Rode uma semana normal de CI

   Registre um runner em um segundo servidor, um Stack 8, e execute seus pipelines de sempre. Se forem workflows do GitHub Actions, reescreva-os para o GitLab CI primeiro e conte essas horas no teste. Anote quanto tempo os jobs esperam enquanto as pessoas usam o aplicativo web.

4. Teste uma restauração e uma atualização

   Restaure um backup, junto com suas cópias de gitlab.rb e gitlab-secrets.json, em um servidor reserva e descartável. Depois, aplique uma atualização do GitLab. Anote quanto tempo cada etapa levou e tudo o que você precisou corrigir manualmente. Não cronometramos uma atualização na nossa VM de teste, então é desta etapa que sai a sua estimativa de manutenção.

Antes de o sprint começar, defina por escrito seu critério de aprovação: quanto tempo um build pode esperar e quantas horas de manutenção por mês você aceita.

Como testamos o GitLab CE

Os números do GitLab nesta página foram medidos pela DreamHost em uma VM de teste (arm64), não em um servidor da DreamHost, em 20 de outubro de 2026. É o mesmo teste por trás do nosso guia sobre custos por usuário do GitLab e do GitHub, que traz a configuração completa e as leituras em repouso com mais detalhes. Nossos planos usam processadores x86 AMD EPYC, então espere pequenas diferenças em um servidor real. Resumindo: a imagem oficial do CE 19.5.0 em uma máquina com 2 vCPU e 8 GB de memória (7.922 MiB, segundo o Linux), uma vez com as configurações padrão e outra com as configurações para memória limitada do GitLab. Para os pipelines, o GitLab Runner ficou na mesma máquina e executou três vezes os jobs de teste e build do projeto open source Express, enquanto líamos a memória e a CPU a cada 3 segundos.

O que não testamos: a carga de uma equipe real, um repositório grande, vários pipelines ao mesmo tempo, um runner em um segundo servidor, as 4 vCPU do Stack 16 ou as 8 do Stack 32 e o tempo de inatividade durante uma atualização. Cada configuração foi executada uma vez. Os dados e preços dos planos vêm das próprias páginas do GitHub e do GitLab, nas datas indicadas nas fontes.

Perguntas frequentes sobre GitLab ou GitHub