Como Auto-Hospedar GitLab CE em um VPS

É uma tarde de sexta-feira, o pedido de pull da tua equipe está em análise, e o teu laptop emite um sinal com uma mensagem familiar: o GitHub está com problemas novamente.

Talvez as ações estejam travadas.

Talvez `git push` retorne um erro 500 pela terceira vez este mês.

O tópico no teu chat de equipe já tem oito mensagens.

A primeira vez que isso acontece, você ri disso. A segunda vez, alguém compartilha o GitHub status page, e todos vocês vão tomar um café. A terceira vez, geralmente logo antes de uma janela de lançamento, alguém finalmente digita a pergunta em voz alta: “Devemos simplesmente gerenciar o nosso próprio?”

Para a maioria das equipes, a resposta honesta é não. O GitLab.com Free cobre pequenas equipes confortavelmente, e o imposto operacional de executar seu próprio servidor de controle de versão não é zero.

É o tipo de negociação que você só faz por um motivo real.

Se sua equipe tem um desses motivos, como um contrato com o cliente que proíbe SaaS de terceiros, um limite de conformidade ou uma conta de licença de usuário que está começando a parecer ridícula, auto-hospedar o GitLab CE é a mudança mais limpa que você pode fazer. É de código aberto, funciona em um único VPS e, uma vez ajustado, a manutenção leva cerca de uma hora por mês.

Na DreamHost, nós hospedamos inúmeros servidores auto-gerenciados, e continuamos vendo um padrão: desenvolvedores que têm sucesso com o GitLab auto-hospedado escolhem o plano certo desde o início, acertam na preparação do Protocolo de Shell Seguro (SSH) e do Sistema de Nomes de Domínio (DNS), e depois resistem à tentação de continuar mexendo uma vez que está estável.

Por Que Você Deveria Hospedar o GitLab por Conta Própria em Vez de Usar o GitLab.com?

Você hospeda o GitLab por conta própria quando GitLab.com ou GitHub.com não conseguem atender às suas necessidades de privacidade, conformidade ou controle de custos. Para a maioria das outras equipes, a opção hospedada é uma troca melhor.

Três razões reais resistem ao escrutínio:

1. Privacidade e soberania de dados: Teu código-fonte reside em infraestrutura que você gerencia e atualiza conforme teu próprio cronograma. Sem acesso de terceiros, sem plataforma compartilhada, sem raio de explosão de violação além do teu próprio servidor.
2. Conformidade: Indústrias reguladas como saúde, finanças e governo muitas vezes precisam de controle de residência de dados. O GitLab CE auto-hospedado é a maneira mais simples de manter o código dentro de um limite controlado. 
3. Controle de custos em escala: GitLab.com cobra por usuário ativo. De acordo com a página de preços do GitLab, o Premium custa $29 por usuário por mês, enquanto o preço do Ultimate está disponível apenas sob consulta. Uma equipe de 50 pessoas no Premium custa $17,400 por ano antes de complementos. Um VPS auto-gerenciado mais uma hora de manutenção mensal muitas vezes custa menos.

Se vocês são uma equipe de duas pessoas sem razões de privacidade ou conformidade, a resposta certa é o plano gratuito do GitLab. (Sim, nós sabemos que isso soa engraçado vindo de uma empresa de hospedagem).

Com a auto-hospedagem, você está trocando uma conta mensal de SaaS por tempo operacional contínuo. Isso só vale a pena se você tiver um bom motivo para fazer a troca.

Aqui está onde esta opção faz sentido e onde não faz:

Cenário	Melhor opção
Requisito de privacidade ou conformidade	GitLab CE auto-hospedado
Equipe maior que ~30 usuários ativos	Auto-hospedado geralmente é mais barato
O código é sua propriedade intelectual, e você quer mantê-lo local	GitLab CE auto-hospedado
Equipe de 2-5 pessoas, sem necessidades de conformidade	GitLab.com (gratuito)
Você não quer atualizar um servidor	GitLab.com

A Edição Comunitária do GitLab é gratuita sob uma licença de código aberto estilo MIT. Não há limite de usuários, nenhuma restrição de funcionalidades básicas e nenhum incentivo para compra de planos superiores. Toda a plataforma é sua para gerenciar.

Quais São os Requisitos de Hardware para o GitLab CE?

GitLab CE possui limites claros de hardware, e acertá-los é a diferença entre uma instalação rápida e uma que se arrasta através da memória swap (espaço em disco que seu sistema operacional usa quando a RAM se esgota).

De acordo com os requisitos oficiais de instalação do GitLab, o dimensionamento é expresso em solicitações por segundo ao invés de camadas fixas por usuário. A linha de base publicada é de 8 vCPU e 16 GB de RAM para até 1.000 usuários (cerca de 20 solicitações por segundo). Equipes menores podem funcionar com menos, até um piso documentado de 2 GB de RAM mais 1 GB de swap para avaliação, embora o desempenho seja prejudicado abaixo de 4 GB.

Uma instalação nova do GitLab consome cerca de 4-6 GB em repouso. Uma vez que os trabalhos de CI/CD começam a ser executados, o uso de memória aumenta rapidamente. Portanto, planeje ter uma margem — ou prepare-se para a lentidão.

Quanto ao armazenamento, a linha de base oficial do GitLab é 40 GB mais o tamanho do repositório, mas 50 GB é um ponto de partida mais seguro na prática. Os repositórios crescem e os artefatos de construção se acumulam. NVMe, um tipo mais rápido de armazenamento em estado sólido, faz uma diferença notável nas operações de Git e na leitura de cache de CI.

Aqui está como esses limites se aplicam aos níveis de VPS hosting da DreamHost:

Caso De Uso	RAM Recomendada	Nível DreamHost VPS
Avaliação / pessoal	4 GB RAM	Stack 4
Equipe pequena, uso leve	8 GB RAM	Stack 8
Até ~1.000 usuários (linha de base publicada pelo GitLab)	16 GB RAM	Stack 16
Executando runners CI/CD na mesma caixa	+ 2-8 GB RAM além do seu nível	Aumente o tamanho (por exemplo, Stack 16 → Stack 32)

O ponto de partida certo para a maioria das equipes que executam pipelines reais de CI/CD é o Stack 16. Isso parece exagero até você ver a primeira construção iniciar e o Sidekiq, Postgres e um executor dispararem ao mesmo tempo.

16 GB de RAM oferecem espaço suficiente para a pilha de serviços do GitLab (aproximadamente 4 a 6 GB em repouso numa instalação padrão) e um par de trabalhadores de CI (1-2 GB cada) para funcionar simultaneamente sem que ninguém no chat da equipe perceba.

Como Você Prepara Seu VPS Antes de Instalar o GitLab?

Gaste 10 minutos na preparação — vale a pena na primeira vez que você reiniciar. Basta seguir estes passos:

1. Provisionar o VPS: Escolha Ubuntu 22.04 LTS ou 24.04 LTS. Ambos são suportados pelos pacotes Omnibus oficiais do GitLab (o instalador tudo-em-um que o GitLab fornece) e têm anos de atualizações de segurança gratuitas pela frente.
   
2. Apontar um domínio para o IP do servidor: Crie um registro A (o tipo de registro DNS que mapeia um domínio para um endereço IP) e deixe-o propagar por pelo menos 15-30 minutos antes de instalar. Sem isso, a configuração automática de SSL falhará porque a autoridade de certificação não terá onde validar.
   
3. Atualizar pacotes: Conecte-se ao VPS usando `ssh root@your-server-ip` e execute `sudo apt update && sudo apt upgrade -y`.
   
4. Instalar dependências: Execute `sudo apt install -y curl openssh-server ca-certificates perl postfix`. O pacote `postfix` é um servidor de email que lida com o envio de emails, permitindo que o GitLab envie notificações de merge-request e redefinições de senha.
   Quando o instalador perguntar sobre a configuração de email, escolha Internet Site e use seu domínio. Isso permite que o GitLab envie emails imediatamente.
   Para produção: pule o postfix local e configure um relay SMTP em gitlab.rb em vez disso. IPs de VPS frequentemente estão em listas de bloqueio de spam, e emails de redefinição de senha enviados através do postfix local muitas vezes acabam no spam. SendGrid, Mailgun e o relay de saída da DreamHost funcionam — consulte a documentação de configuração SMTP do GitLab.
   
5. Abrir as portas corretas: Configure um firewall usando UFW (a ferramenta de firewall integrada do Ubuntu) e permita as portas 80, 443 e 22.

sudo ufw allow http
sudo ufw allow https
sudo ufw allow ssh
sudo ufw enable

Como Instalar o GitLab CE em Ubuntu Usando o Pacote Omnibus?

Adicione o repositório GitLab CE:

curl -sSL https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh | sudo bash

Em seguida, instale o GitLab CE com seu domínio configurado como a URL externa:

sudo EXTERNAL_URL="https://gitlab.example.com" apt install gitlab-ce

Configurar `https://` aqui instrui o GitLab a solicitar automaticamente um certificado Let’s Encrypt durante a instalação, desde que as portas 80 e 443 estejam abertas e o DNS esteja corretamente configurado. Se alguma dessas condições não estiver pronta, a instalação é concluída, mas o SSL falha — e você gasta os próximos trinta minutos solucionando um problema que na verdade não está quebrado.

A seguir, aguarde o passo de reconfiguração.

O GitLab executa `gitlab-ctl reconfigure` (o comando que aplica quaisquer alterações na configuração do GitLab) automaticamente ao final da instalação. Leva de cinco a 10 minutos. E sim, o passo de reconfiguração realmente leva todo esse tempo.

Obtenha a senha inicial do root:

sudo cat /etc/gitlab/initial_root_password

Este arquivo é gerado automaticamente e será excluído em 24 horas, então pegue a senha e faça login. Visite seu domínio em um navegador, entre como `root` e troque a senha imediatamente.

Por fim, verifique a instalação.

Na tela de boas-vindas do GitLab, crie um projeto de teste. Faça um commit para ele a partir do seu computador local. Se o push for bem-sucedido e o arquivo aparecer na interface web, a instalação está saudável.

Se o passo de reconfiguração travar, verifique `tail -f /var/log/gitlab/reconfigure/*.log`. É lá que o erro real se encontra.

Como Você Bloqueia uma Instância do GitLab Auto-Hospedada?

O GitLab vem com configurações padrões razoáveis, mas elas são ajustadas para um servidor comunitário aberto, não para a instância privada da sua equipe. Dedique uma hora aqui.

1. Desative O Registro Aberto. O registro aberto está ativado por padrão. Na Área de Administração, navegue até Configurações > Geral > Restrições de registro e desmarque a caixa “Registro habilitado”. Caso contrário, qualquer pessoa com a URL pode criar uma conta.
2. Habilite A Autenticação Em Dois Fatores. Vá para Área de Administração > Configurações > Geral > Restrições de login e imponha o 2FA para todos os usuários. Reduza o período de carência do padrão de 48 horas para 8 horas.
3. Restrinja A Criação De Projetos. Defina Criação de Projeto Padrão para Mantenedores ou Ninguém, dependendo do nível de restrição desejado.
4. Verifique A Renovação Do SSL. O GitLab renova automaticamente os certificados do Let’s Encrypt por padrão. Para confirmar, execute `sudo gitlab-ctl renew-le-certs` uma vez e verifique a saída.
5. Proteja O SSH No Próprio VPS. Desative o login com senha do root, permita apenas a autenticação com chave SSH e (se possível) mova o SSH para fora da porta 22. Um servidor Git auto-hospedado é tão seguro quanto a máquina abaixo dele.

Para uma versão mais detalhada, o GitLab publicou um Guia de Fortalecimento que abrange autenticação, criptografia e configurações de instância. Leia-o uma vez, aplique o que corresponder ao seu modelo de ameaça e siga em frente.

Como Você Faz Backup e Restaura Uma Instância do GitLab Auto-hospedada?

GitLab inclui uma ferramenta de backup integrada. A primeira vez que precisar dela, ficará feliz por tê-la configurado.

Crie um backup:

sudo gitlab-backup create

Isso coloca um tarball em `/var/opt/gitlab/backups`. Programe isso diariamente via Cron Job com uma janela de retenção de sete dias. Execute sudo crontab -e e adicione estas duas linhas:

0 2 * * * /opt/gitlab/bin/gitlab-backup create CRON=1
0 3 * * * find /var/opt/gitlab/backups -name "*.tar" -mtime +7 -delete

A flag CRON=1 suprime a saída de progresso para que não encha os registros do Cron Job de spam.

Dica profissional: o backup de dados não inclui `/etc/gitlab/gitlab-secrets.json` ou `/etc/gitlab/gitlab.rb`.

Esses arquivos contêm a chave de criptografia do banco de dados, sementes de autenticação de dois fatores e variáveis de CI/CD. Os segredos de configuração não fazem parte do backup regular e devem ser salvos separadamente. Restaurar dados sem o arquivo de segredos resulta em quebras de contas de dois fatores, variáveis criptografadas se tornam inúteis, e você passa uma longa noite tentando descobrir o porquê.

Adicione isto ao mesmo Cron Job:

sudo cp /etc/gitlab/gitlab-secrets.json /etc/gitlab/gitlab.rb /var/opt/gitlab/backups/

Um backup só pode ser restaurado para a mesma versão e edição (de CE para CE, não de CE para EE) do GitLab na qual foi criado.

Atualize com cuidado: não restaure um backup antigo em um GitLab recém-instalado sem antes alterar o plano de instalação para combinar.

Teste o processo de restauração pelo menos uma vez. Um backup que você nunca testou é apenas um arquivo.

Vale a Pena Hospedar o GitLab por Conta Própria para a Sua Equipe?

Autogerenciamento do GitLab é uma decisão de controle para a maioria das equipes. A matemática de custo às vezes compensa, mas o motivo pelo qual as pessoas continuam com o autogerenciamento raramente é o item de linha.

Aqui está o custo mensal honesto para uma instalação de pequena equipe:

• ~30 minutos de atualização – atualizações apt, versões menores do GitLab
• ~15 minutos de verificação de backup – não confie em um backup que você não restaurou
• ~15 minutos de verificação de capacidade – uso do disco, espaço livre em RAM
• ~2x se CI/CD é executado na máquina – Um executor ocupado pode dobrar a carga

Isso é cerca de uma hora por mês em uma semana lenta, ou duas em uma semana movimentada.

Aproximadamente $150 por hora, 12 horas de tempo operacional custam cerca de $1,800 — aproximadamente cinco assentos GitLab.com Premium.

Um estudo de caso do praticante de Mad Devs descreve como a equipe economiza mais de $10,000 por ano ao executar o GitLab CE auto-hospedado em vez de pagar por assentos Premium. A economia só se materializa quando a equipe é grande o suficiente para que as licenças de assento dominem o orçamento.

Dito isso, a auto-hospedagem é a escolha errada para:

• Equipes De Duas A Três Pessoas Sem Motivos De Conformidade. O GitLab.com Free cobre você. O tempo operacional é maior que o custo economizado.
• Equipes Sem Ninguém Confortável Na Linha De Comando. “Confortável” não significa nível de sysadmin. Significa que você pode ler os erros de `/var/log/gitlab` sem pânico.
• Equipes Cujo Maior Impedimento É Contratação, Não Ferramentas. A auto-hospedagem desvia a atenção do produto. Se a velocidade do produto é a restrição, hospedado é a escolha certa.

Então, quando faz sentido a auto-hospedagem? Abaixo estão alguns cenários:

• Indústrias reguladas com requisitos explícitos de residência de dados ou cadeia de custódia
• Equipes da UE/Reino Unido com preocupações de soberania sobre códigos hospedados nos EUA
• Equipes de 30+ onde as licenças de assento dominam o orçamento
• Contratos com clientes que proíbem o uso de SaaS de terceiros para código-fonte

Se o seu motivo é “o GitHub cobra por assento,” provavelmente você sairá na frente. Se o seu motivo é “quero me sentir no controle,” você pode achar a realidade operacional menos romântica do que esperava.

Deverias Executar Os Runners GitLab CI/CD No Mesmo VPS?

Para avaliação, sim. Para produção, não.

Um runner de CI na mesma máquina rouba memória e CPU da interface do GitLab. O sintoma clássico é “GitLab parece lento às 9 da manhã,” que geralmente remete a um build que inicia a primeira pipeline da manhã e esgota o frontend da web. A configuração mais limpa é um pequeno VPS separado (ou uma instância DreamCompute) para o runner, registrado na instância do GitLab através da rede.

Se você precisa manter os runners na mesma caixa, aumente o VPS para 16 GB.

De acordo com os requisitos do sistema de runner do GitLab, o próprio processo do runner é leve. As cargas de trabalho que executa não são, e compartilham a CPU e o disco da caixa com tudo mais que o GitLab está fazendo.

Pronto para Fazer a Mudança?

De volta ao bate-papo da equipe de sexta-feira à tarde.

Se o GitHub ficar amarelo e sua equipe rir disso novamente e for tomar um café, tudo bem.

Mas se o GitHub começar a falhar e parecer algo sério?

Talvez esteja ameaçando um contrato de cliente? Surge em uma auditoria de conformidade? Ou a conta da licença por assento finalmente ultrapassou o limite?

Autogestão do GitLab CE começa a se tornar uma opção totalmente razoável. Tudo o que é necessário é um VPS, um domínio, uma instalação Omnibus e uma hora de reforço de segurança.

Até a próxima vez que a página de status do GitHub acender, seu código continuará sendo enviado sem problemas.

Perguntas Frequentes Sobre Hospedagem Própria do GitLab

Há mais alguma coisa que precisas saber sobre hospedagem própria do GitLab num VPS? Abaixo estão as respostas para algumas perguntas frequentemente feitas.

O GitLab CE é gratuito para auto-hospedagem?

Sim, o GitLab CE é gratuito para auto-hospedagem sob uma licença de código aberto estilo MIT. Não há limite de usuários e nenhum preço por assento. Os únicos custos são o próprio VPS e o tempo operacional para mantê-lo.

O VPS Stack 4 da DreamHost é um ponto de partida razoável para avaliação. Equipes de produção normalmente utilizam o Stack 8 ou o Stack 16.

Quanta RAM o GitLab CE realmente precisa?

Planeje 16 GB de RAM para até 1.000 usuários, que é a linha de base publicada pelo GitLab (cerca de 20 solicitações por segundo). Equipes menores podem funcionar com menos, até um limite documentado de 2 GB mais 1 GB de swap para avaliação. De qualquer forma, se você executar pipelines CI/CD na mesma máquina, planeje 16 GB.

Posso hospedar o GitLab em um VPS de 4 GB?

Sim, você pode executar o GitLab CE com 4 GB, mas ele estará lento sob qualquer carga real. O GitLab documenta uma alternativa de 2 GB + 1 GB de swap para ambientes com restrição de memória — esse caminho é para avaliação, não para produção. Para uma equipe que está ativamente enviando código e executando pipelines, 8 GB é o mínimo prático.

Quanto tempo leva para instalar o GitLab CE em um VPS?

Cerca de 10 a 15 minutos para a instalação do pacote, mais aproximadamente uma hora para preparação e reforço de segurança, totalizando cerca de 90 minutos do início ao fim. A instalação em si é principalmente esperar pelo passo de reconfiguração.

A etapa de reforço de segurança, que exige desativar o cadastro aberto, impor a autenticação de dois fatores e bloquear a criação de projetos, leva a hora restante e é obrigatória para qualquer instância de produção.

Vale a pena hospedar o GitLab por conta própria para uma equipe de cinco pessoas?

Provavelmente não, a menos que você tenha um motivo de privacidade ou conformidade. O GitLab.com Free cobre até cinco usuários com projetos privados ilimitados e 400 minutos de CI/CD por mês. O tempo operacional de auto-hospedagem supera o custo por assento economizado nesse tamanho de equipe.

A auto-hospedagem começa a valer a pena, em termos de custo puro, a partir de 30+ usuários ativos.

Qual é a diferença entre GitLab CE e GitLab Community Edition?

GitLab CE e GitLab Community Edition são o mesmo produto. CE é a abreviação padrão. O termo “Self-Managed” refere-se ao local onde você o executa (sua infraestrutura), e não à edição.

A Edição Comunitária do GitLab é de código aberto. A Edição Empresarial (EE) do GitLab adiciona funcionalidades pagas em cima da mesma base de código.

Onde o GitLab CE difere do GitLab EE?

GitLab CE é a edição gratuita e de código aberto. GitLab EE usa a mesma base de código, além de recursos pagos que são ativados quando você faz o upload de um arquivo de licença.

A diferença prática resume-se ao seguinte:

• O CE possui licença MIT e é totalmente funcional. Controle de versão, mesclagem de solicitações, problemas, CI/CD básico, registro de contêineres, tudo.
• O EE adiciona recursos empresariais por trás de uma licença. Pense em epics, frameworks avançados de conformidade, análise de fluxo de valor, múltiplas regras de aprovação e varredura de segurança avançada. De acordo com a comparação de recursos auto-gerenciados do GitLab, a diferença é mais significativa para organizações com processos formais de gestão de mudanças.
• Você pode instalar o EE sem uma licença, e ele funciona como o CE até ser licenciado. É assim que a maioria das equipes se protege contra uma futura necessidade de atualização.
• Você não pode rebaixar o EE para o CE de forma limpa. Planeje-se de acordo.

Para a maioria das equipes de auto-hospedagem, o CE é suficiente. Se o seu motivo é privacidade ou custo, os recursos do EE raramente alteram o cálculo.

Como mantenho minha instância GitLab auto-hospedada atualizada?

Execute `sudo apt update && sudo apt upgrade gitlab-ce` para aplicar patches de segurança. A cadência mensal é o mínimo prático para uma instância em produção. Sempre crie um backup antes de atualizar.

As atualizações de versões principais devem ser feitas sequencialmente — você não pode pular versões principais. Passar de 16.x para 18.x requer atualizar primeiro para 17.x, depois para 18.x. Pular uma versão principal quebrará as migrações de banco de dados. Sempre verifique a ferramenta de caminho de atualização do GitLab antes de atualizar e crie um backup imediatamente antes de cada etapa.

Onde se encaixa a DreamHost em um GitLab auto-hospedado?

VPS Hosting da DreamHost fornece o servidor Linux com acesso root no qual o GitLab CE é instalado. O plano Stack 16 (16 GB de RAM) atende ao requisito oficial do GitLab para até 1000 usuários, com folga para pipelines CI/CD ativos.