GitHub Actions vs GitLab CI vs CircleCI: qual CI/CD compensa
Comparativo prático de GitHub Actions, GitLab CI e CircleCI por custo, minutos grátis, artifacts e setup. Escolha a pipeline certa pro tamanho do projeto.
Por Vitor Morais
Fundador do MochaLabz ·
GitHub Actions, GitLab CI e CircleCI oferecem free tiers generosos o suficiente pra rodar testes e deploy de um projeto com receita zero — mas cada um cobra diferente quando o projeto cresce. Escolher errado não quebra nada no dia 1; quebra no mês em que o build começa a levar 40 minutos e a fatura aparece. Este comparativo usa três critérios que importam quando a operação é enxuta: minutos gratuitos por mês, armazenamento de artifacts e custo incremental real quando o free tier acaba.
O problema real: CI/CD é commodity até você precisar pagar
Nos primeiros meses de qualquer projeto, CI roda pouco. Dois pushes por dia, suíte de testes que leva 3 minutos, deploy pra Vercel ou Cloudflare que nem passa pela pipeline. A tentação é escolher a plataforma "que todo mundo usa" e não pensar mais nisso. O custo aparece em três momentos previsíveis:
- A suíte de testes cresce e cada run leva 15–25 minutos. Minutos grátis acabam no meio do mês.
- Artifacts de build (imagens Docker, bundles) somam GBs e o storage gratuito estoura.
- O projeto precisa de runner com mais RAM (testes e2e com Playwright, por exemplo) e o runner padrão não dá conta.
Quem já passou por isso sabe: migrar de CI no meio do projeto é possível, mas dolorido. Configs de YAML não são portáveis entre plataformas, secrets precisam ser reconfigurados, e o histórico de runs some. Escolher com critério agora evita essa dor.
Free tier lado a lado: minutos, storage e concurrency
A tabela abaixo compara o que cada plataforma entrega sem pagar nada. Valores mudam — confira a página de pricing oficial antes de decidir. O ponto aqui é a proporção entre elas.
| Critério | GitHub Actions | GitLab CI (Free) | CircleCI (Free) |
|---|---|---|---|
| Minutos/mês (Linux) | 2.000 min | 400 min de compute (shared runners) | 6.000 créditos (~equivalente a minutos em runner médio) |
| Minutos/mês (macOS) | 200 min | Não incluso no free | Não incluso no free |
| Storage de artifacts | 500 MB | 5 GB de registry + artifacts | Sem limite declarado (artifacts expiram em 30 dias) |
| Concurrency | 20 jobs simultâneos | Varia conforme fila compartilhada | 1 job simultâneo (resource class small) |
| Self-hosted runner | Sim, grátis e ilimitado | Sim, grátis e ilimitado | Sim (runner próprio sem custo de crédito) |
| Container services no job | Sim (com override de entrypoint desde abril 2026) | Sim (services nativo no .gitlab-ci.yml) | Sim (via executor Docker) |
Override de entrypoint no GitHub Actions
Desde abril de 2026, GitHub Actions permite usar as keys entrypoint e command para sobrescrever defaults de imagens em service containers direto no YAML do workflow. Isso elimina workarounds com Dockerfiles customizados só pra CI.
Quando o free tier acaba: custo incremental de cada plataforma
O free tier é o chamariz. O que define se a plataforma cabe no projeto de verdade é quanto custa o minuto extra quando os grátis acabam — e como esse custo escala.
- GitHub Actions — cobra por minuto excedente. Runner Linux é o mais barato; macOS e Windows têm multiplicador (macOS custa várias vezes mais por minuto). Self-hosted runner zera esse custo, mas transfere a responsabilidade de manutenção.
- GitLab CI — o plano pago seguinte (Premium) inclui mais minutos de compute e funcionalidades de compliance. O salto de preço é por seat, não por minuto avulso, o que pode ser vantajoso quando há 2–3 pessoas no projeto.
- CircleCI — modelo de créditos. Cada resource class consome créditos diferentes. Escalar pra runner maior (mais RAM, mais CPU) gasta créditos mais rápido. Performance plan cobra por uso real, sem seat.
A diferença estrutural: GitHub e GitLab cobram por seat nos planos pagos (o que inclui CI como parte do pacote), enquanto CircleCI cobra puramente por uso de compute. Pra um projeto com 1 pessoa que roda muitos builds, CircleCI pode ser mais caro que GitHub Actions com self-hosted runner. Pra 3 pessoas que rodam poucos builds, o seat do GitLab Premium pode incluir tudo sem surpresa.
Self-hosted runner: quando vale o trabalho
Rodar um runner na própria máquina (ou numa VPS barata) elimina custo de minutos. Mas adiciona responsabilidade: manter o runner atualizado, garantir que o ambiente está limpo entre runs, e lidar com falhas de rede. Em termos práticos:
- Faz sentido quando os builds são pesados (Playwright, builds Docker multi-stage, compilação Rust) e o free tier acaba toda semana. Uma VPS de entrada com 4 GB de RAM resolve a maioria dos casos.
- Não faz sentido quando os builds são leves (lint + unit tests em Node.js que levam 3 minutos) e cabem no free tier com folga. O overhead de manutenção não se paga.
- GitHub Actions e GitLab CI facilitam o setup: um binário, um token, um
systemdservice. CircleCI também suporta, mas a documentação é mais fragmentada.
Setup mínimo de self-hosted runner no GitHub Actions (Linux)
# 1. Baixar o runner (cheque a versão atual em Settings > Actions > Runners)
mkdir actions-runner && cd actions-runner
curl -o actions-runner-linux-x64.tar.gz -L https://github.com/actions/runner/releases/download/v2.XXX.X/actions-runner-linux-x64-2.XXX.X.tar.gz
tar xzf ./actions-runner-linux-x64.tar.gz
# 2. Configurar com token do repositório
./config.sh --url https://github.com/SEU-USER/SEU-REPO --token SEU_TOKEN
# 3. Rodar como serviço
sudo ./svc.sh install
sudo ./svc.sh startWorkflow usando self-hosted runner
name: CI
on: [push]
jobs:
test:
runs-on: self-hosted
steps:
- uses: actions/checkout@v4
- run: npm ci
- run: npm testSegurança do self-hosted runner
Nunca use self-hosted runner em repositório público sem proteções extras. Qualquer PR pode executar código no seu servidor. Em repositórios privados o risco é controlável, mas garanta que o runner roda em ambiente isolado (container ou VM dedicada).
IA no code review: hype vs realidade em pipelines pequenas
GitLab liberou acesso a agentes IA (Duo Agent) na free tier a partir da versão 18.10, incluindo review automatizado de merge requests. O apelo é óbvio: quem não tem par pra revisar código ganha um segundo olho artificial. Mas o dado real é mais sóbrio do que o marketing sugere.
Em empresas usando ferramentas de IA pra code review, o tempo médio de review aumentou 91%, com engenheiros esperando em média 13 horas por merge request. O motivo: a IA gera comentários em volume, muitos deles falsos positivos, e o humano ainda precisa triar tudo. Em operação de 1–2 pessoas, o efeito é diferente — não há fila de MRs, então o gargalo não é espera, é qualidade da sugestão.
- Útil pra pegar erros de segurança triviais (secret hardcoded, SQL sem parametrização) que passam batido quando se faz self-review.
- Irritante quando gera 15 comentários de estilo que o projeto já resolve com ESLint/Prettier. Desabilitar regras cosméticas na configuração do agent economiza tempo.
- Não substitui revisão humana de lógica de negócio. O agent não sabe que o desconto não pode ser negativo no contexto do seu SaaS.
Se o repositório já está no GitLab, ativar Duo Agent no free tier custa zero e leva minutos. Se o repositório está no GitHub, opções equivalentes existem via GitHub Actions com integração a LLMs ou ferramentas como CodeRabbit. O ponto é: não migre de plataforma só por causa de AI review. O ganho real é marginal comparado ao custo de trocar todo o CI.
Decisão por perfil de projeto: a recomendação direta
Depois de comparar free tier, custo incremental, self-hosted e AI review, a recomendação se resume a três cenários:
- Código já no GitHub, builds leves (<10 min), sem orçamento extra → GitHub Actions. O free tier de 2.000 minutos/mês em Linux cobre a maioria dos projetos com folga. O ecossistema de actions do marketplace reduz YAML boilerplate. Se os minutos acabarem, self-hosted runner resolve sem custo.
- Projeto precisa de registry de containers + CI integrado + AI review grátis → GitLab CI. Os 400 minutos são curtos, mas o registry incluso e o Duo Agent sem custo compensam pra quem quer tudo num lugar só. Ideal quando o repositório já mora no GitLab ou quando migrar é aceitável.
- Builds pesados (e2e, compilação longa), time de 1 pessoa, sem querer manter runner → CircleCI. O modelo de créditos permite pagar só pelo que roda, sem seat fee. A concurrency de 1 job no free tier é limitante, mas o upgrade é granular.
Nenhuma dessas plataformas é errada. A escolha errada é migrar no meio do projeto porque não avaliou o custo incremental antes. Gaste 30 minutos agora calculando quantos minutos o build vai consumir em 6 meses — multiplique o tempo atual do build pelo número de pushes por dia e por 22 dias úteis. Se o resultado cabe no free tier, escolha a plataforma onde o código já está. Se não cabe, self-hosted runner é quase sempre mais barato que upgrade de plano.
Setup mínimo pra cada plataforma: YAML lado a lado
Pra quem nunca configurou CI em nenhuma das três, o atrito inicial é parecido: criar um arquivo YAML na raiz do repositório. A diferença está na convenção de nomes e na sintaxe de jobs.
.github/workflows/ci.yml (GitHub Actions)
name: CI
on:
push:
branches: [main]
pull_request:
branches: [main]
jobs:
test:
runs-on: ubuntu-latest
services:
postgres:
image: postgres:16
entrypoint: docker-entrypoint.sh # override disponível desde abril 2026
env:
POSTGRES_PASSWORD: test
ports:
- 5432:5432
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: 22
- run: npm ci
- run: npm test
env:
DATABASE_URL: postgres://postgres:test@localhost:5432/postgres.gitlab-ci.yml (GitLab CI)
stages:
- test
test:
stage: test
image: node:22
services:
- name: postgres:16
alias: db
variables:
POSTGRES_PASSWORD: test
variables:
DATABASE_URL: postgres://postgres:test@db:5432/postgres
script:
- npm ci
- npm test.circleci/config.yml (CircleCI)
version: 2.1
jobs:
test:
docker:
- image: cimg/node:22.0
- image: cimg/postgres:16.0
environment:
POSTGRES_PASSWORD: test
steps:
- checkout
- run: npm ci
- run: npm test
environment:
DATABASE_URL: postgres://postgres:test@localhost:5432/postgres
workflows:
main:
jobs:
- testOs três exemplos fazem a mesma coisa: checkout, instalar dependências, rodar testes com Postgres como service container. A diferença prática mais relevante é como cada um resolve service containers — e o GitHub Actions agora permite override de entrypoint e command, o que antes exigia Dockerfile wrapper.
Outra diferença que aparece conforme o projeto cresce: feature flags no deploy exigem que a pipeline saiba qual ambiente está ativo. GitHub Actions e GitLab CI resolvem isso com variáveis de ambiente por branch; CircleCI usa contexts. Nenhum é melhor — mas a migração entre eles exige reescrever essa parte.
Artifacts e cache: onde o dinheiro vai embora
O maior custo escondido em CI não são os minutos — é o upload repetido de node_modules e imagens Docker. Configure cache de dependências (actions/cache no GitHub, cache key no GitLab, save_cache/restore_cache no CircleCI) e defina TTL curto pra artifacts de build. Isso sozinho pode cortar 30–50% do tempo de pipeline.
Perguntas frequentes
GitHub Actions é grátis para repositório privado?+
Sim. Repositórios privados no GitHub Free recebem 2.000 minutos/mês de runners Linux e 500 MB de storage para artifacts. Minutos excedentes são cobrados. Self-hosted runners não consomem minutos.
Qual CI/CD tem mais minutos grátis por mês?+
Em runners gerenciados Linux, GitHub Actions oferece 2.000 minutos/mês no free tier — o maior entre as três plataformas comparadas. GitLab CI oferece 400 minutos de compute. CircleCI trabalha com sistema de créditos, o que torna a comparação direta menos linear.
Vale a pena usar self-hosted runner em projeto pessoal?+
Depende do volume de builds. Se a pipeline roda mais de 2.000 minutos/mês (builds pesados com testes e2e ou Docker multi-stage), um self-hosted runner numa VPS de entrada sai mais barato que pagar minutos excedentes. Para builds leves que cabem no free tier, o overhead de manutenção não compensa.
Posso migrar de GitLab CI para GitHub Actions sem reescrever tudo?+
Não existe conversão automática entre os formatos YAML. A lógica dos jobs é parecida, mas sintaxe de services, cache, artifacts e variáveis muda. Projetos simples levam 1–2 horas de reescrita; projetos com matrix builds e deploy multi-stage podem levar um dia inteiro.
IA no code review da CI vale a pena para quem trabalha sozinho?+
Parcialmente. Agentes como GitLab Duo Agent pegam erros de segurança triviais que escapam no self-review. Mas geram volume alto de comentários cosméticos. Configure o agent pra ignorar regras de estilo (ESLint/Prettier já cobre) e foque nos alertas de segurança e lógica.
Artigos relacionados
git history: reescrever commits sem rebase interativo
Git 2.54 trouxe o comando experimental git history para editar commits sem rebase interativo. Veja os 3 casos reais mais comuns e quando usar cada abordagem.
GitHub Copilot coleta seu código privado: como proteger
A partir de 24 de abril, GitHub usa código de repositórios privados para treinar IA. Veja como desabilitar, o que muda no workflow e implicações LGPD para freelancer.
Feature flags no Next.js com Vercel Flags sem pagar terceiro
Como implementar feature flags nativos no Next.js com Vercel Flags: targeting, rollout gradual e quando vale pagar pelo LaunchDarkly.
Segurança indie: 5 camadas que seu SaaS precisa (sem overkill)
Guia prático de segurança pra solopreneur. Quais defesas você realmente precisa, quanto custam e onde não vale investir tempo agora.