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

> Depot vs Blacksmith para GitHub Actions: o Depot lidera em cache de builds Docker, o Blacksmith em velocidade de CPU. Como escolher - e onde a autocorreção se encaixa.

Source: https://latchkey.dev/pt/learn/compare-runners/depot-vs-blacksmith  
Updated: 2026-08-20

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.

## Comparison

|  | 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 |

> The one published rate that does separate them is Linux arm64. Blacksmith lists ARM at $0.0025/min; Depot does not publish a separate ARM rate. If your builds run on ARM, that gap is real money and it favors Blacksmith.

## 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.

> Single-thread performance is the right thing to optimize when your critical path is one process doing one thing: `tsc`, a Rust or Kotlin compile, a Webpack bundle, a single-threaded test runner. Adding vCPUs does not help those; a faster core does.

## 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.

> Per-second billing sounds like a rounding detail and is not. A pipeline of 40 short jobs averaging 70 seconds each pays for 40 full minutes on a per-minute biller and roughly 47 minutes of actual time on a per-second one. The shorter and more numerous your jobs, the more the rounding costs you.

## 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.

> 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

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

## FAQ

### 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.

---

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