# Blacksmith vs Namespace: CPUs Rápidas vs Plataforma de Build

> Blacksmith vs Namespace para o GitHub Actions em 2026: o Blacksmith foca em runners de CPU de alto clock, o Namespace em runners mais infraestrutura de build mais ampla. Como escolher.

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

O Blacksmith é uma aposta focada em velocidade; o Namespace é uma plataforma de build mais ampla. A escolha certa depende de quanto do seu stack de build você quer em um só lugar.

O Blacksmith é conhecido por runners de CPU de alto clock voltados diretamente a builds single-threaded mais rápidos. O Namespace é conhecido por runners rápidos mais infraestrutura remota mais ampla de build e desenvolvimento. Esta comparação é sobre foco versus amplitude, e onde custo e autocorreção se encaixam. Verifique o preço e os recursos atuais no site de cada fornecedor.

## Comparison

|  | Blacksmith | Namespace |
| --- | --- | --- |
| Conhecido por | Runners de CPU de alto clock | Runners rápidos + infraestrutura de build |
| Escopo | Focado na velocidade do runner | Plataforma de build mais ampla |
| Melhor quando | Builds CPU-bound são o gargalo | Você quer uma plataforma de build integrada |
| Autocorreção de jobs instáveis | Não | Não |
| Otimizado para | Velocidade de thread única | Custo por vCPU-minuto |
| Substrato de computação | CPU gamer bare-metal, microVM Firecracker | Computação em nuvem, medida por unidade |
| Tempo de boot | Menos de 3 segundos (publicado) | Não publicado |
| Compromisso de plano para a melhor tarifa | Nenhum | Tier pré-pago; o excedente custa 50% mais |
| Cache | Co-localizado, sticky disks disponíveis | Snapshots de volume a US$ 0,002/GB-hora |

## Escolha o Blacksmith se

Você quer um upgrade de velocidade focado e drop-in e seu gargalo é trabalho de CPU single-threaded. O Blacksmith mantém a superfície pequena: runners mais rápidos, mudança mínima.

| Job | Namespace at ~$0.002/min | Blacksmith at $0.004/min |
| --- | --- | --- |
| Runs 10 min on both | $0.020 | $0.040 |
| 10 min vs 5 min (CPU-bound) | $0.020 | $0.020, and finishes 5 min sooner |
| 10 min vs 4 min (heavily CPU-bound) | $0.020 | $0.016, and finishes 6 min sooner |

> These rows are illustrative arithmetic, not benchmark results. The point is the shape: measure wall-clock on your own pipeline, because the ranking flips depending on how single-threaded your critical path is.

## Escolha o Namespace se

Você quer mais do que runners, como cache remoto e infraestrutura de build sobre a qual pode padronizar. O Namespace serve equipes investindo em uma plataforma de build mais ampla, em vez de apenas trocar o hardware do runner.

## Se custo e confiabilidade lideram

Ambos competem em velocidade e nenhum auto-recupera jobs instáveis. Se suas prioridades são uma fatura menor e pipelines que se recuperam de falhas transitórias por conta própria, o Latchkey adiciona autocorreção em runners gerenciados de baixo custo. Faça benchmark dele contra o seu pipeline real ao lado daquele que corresponde ao seu escopo.

```workflow.yml
jobs:
  build:
    runs-on: ubuntu-latest        # GitHub-hosted
    # runs-on: latchkey-small     # Latchkey
```

> Runner selection is per job, so you do not have to migrate a pipeline to test one. Point the most expensive job at a candidate, compare two weeks of real runs, and expand only if the numbers hold.

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

Velocidade de CPU focada: Blacksmith. Plataforma de build mais ampla: Namespace. Se custo e re-execuções instáveis são o problema mais profundo, avalie também a autocorreção do Latchkey. Decida pelo escopo primeiro, depois verifique o preço atual.

## FAQ

### Blacksmith vs Namespace: Clock Speed Against Unit Price?

Blacksmith runs bare-metal consumer gaming CPUs and charges a fixed rate per runner-minute. Namespace charges per unit-minute, where one unit is 1 vCPU plus 2 GB of RAM, at $0.001/unit-min prepaid, so a 2 vCPU Linux runner is roughly $0.002/min.

### A cheaper minute is not a cheaper job?

The comparison that matters is cost per completed job, not cost per minute. If Blacksmith finishes a compile-bound job in half the wall-clock time, its higher per-minute rate can still produce a lower bill.

### Watch the RAM ratio on Namespace?

Namespace fixes RAM at 2 GB per vCPU. A job that needs 8 GB but only 2 cores has to buy a 4 vCPU shape to get the memory, which erodes the price advantage precisely where memory-bound builds live: Java, Gradle, and large Node or Webpack builds.

### Switching, and switching back?

Every managed runner in this category is selected by the runs-on label, so adoption and reversal are the same one-line edit. That makes a two-week trial on your slowest job a better decision procedure than any amount of modelling.

### Which should I choose?

CPU-bound critical path, or ARM builds: Blacksmith. Its bare-metal high-clock architecture targets exactly single-threaded compile and bundle steps, and its published $0.0025/min ARM rate is strong.

---

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