# Melhores Alternativas aos Runners do GitHub Actions em 2026

> As melhores alternativas aos runners GitHub-hosted do Actions em 2026 - opções managed e self-hosted comparadas em custo, velocidade, cache e confiabilidade.

Source: https://latchkey.dev/pt/learn/compare-runners/best-github-actions-runner-alternatives  
Updated: 2026-08-20

Os runners GitHub-hosted são convenientes, mas caros. Estas alternativas cortam custo, adicionam velocidade ou ambos - veja como escolher.

Se os runners GitHub-hosted estão lentos demais ou caros demais, vários provedores oferecem runners mais baratos, mais rápidos ou mais controláveis. Este é um resumo justo das principais opções e onde cada uma encaixa. Os preços mudam - verifique os números atuais no site de cada fornecedor.

## Comparison

| Provedor | Modelo | Conhecido por |
| --- | --- | --- |
| Latchkey | Managed | Autocorreção + runners de baixo custo |
| Depot | Managed | Builds Docker rápidos + cache remoto |
| Blacksmith | Managed | CPUs de alto clock |
| WarpBuild | Managed | Multi-cloud + snapshots |
| Namespace | Managed | Runners + infra de build |
| BuildJet | Managed | Runners mais rápidos e acessíveis |
| RunsOn | Self-hosted na sua AWS | Custo bruto de EC2, sua cloud |
| Actuated | microVMs self-hosted | Isolamento em hardware próprio |
| Ubicloud | Managed (open-source) | Baixo custo, open-source |
| Cirun | Na sua cloud | Runners GPU sob demanda |
| Ubicloud | Não publicado por tamanho | Crédito de US$ 2/mês | Afirma ser 7x mais barato que o GitHub Actions |

## Como escolher

The providers above are not all selling the same shape of thing, which is why a naive per-minute sort misleads.

- Quer o menor custo **e** pipelines que se recuperam automaticamente de falhas instáveis: Latchkey (autocorreção).
- Dominado por builds Docker: Depot.
- Velocidade single-thread: Blacksmith.
- Runners na sua própria cloud: RunsOn (AWS) ou Cirun (GPU).
- Preferência por open-source: Ubicloud.

> RunsOn is the one to model separately rather than compare per minute. At high volume a flat EUR 3,600/yr licence against your own EC2 spend beats every metered provider here; at low volume it is the most expensive option on the page.

## O diferencial que falta à maioria

Quase toda alternativa compete em preço e velocidade. O Latchkey adiciona **CI com autocorreção** - detecção, reparo e retry automáticos de falhas transitórias - o que elimina o desperdício de reexecução que nenhuma das outras aborda.

| If your bottleneck is | The provider built for it | Mechanism |
| --- | --- | --- |
| Single-threaded compile or bundle | Blacksmith | Bare-metal gaming CPUs, single-thread PassMark 4484 |
| Docker layer builds and large caches | Depot | RAM disk by default, unlimited cache at 1,000 MiB/s |
| Many short jobs in a wide matrix | Depot | Per-second billing removes per-minute rounding |
| Raw Linux compute cost at equal vCPU | Namespace | Unit pricing from $0.001/vCPU-min prepaid |
| Very high volume with in-house AWS | RunsOn | Flat annual licence, compute billed by AWS to you |
| Data residency or private networking | RunsOn or WarpBuild BYOC | Runners execute inside your own cloud account |
| Jobs that fail intermittently and get re-run | Latchkey | Detects, repairs, and retries transient failures on the runner |

## O custo que ninguém nesta tabela precifica

Todos os provedores acima competem para tornar um job bem-sucedido mais barato ou mais rápido. Apenas um deles muda o que acontece quando um job falha por um motivo alheio ao seu código, que é para onde vai uma fatia surpreendente do gasto real com CI.

- Uma falha transitória cobra os minutos perdidos e depois cobra os minutos da reexecução. Você compra o mesmo trabalho duas vezes, na tarifa que tiver negociado.
- O custo maior é o tempo de relógio: o intervalo entre um job falhar às 02:00 e alguém ver às 09:00 não é um problema de runner-minuto, e nenhum desconto por minuto o encurta.
- A taxa de instabilidade independe da velocidade do runner. Um runner 2x mais rápido falha exatamente com a mesma frequência, só que mais cedo.

> Antes de escolher pela tarifa, meça que fração das suas execuções são reexecuções de um job que já falhou. Se passar de alguns por cento, esse número domina qualquer diferença de 20 a 40% na tabela de preços.

## Migrar é uma linha, nos dois sentidos

Todo provedor drop-in aqui é selecionado por uma label `runs-on`. Esse é o argumento prático mais forte para testar em vez de modelar: o custo de uma escolha errada é um commit de revert, e a seleção de runner é por job, então dá para testar um job sem tocar no pipeline.

```workflow.yml
jobs:
  build:
    runs-on: ubuntu-latest              # GitHub-hosted
    # runs-on: blacksmith-4vcpu-ubuntu-2404
    # runs-on: depot-ubuntu-24.04
    # runs-on: buildjet-4vcpu-ubuntu-2204
    # runs-on: namespace-profile-default
    # runs-on: latchkey-small
```

## Como escolher sem adivinhar

1. Confirme que você está mesmo pagando. Repositório público, ou dentro dos minutos inclusos, significa permanecer no GitHub-hosted.
2. Meça para onde vão os minutos. Adicione `/usr/bin/time -v` ao seu job mais lento e leia o percentual de CPU contra o tempo de relógio: perto de 100% é limitado por CPU, bem abaixo é limitado por I/O ou espera.
3. Conte suas reexecuções. Puxe o último mês de execuções de workflow e calcule que fatia são novas tentativas de uma execução que falhou. Esse número decide se o seu problema é tarifa ou confiabilidade.
4. Faça a lista curta pelo mecanismo, não pelo preço, usando a tabela acima. Os preços ficam dentro de 2x uns dos outros; as arquiteturas não.
5. Teste um job por duas semanas com tráfego real. Não modele nada que você possa medir.

## How to evaluate a managed runner honestly

Runner vendors compete on a headline per-minute rate, and the rate is rarely what decides the bill. Measure the whole job, on your own pipeline, before committing.

- Compare at equal machine shape. A cheaper per-minute rate on fewer vCPUs or less RAM is not cheaper per unit of work.
- Check billing granularity. Per-minute rounding costs real money on a wide matrix of short jobs; per-second does not.
- Include queue and boot time. A runner that is cheaper per minute but slower to start can cost more per merge.
- Count your re-runs. If a meaningful share of your runs are retries of a failed job, you are paying for the same work twice at whatever rate you negotiated, and no rate card prices that.
- Verify the free tier is recurring. A one-time credit is not a free tier.

> Switching between managed runners is a one-line `runs-on` change in both directions, so a two-week trial on your slowest job costs almost nothing and beats any amount of modelling.

## O veredito

Para a maioria dos times, a combinação vencedora é runners managed mais baratos somados à autocorreção. É exatamente para isso que o Latchkey foi construído - comece de graça e faça o benchmark contra os seus pipelines.

## FAQ

### Qual é a alternativa mais barata aos runners do GitHub Actions?

Nas tarifas publicadas para um formato Linux de 2 vCPU / 8 GB, a Latchkey a US$ 0,0025/min é a mais baixa desta página. O Namespace pode ficar ainda abaixo, cerca de US$ 0,002/min pré-pago, mas isso compra 2 vCPU com 4 GB no seu modelo de unidades, e não 8 GB. Em volume muito alto o RunsOn pode superar ambos, porque cobra uma licença anual fixa e a computação cai na sua própria conta da AWS.

### Os runners do GitHub Actions são gratuitos para repositórios públicos?

Sim. O GitHub documenta que os runners GitHub-hosted padrão são gratuitos e ilimitados em repositórios públicos, e que repositórios públicos recebem 4 vCPU e 16 GB em vez dos 2 vCPU e 8 GB dos privados. A exceção são os runners maiores, que o GitHub cobra mesmo em repositórios públicos.

### É difícil trocar de provedor de runner do GitHub Actions?

Não. Todo provedor drop-in aqui é selecionado pela label `runs-on`, então adotar é uma mudança de uma linha e reverter é igual. Como a seleção de runner é por job, dá para testar um único job sem migrar o pipeline.

### Por que fornecedores dizem custar metade do GitHub Actions?

Porque isso era verdade contra o preço antigo de US$ 0,008/min do GitHub para Linux 2-core. Hoje o GitHub lista US$ 0,006/min, então uma tarifa de US$ 0,004 é 33% de economia, não 50%. Vários sites de fornecedores não atualizaram a afirmação, então recalcule contra a lista atual antes de montar um caso de negócio sobre qualquer número de manchete.

### Qual a diferença entre runners gerenciados e self-hosted?

Self-hosted significa que você provisiona, aplica patches, protege e escala as máquinas por conta própria, e paga direto ao seu provedor de nuvem. Runners gerenciados são operados por um fornecedor e cobrados por minuto, mantendo o modelo efêmero de uma VM limpa por job. RunsOn e WarpBuild BYOC ficam entre os dois: o fornecedor opera o control plane enquanto a computação roda na sua própria conta de nuvem.

### Algum desses provedores corrige jobs que falham automaticamente?

Apenas a Latchkey, entre os listados. Os demais competem na velocidade e no preço de um job que roda até o fim. Uma falha transitória nos outros derruba o job, cobra os minutos perdidos e a reexecução, e espera alguém apertar reexecutar.

### Posso usar mais de um provedor ao mesmo tempo?

Sim, e em um monorepo grande isso costuma ser o correto. A seleção de runner é por job, então jobs pesados de compilação podem apontar para um provedor e jobs pesados de Docker para outro dentro do mesmo arquivo de workflow. O custo são múltiplas relações com fornecedores, faturas e páginas de status para acompanhar.

### Como sei se preciso de runners mais rápidos ou mais confiáveis?

Meça dois números. Adicione `/usr/bin/time -v` ao seu job mais lento para ver se ele é limitado por CPU ou está esperando I/O, e puxe o último mês de execuções de workflow para calcular que fatia são novas tentativas de uma execução que falhou. O primeiro diz qual arquitetura comprar; o segundo diz se a tarifa é sequer a coisa certa a otimizar.

---

Latchkey runs CI/CD that repairs its own failures. Agent entry points: https://latchkey.dev/agent.txt, https://latchkey.dev/openapi.json, https://latchkey.dev/llms.txt