GitHub Actions ou GitLab CI: o runner próprio muda a conta e a migração

Para repositórios públicos que usam runners hospedados padrão, o GitHub Actions oferece minutos gratuitos. Em repositórios privados, o GitHub Free inclui 2.000 minutos mensais e cobra US$ 0,006 por minuto excedente no Linux x64 de dois núcleos, conforme as regras de cobrança do GitHub Actions. Um runner próprio não consome essa franquia, mas transfere o custo da máquina e de sua operação para a equipe.

No GitLab.com, o Free inclui 400 minutos mensais; o Premium inclui 10.000, custa US$ 29 por usuário ao mês na cobrança anual, e minutos adicionais são vendidos por US$ 10 a cada 1.000, segundo a tabela de preços do GitLab. Runners próprios também ficam fora da cota nessa plataforma. Portanto, escolher entre os serviços exige somar a execução hospedada ou própria ao trabalho de adaptar o pipeline, sobretudo a seleção de runners, as credenciais e os artefatos.

Onde os minutos entram na conta

O tempo total de um pipeline não equivale necessariamente ao consumo faturável. No GitLab.com, o cálculo dos minutos computacionais soma a duração dos jobs, inclusive os que rodam em paralelo, e aplica um fator conforme o runner. O Linux x86-64 padrão tem fator 1; o Linux médio, fator 2. Assim, dez minutos de execução no runner médio consomem vinte minutos da franquia. O tempo em que o job aguarda para começar não entra na duração.

A visibilidade do projeto altera a comparação. Um projeto público comum no GitLab.com ainda consome minutos dos runners hospedados; projetos públicos aceitos no programa GitLab for Open Source recebem um fator reduzido. No GitHub, a gratuidade em repositórios públicos vale para runners hospedados padrão, enquanto runners maiores são cobrados mesmo nesses repositórios. As franquias também pertencem a unidades distintas: no GitHub Free, à conta proprietária dos repositórios; no GitLab.com, ao namespace de nível superior.

Armazenamento de artefatos e cache precisa ficar fora da conta de minutos. Um job curto que conserva arquivos por muito tempo pode ter um custo de armazenamento separado no GitHub; a duração do pipeline, sozinha, não mede essa despesa. Para comparar plataformas, convém usar primeiro o consumo real de jobs e só depois acrescentar licenças, armazenamento e serviços externos.

Quanto custam 2 mil, 10 mil e 50 mil minutos

Os cenários abaixo são hipotéticos: repositórios privados, um mês de jobs em runners Linux padrão, GitHub Free e GitLab.com Free. O Premium aparece apenas pelo excedente de execução, sem o preço das licenças. A conta presume que não há saldo de minutos adicionais comprado anteriormente; no GitLab, é preciso adquirir pacotes inteiros para cobrir o consumo que ultrapassa a franquia.

• Com 2.000 minutos, o GitHub Free permanece na franquia, sem custo adicional de execução. O GitLab Free precisa cobrir 1.600 minutos excedentes com dois pacotes, por US$ 20. No Premium, todo o volume cabe na franquia.
• Com 10.000 minutos, o GitHub Free cobra US$ 48 pelos 8.000 minutos excedentes. O GitLab Free exige dez pacotes, por US$ 100; no Premium, não há excedente de execução.
• Com 50.000 minutos, o excedente do GitHub Free é de 48.000 minutos, ou US$ 288. No GitLab Free, 50 pacotes cobrem os 49.600 minutos excedentes, por US$ 500. No Premium, os 40.000 minutos acima da franquia custam US$ 400 em pacotes.

Esses valores comparam execução, não assinaturas completas. Uma equipe que já paga pelo GitLab Premium pode aproveitar a franquia contratada; uma equipe que teria de aderir ao plano precisa acrescentar o custo de cada usuário. Minutos adicionais do GitLab comprados e não utilizados podem passar para o mês seguinte, de modo que o desembolso de um mês isolado não representa necessariamente o gasto médio recorrente.

O resultado também muda quando os jobs saem do Linux padrão. No GitHub, sistema operacional e capacidade alteram a tarifa por minuto. No GitLab.com, o fator do runner altera a velocidade com que a franquia é consumida. Por isso, a mesma duração de relógio pode produzir contas diferentes das mostradas nos três cenários.

Quando o runner próprio compensa

Ao executar jobs em infraestrutura da equipe, os minutos deixam de consumir a franquia de runners hospedados nas duas plataformas. Isso não torna a execução gratuita: entram na conta a máquina ou instância, armazenamento, rede, energia, atualização do runner e tempo de operação. Também é preciso dimensionar a capacidade para os períodos de pico, quando vários jobs podem precisar de execução simultânea.

Uma estimativa útil divide o custo mensal da capacidade própria pelos minutos efetivamente executados nela e acrescenta o trabalho de administração. Se a máquina passa grande parte do tempo ociosa, seu custo por minuto útil sobe; se já atende outras cargas e recebe muitos jobs, a parcela atribuída ao CI pode cair. O cálculo deve considerar a capacidade realmente disponível, pois transferir jobs para um runner próprio pode reduzir a despesa hospedada e, ao mesmo tempo, criar uma fila de execução.

Em um repositório público no GitHub, os minutos do runner padrão já são gratuitos, então a justificativa econômica para manter hardware próprio é diferente daquela de um projeto privado com muito consumo excedente. Acesso a uma rede interna, requisitos específicos de hardware ou controle do ambiente de execução podem pesar mais que a franquia. Se houver migração de plataforma, esses jobs ainda precisarão ser associados aos runners corretos na nova configuração.

O trabalho que acompanha a migração

Mover o código não converte os workflows. O guia de migração do GitLab orienta criar um arquivo .gitlab-ci.yml e mapear os jobs do GitHub Actions: comandos de run passam para script, runs-on dá lugar à seleção por tags, e condições de execução precisam ser expressas nas regras do GitLab. A correspondência entre usos de actions e mecanismos de reutilização do GitLab exige avaliar o comportamento de cada integração, não apenas trocar palavras no YAML.

O esforço fica mais claro quando o pipeline é inventariado por componentes que precisam funcionar no destino:

• Conte as referências distintas em uses e identifique quais viram comandos, quais têm um template ou configuração equivalente e quais exigem outra integração.
• Conte segredos e credenciais por ambiente, incluindo o escopo de acesso de cada um. No GitLab, variáveis sensíveis exigem configuração adequada de proteção e mascaramento; copiá-las para o arquivo do pipeline as exporia a quem pode ler o repositório.
• Conte artefatos produzidos e os jobs que os consomem. Registre caminhos, dependências e retenção, além dos caches necessários para manter o comportamento da execução.
• Conte disparos por push, solicitação de mudança ou agendamento, condições por branch e jobs associados a runners específicos. Cada regra precisa produzir no destino o mesmo conjunto de execuções esperado pela equipe.

Essas contagens delimitam o trabalho, mas não são horas de migração: substituir um comando simples e recriar uma integração de publicação têm complexidades diferentes. Há ainda uma regra fora do YAML. A documentação do importador do GitLab informa que a exigência do GitHub de verificações de status aprovadas antes do merge não é importada, embora outras regras de proteção possam ser mapeadas. Se essa exigência faz parte do processo de entrega, sua configuração no destino deve entrar no mesmo inventário do pipeline.

Leia também:

• Make ou n8n: cobrar por etapa ou execução muda o custo da automação
• Agente de IA ganhou uma VM própria — isole rede, segredos e estado na AWS
• Omie ou Conta Azul: faturamento e estoque podem dobrar o custo do ERP