Depot vs Blacksmith: comparação de runners do GitHub Actions

Q: Como migro para qualquer um dos dois?

Ambos são drop-in: instale o GitHub App e mude a label runs-on no seu workflow. Seu YAML, actions e passos ficam intocados. Isso também significa que sair é igualmente barato, então nenhuma das escolhas cria lock-in.

Por Daniel Zoghalchali·Latchkey

Duas opções populares de runners gerenciados com pontos fortes diferentes: Depot para builds Docker, Blacksmith para velocidade bruta de CPU.

Depot e Blacksmith superam os runners hospedados pelo GitHub, mas otimizam coisas diferentes. Aqui está a divisão honesta - além de onde entra uma opção com autocorreção como o Latchkey.

Depot vs Blacksmith at a glance

	Depot	Blacksmith
Melhor em	Aceleração de builds Docker + cache remoto	Runners com CPU de alta frequência
Carga ideal	Pipelines pesados em containers	Build/teste single-thread
Autocorreção	Não	Não
Linux arm64, 2 vCPU	Não publicado como tarifa separada	US$ 0,0025/min
Substrato de computação	Instância EC2 single-tenant por job	CPU gamer bare-metal, microVM Firecracker
Otimizado para	Vazão de disco e cache	Velocidade de relógio em core único
Cache	Armazenamento ilimitado, até 1.000 MiB/s	Cache co-localizado, sticky disks
Granularidade de cobrança	Por segundo	Por minuto
Plano gratuito	Plano Developer de US$ 20/mês inclui minutos	3.000 minutos/mês
Tempo de boot	Não publicado	Menos de 3 segundos (afirmação publicada)
Recuperação automática de falhas	Não	Não

Escolha o Depot se

Seu CI é dominado por builds de imagens Docker e o cache remoto de build é o seu gargalo.

Linux x64 size	GitHub-hosted	Depot	Blacksmith
2 vCPU	$0.006	$0.004	$0.004
4 vCPU	$0.012	$0.008	$0.008
8 vCPU	$0.022	$0.016	$0.016
16 vCPU	$0.042	$0.032	$0.032

Escolha o Blacksmith se

Seu tempo de build/teste é limitado por CPU e hardware mais rápido por núcleo é a vantagem.

Published workload claims: Node.js builds 5.9x, Rust 4x, Docker 3x, and Android 2.3x faster than GitHub-hosted.
Co-located CI cache and Docker layer caching, with sticky disks and static IPs as add-ons.
Installed as a GitHub App, selected with runs-on labels.
3,000 free minutes per month.

Uma terceira opção

Se sua dor real é custo somado a re-execuções instáveis, nenhum dos dois resolve isso - o Latchkey adiciona autocorreção em runners gerenciados mais baratos.

Unlimited cache storage, against the 10 GB per-repository ceiling on GitHub-hosted cache.
RAM disks on by default, so heavy write workloads never touch a network volume.
Billed per second rather than rounded up to the minute.
No concurrency cap on simultaneous jobs.
Runner images track GitHub-hosted definitions, updated within one to two weeks of a release.

Qual gargalo você realmente tem?

A resposta honesta é que a maioria das equipes não sabe, e escolhe pela impressão de marca. Dá para descobrir em um job. Adicione este passo a um workflow representativo nos seus runners atuais e leia a divisão entre tempo de CPU e tempo de relógio.

Measure before you choose (GitHub Actions step)

- name: Where does this job spend its time
  run: |
    /usr/bin/time -v ./your-build-command 2>&1 | tee timing.txt
    echo "--- cache restore ---"
    du -sh ~/.cache 2>/dev/null || true

# In the output:
#   "Percent of CPU this job got"  near 100% (or N x 100% when parallel)
#     -> CPU-bound. A faster core wins. Favor Blacksmith.
#   "Percent of CPU this job got"  well under 100%
#     -> the job is waiting on disk or network. Favor Depot.
#   "Elapsed (wall clock) time"  dominated by actions/cache restore
#     -> cache throughput is your ceiling. Favor Depot.

A regra de decisão

Uma vez conhecida a divisão, a escolha é mecânica.

Se o seu pipeline é dominado por	Escolha	Porque
Compilação de TypeScript, Rust, Kotlin ou C++	Blacksmith	Caminhos críticos de compilação são de thread única; a alavanca é a velocidade de clock
Builds de imagem Docker com layers grandes	Depot	A vazão do cache de layers e o disco em RAM dominam o tempo de build
Restauração via `actions/cache` de árvores grandes de dependências	Depot	Cache ilimitado a 1.000 MiB/s contra um teto de 10 GB
Um test runner de thread única	Blacksmith	Mesma razão da compilação: um core faz o trabalho
Muitos jobs curtos em uma matrix grande	Depot	A cobrança por segundo evita pagar pelo arredondamento não usado
Builds ARM64	Blacksmith	Tarifa ARM publicada de US$ 0,0025/min; a Depot não publica tarifa ARM separada
Jobs que falham de forma intermitente e são reexecutados	Nenhum resolve isso	Ambos cobram a reexecução pela tarifa cheia

O que nenhum dos dois faz

Os dois fornecedores competem em fazer um job bem-sucedido terminar mais cedo. Nenhum muda o que acontece quando um job falha por um motivo que nada tem a ver com o seu código: um timeout de registry, um mount de rede instável, uma falha transitória de resolução de dependências, um binário de navegador que não instalou. Nas duas plataformas esse job falha, alguém percebe, e alguém clica em reexecutar. Você paga os minutos perdidos e os minutos de reposição, e o merge depende de haver uma pessoa acordada.

A execução que falhou é cobrada. A reexecução também. Nenhum fornecedor dá desconto por falha transitória.
O custo em tempo de relógio não são os minutos do runner, é o intervalo entre a falha e a pessoa que a percebeu.
A taxa de instabilidade independe da velocidade do runner. Um runner 2x mais rápido falha com a mesma frequência, só que mais cedo.

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.

The verdict

Limitado por Docker: Depot. Limitado por CPU: Blacksmith. Custo + confiabilidade: avalie o Latchkey ao lado deles.

Perguntas frequentes

Depot ou Blacksmith é mais barato?

Nenhum. Em 2026-08-20 as tarifas Linux x64 publicadas são idênticas em todos os tamanhos que ambos vendem: US$ 0,004/min com 2 vCPU, US$ 0,008 com 4, US$ 0,016 com 8 e US$ 0,032 com 16. A única tarifa publicada que difere é Linux arm64, em que a Blacksmith lista US$ 0,0025/min e a Depot não publica tarifa ARM separada.

Qual é mais rápido, Depot ou Blacksmith?

Depende do que o seu job faz. A Blacksmith é mais rápida em trabalho limitado por CPU porque roda CPUs gamer bare-metal com PassMark de thread única citado em 4484. A Depot é mais rápida em trabalho limitado por I/O porque monta um disco em RAM por padrão e serve cache a até 1.000 MiB/s sem teto de armazenamento. Um pipeline pesado em compilação favorece a Blacksmith; um pesado em Docker ou cache favorece a Depot.

Como migro para qualquer um dos dois?

Ambos são drop-in: instale o GitHub App e mude a label runs-on no seu workflow. Seu YAML, actions e passos ficam intocados. Isso também significa que sair é igualmente barato, então nenhuma das escolhas cria lock-in.

Depot ou Blacksmith reexecutam jobs que falham automaticamente?

Não. Nenhum dos produtos inclui detecção e reparo automáticos de falhas transitórias. Um job que falha por timeout de registry ou binário de navegador ausente falha nas duas plataformas, é cobrado nas duas, e espera alguém apertar reexecutar. O reparo automático no runner é a lacuna que ambos deixam aberta.

Qual é o plano gratuito de cada um?

A Blacksmith publica 3.000 minutos gratuitos por mês. A Depot embute minutos em planos pagos, a partir do plano Developer de US$ 20/mês, que inclui 2.000 minutos de GitHub Actions, 500 minutos de build Docker e 25 GB de cache.

Por que a cobrança por segundo importa?

Porque matrices do GitHub Actions produzem muitos jobs curtos. Um job de 70 segundos é cobrado como 2 minutos por quem cobra por minuto e como 70 segundos por quem cobra por segundo. Em uma matrix de 40 jobs isso dá cerca de 15% de diferença no mesmo trabalho. A Depot cobra por segundo; a Blacksmith por minuto.

Algum deles remove o limite de 10 GB de cache do GitHub Actions?

A Depot sim, explicitamente: o armazenamento de cache é ilimitado, com excedente cobrado a US$ 0,20/GB/mês além do incluído no plano. A Blacksmith oferece cache co-localizado e sticky disks opcionais, mas não publica um número de teto de armazenamento, então confirme contra o seu working set antes de migrar um cache grande.

Posso usar os dois?

Sim, e num monorepo grande pode ser a resposta certa. Como a seleção de runner é por job, dá para apontar jobs pesados de compilação para um provedor e jobs pesados de Docker para outro usando labels runs-on diferentes no mesmo arquivo de workflow. O custo são duas relações com fornecedores e duas faturas.

Guias relacionados

GitHub Actions Runner Alternatives: Every Published Price (2026)Eleven managed GitHub Actions runner alternatives with their published per-minute rates, free tiers, and Blacksmith vs GitHub-Hosted Runners: Real Cost and SpeedBlacksmith vs GitHub-hosted runners on published rates and CPU architecture, including the case where Managed GitHub Actions Runners Compared (2026)Managed GitHub Actions runners compared in 2026 - Blacksmith, Depot, Namespace, BuildJet, WarpBuild, and Depot Alternatives: Best Managed GitHub Actions RunnersLooking for a Depot alternative for GitHub Actions? Compare the top options on cost, caching, and GitHub Actions Cost Calculator - Estimate & Cut Your CI BillFree GitHub Actions cost calculator: enter your monthly CI minutes and runner size to see your current bill