GitLab próprio: como eu rodo mais de 300 microsserviços sem pagar GitHub

De onde eu falo

Meu nome é Josimar e eu tenho uma empresa de tecnologia. O GitLab a gente usa aqui há muitos anos, mais de 10, 12. Começou lá pela versão 7, instalado direto num servidor dedicado, que nem virtualizado era.

Hoje todo o nosso processo passa por ele: mais de 300 microsserviços dentro do GitLab, dominado na nossa mão. E eu não pago nenhum Enterprise do GitLab pra isso.

Então o que vem aqui não é comparativo de ferramenta que eu li em algum lugar. É o cenário em que eu trabalho em produção.

O problema não é só o preço

Por que economizar? Porque todo mundo está batendo os limites do GitHub. Você tem um, dois projetos, e deu limite. Aí tem que fazer upgrade. Upgrade, upgrade, upgrade. Até quando você vai fazer upgrade no GitHub?

E o problema não é só o preço. Você fica pagando um negócio que sai do ar, com o Actions fora, enquanto o seu pipeline fica cada vez mais complexo. Eu já escrevi sobre a terceira queda do GitHub que eu tinha avisado.

Eu gravei antes um material mais extenso sobre o GitHub virar gargalo, e uma parte não ficou clara: a hora em que eu disse que o GitHub ia começar a cobrar de quem roda o Actions hospedado no próprio servidor, o self-hosted. Eles sabem que quem roda o Actions dentro de casa faz um uso mais profissional, em ambiente local, e não fica só mandando API pra lá e pra cá.

Eu fui conferir como isso está. Em dezembro de 2025 o GitHub anunciou uma cobrança de US$ 0,002 por minuto que alcançaria também o runner próprio a partir de 1º de março de 2026. No mesmo comunicado, numa atualização, avisou que estava adiando essa mudança pra reavaliar. Em 9 de outubro de 2026, a documentação de cobrança do Actions dizia que o uso com runner próprio é gratuito.

Adiado não é cancelado. É por isso que eu digo: qualquer dia o GitHub começa a te cobrar no self-hosted também, e não só naqueles minutos lá.

Cada camada a mais deixa o pipeline mais lento

Hoje tem coisa demais pra testar. Toda semana aparece uma ferramenta nova e a galera quer plugar no pipeline porque está na moda.

É só mais camada, cara. Será que você precisa mesmo? Mais uma chamada externa pra ir e voltar. Será que não é melhor rodar alguma coisa local, ou chamar outro modelo pelo OpenRouter, do que botar mais uma camada de comunicação externa?

Eu tenho que ter um ganho grande demais pra fazer um negócio desse. Porque a cada peça que você pluga:

• o seu pipeline complica;
• o tempo do seu pipeline aumenta;
• ele demora mais pra responder, porque entra a latência de cada serviço.

Tem API que responde muito rápido. A do Grok, por exemplo, respondia mais rápido que todas as outras da última vez que eu testei. Testar é bom. Mas eu sou contra sair colocando camada a mais. Quanto mais camada, mais complexo. E isso nem é opinião minha: qualquer engenharia é assim.

Um teste desses eu contei em detalhe: o Jules do Google, que não serviu no meu pipeline. Na época eu achei o fluxo muito inseguro e não colocaria em produção. Estou até curioso pra testar de novo.

Com IA, o teste que era utopia virou obrigação

Hoje, pra gente botar algo em produção, a gente precisa de um pipeline gigantesco, com 350 testes, pra cercar os guard rails. É o que não deixa passar o que a inteligência artificial, os nossos agentes autônomos, façam de errado.

Com IA, o cenário ideal é o cenário de utopia que a gente nunca conseguiu com ser humano: 100% de teste no sistema. Só que a gente testa o que tem que dar certo e, principalmente, o que não pode dar certo.

Uma área de login tem 50, 70 testes de possibilidade, dependendo da quantidade de campos. Aí você olha e fala: só a área de login gastou 30, 40 minutos pra testar tudo. E não é só teste unitário. Tem teste de ponta a ponta, tem validação.

Esses são os testes que todo mundo já faz. Agora entram os testes de guard rail, que conferem o agente:

• ele obedeceu o que eu passei pra ele?
• desenvolveu só o que precisava?
• alterou só os arquivos que precisava?
• seguiu as regras do agente e dos subagentes?
• seguiu as regras das skills?

Cada um desses é mais um estágio. O pipeline em que isso roda eu contei em como eu substituí um dev júnior por IA.

Onde os seus 2.000 minutos somem

O que acontece lá na ponta? Os seus 2.000 minutinhos vão sendo comidos. Lembrando que uma hora são 60 minutos.

A tabela do GitHub, que eu conferi em 9 de outubro de 2026, é esta:

A coluna de horas é conta minha, é só dividir por 60. Agora põe um CI de três horas em cima disso. Em 2.000 minutos cabem 11 execuções completas no mês.

E CI não roda uma vez só. Às vezes a gente pede pra IA rodar o dela, e na hora em que ela comita pro ambiente de sandbox ou de staging, roda o CI inteiro. O CI de três horas deu errado. Volta, desenvolve, mais três horas. Deu errado de novo. Foram nove horas de CI embora.

Com o GitHub e o Actions caindo, e com o pipeline ficando mais complexo, isso de perder duas, três, quatro, cinco horas vai ser mato.

Aí você tem dois caminhos dentro do GitHub: ou contrata o Enterprise deles, e se a empresa tem muito dinheiro você nem precisa se preocupar com isso, ou vai pro self-hosted esperando o dia da cobrança.

A saída óbvia: um GitLab instalado num Docker

Qual é a forma mais óbvia de não ter um vendor lock-in hoje? Uma que é de graça, é só você estudar.

Por que você ainda não começou a usar um GitLab local, instalado num Docker, pra ir pegando segurança e testando? Por que você não faz isso pra ter independência do GitHub? O caminho está na própria documentação: instalar o GitLab num contêiner Docker.

"Ai, vou ter que aprender sintaxe diferente, porque o Actions é diferente do YAML do GitLab." É, meu filho, faz parte.

Você decora isso uma vez e vai embora. Vê a sintaxe, vê as diferenças, entende como funciona, e pronto: depois você bate o olho e já sabe se está certo ou não. E a própria IA te ajuda a migrar.

Eu estou citando os dois porque é o que a gente usa aqui. Sei que tem outros. E pode ser que daqui a uns dias o GitHub ou o GitLab parem de existir, ou que surja outro, sei lá o que vem pela frente. O ponto não é a marca. É a independência. Foi o mesmo raciocínio de por que eu não uso GitHub, Supabase ou Firebase em produção.

Como é aqui: mais de 300 microsserviços, sem limite de runner

Aqui na empresa ele funciona redondinho, há anos:

• sem limitação de runner;
• sem cobrança de tempo;
• ficou lento? A gente escova bit: vai lá, olha o que está errado e arruma.

Se você pretende viver de SaaS, ter os seus SaaS, dar manutenção em muito microsserviço, não faz sentido ficar pagando por isso em 2026.

E eu não vou te vender facilidade. Era chato de atualizar o GitLab quando a gente começou. Hoje ainda é chato de atualizar. Ele tem as nuances dele e os problemas dele.

"Mas eu trabalho numa empresa, tem que ter redundância"

Ok, tem que ter redundância. Mas quanto você paga hoje no seu projeto? Faz a pergunta antes de montar um cluster.

Eu separo em três cenários:

O failover parece simples: um docker run de um lado, um docker run do outro. Mas a pergunta é onde estão os arquivos e o que aconteceu enquanto um estava fora. Você precisa integrar outras coisas por trás, como o banco e o Redis que ele usa internamente, pra outra instância conseguir assumir.

Você vai até o ponto em que vale a pena pra você.

A documentação do GitLab vai na mesma linha. Nas arquiteturas de referência, a recomendação geral de alta disponibilidade começa em 3.000 usuários. Abaixo disso, ela diz que, pra muitos clientes, uma estratégia de backup é suficiente e até preferível, e avisa que alta disponibilidade é complexa e traz custo de manutenção.

O hardware: não precisa de 32 cores e 64 GB

Teve gente comentando no canal que eu estava achando tudo fácil demais, que precisava de 32 cores e 64 GB de RAM pra rodar. Não lembro o número exato que ele pôs, mas era dessa ordem.

Não precisa disso tudo. O que acontece com menos hardware é que a performance cai um pouco. Quanto mais hardware, melhor a performance, e nem sempre de forma proporcional. Tem umas maldades no caminho, de configuração e de otimização.

Fui conferir os requisitos de instalação do GitLab: pra um nó só, a base que a documentação dá é de 8 vCPU e 16 GB de memória, e ela diz que o GitLab roda com pelo menos 8 GB.

O runner não fica na máquina do Git

Aí tem o hardware dos runners. O que é o runner? É o equivalente, no GitLab, ao que executa o seu Actions. É onde aquele deploy é lido e executado.

Você instala o runner, mas não na mesma máquina. Não é boa prática. O Git é bom ter num cantinho separado, já que ele centraliza todos os seus repositórios.

A documentação do GitLab Runner pede a mesma coisa: instalar o runner numa máquina separada da que hospeda o GitLab, por segurança e por performance.

Por que eu não pago o Enterprise

Com mais de 300 projetos, eu não pago nenhum Enterprise do GitLab. "Nossa, mas aí você não usa as ferramentas de SSO, de segurança do Git." Não uso.

Eu coloco dentro do meu próprio pipeline os outros testes que eu preciso pra segurança, ainda mais agora com IA. Se eu já rodo isso dentro do pipeline, pra que eu vou contratar o GitLab pra fazer pra mim? Por que eu vou pagar 20, 30, 40 por usuário por uma coisa que um pipeline meu faz, ou que um web hook dentro do próprio GitLab trava?

Pra você ter a referência: em 9 de outubro de 2026, a página de preços do GitLab listava o plano Premium a US$ 29 por usuário por mês, na cobrança anual, e o Free a zero, inclusive pra quem instala por conta própria.

O web hook que resolveu o tempo na issue

Vou dar um exemplo. Eu tinha um problema grande na empresa: fazer o pessoal colocar o tempo gasto na issue. Quem trabalha com sprint fechada sabe o que é isso.

Eu meti um web hook. Ninguém subia nada sem colocar o tempo da issue. Pronto, resolveu. Está na sua mão. Quando é que você vai ter essa possibilidade num serviço que não é seu?

Depois a galera foi lá e fez um scriptzinho de commit: cada vez que comitava, ele fazia o cálculo na IDE, subia e já setava o tempo gasto. O cálculo automático não é tão preciso assim, mas ajudava a gente e resolvia os relatórios e as outras coisas que a gente precisava.

No GitLab esse tempo é o controle de tempo da issue, que você registra com a ação rápida /spend. E o que roda no servidor e consegue recusar um push inteiro a documentação chama de server hook. As duas coisas aparecem na edição Free, e o server hook só existe pra quem instala o próprio GitLab.

Tem várias vantagens em usar o Enterprise. Pode usar, se você quiser. Eu estou te explicando o meu cenário.

E tem o outro lado: o lugar em que sobra dinheiro e se paga tudo pra todo mundo, ou em que ninguém entende nada, alguém diz que é obrigatório e pronto, contrata. Aí você contrata o Enterprise pra uma equipe que não vai usar, e paga um monte de recurso que ninguém usa. Já aconteceu isso aqui também.

A conta: 400 a 500 por mês só de Git

Se eu fosse gastar, eu gastaria cerca de 400 a 500 por mês só com Git aqui dentro da empresa, pela quantidade de deploy que a gente faz.

É muito dinheiro, eu acho. Quinhentos por mês só de Git, caramba. São duas assinaturas e meia do plano de 20x do Claude. Ou da OpenAI.

Pra mim isso é uma baita economia. E é assim que a gente economiza.

Pra quem faz sentido, e pra quem não faz

Isso pra mim é muito claro. Se é um SaaS de poucos usuários, ou um SaaS pouco complexo, talvez não faça sentido nada do que eu estou falando.

Agora, um SaaS que tem front, back e uns cinco, seis microsserviços rodando em paralelo, e que está evoluindo, que não é produto de prateleira: aí faz todo sentido você começar a ter essa independência.

E eu afirmo categoricamente: vai te fazer economizar um dinheirão lá na frente, porque os pipelines vão ficar cada vez mais complexos.

Por onde você começa, de graça

Não é bicho de sete cabeças. E você não precisa comprar a minha imersão pra fazer isso.

1. Instala um GitLab local, num Docker, só pra testar.
2. Sobe um runner em outra máquina.
3. Migra um pipeline pequeno e aprende a diferença de sintaxe. Pede ajuda pra IA.
4. Vai entendendo a relação de custo-benefício do Git com o runner, de processador e de memória.
5. Só depois decide até onde vale a pena ir em redundância.

Vai testando devagarinho, vai pegando a manha. Coloca a mão na massa e testa. Só assim você vai entender se aquilo funciona ou não pra você.

Eu não sou o professor do passo a passo. O que eu faço no canal é te dar o mapa e as dicas pra você ir trabalhando.

Nem toda decisão minha deu certo

Se você já quebrou um SaaS, eu te entendo. Eu já matei um monte. Um deles quase me deu um infarto.

Um tempo atrás eu fiz um SaaS de conferência, o JMV Conference. O Zoom cobrava 14 por mês pelo mesmo recurso, e eu ia gastar quase R$ 200.000 pra deixar o meu rodando. Falei: não vou gastar 200 mil pra mexer com isso.

Veio a pandemia, o Zoom bombou, o preço disparou. E eu chorei.

Decisão de negócio, faz parte do jogo. O que eu fiz? Sentei, chorei e desisti? Não. Próximo. Deu errado, ótimo, vida que segue. É o meu estilo de trabalhar.

Deploy e Git são uma ponta. A outra, onde a maioria fracassa, é venda, pós-venda, marketing e tráfego.

Nota de cronologia

Este relato é de uma gravação de setembro de 2026, publicada em 6 de outubro de 2026. No fim dela eu convido pra uma imersão de três dias em São Paulo sobre pôr um SaaS em produção, do zero até a venda. As condições que eu falei ali eram as daquele dia. O que vale é o que está na página da Imersão de SaaS.

Sobre a cobrança do self-hosted: quando eu gravei, eu disse que qualquer dia ela chega. O que existe de oficial, na data em que eu conferi, é o anúncio de dezembro de 2025 com o adiamento, sem data nova. Se o GitHub publicar outra coisa depois de 9 de outubro de 2026, vale o que ele publicar.

E sobre os "400 a 500 por mês": eu não falei a moeda na gravação. A comparação que eu fiz, de duas assinaturas e meia do plano de 20x do Claude, fecha em dólar. A central de ajuda do Claude lista o Max 20x a US$ 200 por mês, e duas e meia dão US$ 500.

Perguntas frequentes