# GitHub Actions lento: por que, e como parar de refazer tudo

> O GitHub Actions é lento porque cada trabalho começa em uma VM em branco e baixa as ferramentas, reinstala as dependências e recria as imagens Docker antes do primeiro teste. O Skipbox guarda tudo isso na sua própria máquina entre os trabalhos, por $39 fixos por mês com minutos ilimitados: com 20.000 minutos em 4 vCPU, são $183 a menos por mês que o GitHub.

A maior parte de um trabalho lento do GitHub Actions acontece antes do primeiro teste. Configurar o Node, baixar as dependências, fazer o build da imagem Docker: os mesmos minutos, a cada push, enquanto alguém da sua equipe espera uma verificação verde. Na cobrança por minuto, você também paga por esses minutos.

O Skipbox é um executor do GitHub Actions que mantém a máquina entre os trabalhos, então o que um trabalho instalou ainda está no disco para o próximo. Troque uma linha, `runs-on: skipbox`, e o trabalho roda na sua própria máquina por $39 fixos por mês com minutos ilimitados.

- Dependências, camadas Docker e ferramentas ficam no disco, então os trabalhos pulam os downloads e os rebuilds
- Pelo menos 7× o espaço de cache do GitHub, sem expiração de 7 dias e sem chaves de cache para ajustar
- 20.000 minutos por mês em 4 vCPU: $222 no GitHub, $39 no Skipbox

**GitHub Actions a preço fixo, minutos ilimitados** O Skipbox roda os seus trabalhos do GitHub Actions na sua própria máquina dedicada: $39 por mês, não importa quantos minutos você rode. As camadas Docker e o cache de dependências ficam entre os trabalhos, então o próximo trabalho começa na hora.

Um executor de 4 vCPU, 20.000 minutos por mês: GitHub $222 → Skipbox $39. Você economiza $183 todo mês.

A mudança é uma linha: `runs-on: skipbox`.

[Começar meu teste grátis de 7 dias](https://app.skipbox.dev/sign-in?ref=g-github-actions-slow-pt-br)

## Cada trabalho começa em uma VM em branco

Um executor hospedado pelo GitHub é uma máquina virtual nova para cada trabalho. Nada do que o último trabalho baixou ou construiu está nela, então cada trabalho reconstrói o mesmo estado:

| Etapa | Executor hospedado pelo GitHub | Skipbox |
|---|---|---|
| Configurar Node, Python, Java | Baixa o toolchain | Encontra no cache de ferramentas do último trabalho |
| Instalar as dependências | Baixa e descompacta o arquivo do cache; se não houver acerto, o download inteiro do registro | Lê o cache do gerenciador de pacotes no disco |
| Fazer o build da imagem Docker | Começa sem camadas e refaz cada etapa | Reutiliza as camadas do último build |
| Rodar os testes | 2 CPUs no `ubuntu-latest` de um repositório privado | 4 vCPU ou mais |

As três primeiras linhas não produzem nada novo. Elas só devolvem a máquina ao estado de ontem.

O cache do GitHub ameniza isso sem mudar nada. Ele guarda 10 GB por repositório, apaga as entradas que nenhum trabalho leu em 7 dias, e um branch de feature novo não pode ler o cache de outro branch de feature. Mesmo um acerto baixa e descompacta um arquivo em cada execução.

## Quanto a espera te custa

Digamos que a configuração leve 3 minutos de cada trabalho e a sua equipe rode 100 trabalhos por dia. São 300 minutos por dia de tempo de executor gastos devolvendo a máquina ao lugar, e cada pull request espera a sua parte. As revisões começam mais tarde, os merges entram mais tarde, e os engenheiros mudam para outra coisa enquanto esperam.

Na cobrança por minuto, esses minutos estão na fatura. Um executor de 4 vCPU, por minutos mensais:

| Minutos por mês (4 vCPU) | GitHub | Skipbox S | Você economiza por mês |
|---|---|---|---|
| 10.000 | $102 | $39 | **$63** |
| 20.000 | $222 | $39 | **$183** |
| 30.000 | $342 | $39 | **$303** |

Os valores do GitHub são a fatura depois do uso incluído no GitHub Team. Coloque os seus próprios minutos na [calculadora da página inicial](https://skipbox.dev/?ref=g-github-actions-slow-pt-br#cost); não precisa entrar.

E o número de execuções só sobe:

- **Agentes de IA para programação.** Cada push de um agente inicia o CI. A espera e a fatura crescem com os pushes, não com o tamanho da equipe.
- **Mais testes.** Uma suíte E2E ou uma matriz repete a configuração em cada trabalho que adiciona.
- **Orçamentos.** Limite a fatura com um orçamento do GitHub, e os trabalhos param de começar no meio do mês, o que trava os merges.

## Acelerar por conta própria é um projeto

Ficar nos executores hospedados pelo GitHub e deixá-los rápidos significa assumir um trabalho assim:

- Montar as chaves de cache sobre o hash dos lockfiles e ajustar as `restore-keys` até acertarem
- Adicionar o buildx e exportar o cache do Docker com `cache-to`, dentro dos mesmos 10 GB
- Dividir os testes em shards, em que cada shard repete a configuração e os minutos cobrados sobem
- Ou rodar o seu próprio executor auto-hospedado: provisionamento, atualizações do sistema operacional, limpeza entre os trabalhos e conserto quando ele cai

Cada um contorna uma máquina que esquece tudo. O Skipbox mantém a máquina, então nada disso é necessário.

## O que muda no Skipbox

**A configuração fica no disco.** Os seus trabalhos rodam na máquina própria da sua conta, e ela fica entre os trabalhos. Imagens, camadas e cache de build do Docker; caches de pacotes do npm, do pip, do Gradle e outros; as ferramentas que o `setup-node` e companhia instalam. Pelo menos 7× o espaço de cache do GitHub, sem expiração depois de 7 dias e sem regra de branch.

**Máquinas maiores a preço fixo.** Compiladores e executores de teste iniciam um worker por núcleo, então mais núcleos encurtam as etapas limitadas pela CPU.

| Plano | Máquina | Preço |
|---|---|---|
| S | 4 vCPU · 16 GB | $39 por mês |
| M | 8 vCPU · 16 GB | $79 por mês |
| L | 16 vCPU · 32 GB | $149 por mês |

Os minutos são ilimitados em todos os planos. Os trabalhos no Skipbox não usam minutos do GitHub, então um orçamento do GitHub nunca os para.

**Nenhuma máquina para cuidar.** O Skipbox provisiona a máquina, atualiza o sistema operacional e as ferramentas, limpa tudo depois de cada trabalho, roda uma verificação de integridade e recria a máquina que falha nela.

## Mudar é uma linha

```yaml
jobs:
  build:
    runs-on: skipbox # was ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci && npm test
```

1. Entre no Skipbox com o GitHub.
2. Instale o app do Skipbox no GitHub e escolha os repositórios.
3. Troque o `runs-on` e faça push.

O que o primeiro trabalho instala fica no disco para o segundo.

## Segurança

- A máquina é só da sua conta. Nenhum trabalho de outra empresa roda nela.
- Depois de cada trabalho, as credenciais, os processos e os contêineres do executor são apagados. A partir de 13 de novembro de 2026, o seu checkout e a saída de build dele (o `target/` do Cargo) ficam na sua própria máquina para os próximos trabalhos; Limpar a cada trabalho dá a cada trabalho uma máquina nova.
- O código de pessoas sem acesso de escrita (como pull requests de forks) roda em uma máquina nova, descartável.

Os detalhes estão em [como os trabalhos são isolados](https://docs.skipbox.dev/isolation).

## Teste no seu trabalho mais lento

O teste é grátis por 7 dias ou 3.000 minutos de trabalhos, o que vier primeiro, e não pede cartão. Mova o seu trabalho mais lento para `runs-on: skipbox`, rode-o duas vezes seguidas e coloque os tempos de cada step ao lado dos do GitHub.

## Perguntas frequentes

### Por que o GitHub Actions é tão lento?

Cada trabalho em um executor hospedado pelo GitHub começa em uma VM nova, sem nada da última execução, então ele baixa as ferramentas, reinstala as dependências e recria as imagens Docker antes de os seus testes começarem. O Skipbox roda os seus trabalhos na máquina própria da sua conta e guarda esse estado no disco dela, então o próximo trabalho começa de onde o último parou.

### Adicionei o actions/cache. Por que o meu workflow continua lento?

Mesmo um acerto de cache ainda baixa e descompacta um arquivo em cada trabalho, porque a VM é nova a cada vez. E o cache do GitHub guarda 10 GB por repositório, remove as entradas sem uso há 7 dias e não pode ser lido de um branch irmão. No Skipbox, os caches de pacotes e as camadas Docker já estão no disco da máquina, sem chaves para gerenciar.

### Como deixar os builds Docker mais rápidos no GitHub Actions?

Dê ao build as camadas do último build. Nos executores hospedados pelo GitHub, isso significa exportar o cache com o buildx e importá-lo a cada execução, dentro do mesmo limite de 10 GB. No Skipbox, as imagens e o cache de build do Docker ficam na máquina entre os trabalhos, então o docker build reutiliza as camadas sozinho.

### Preciso reescrever os meus workflows para usar o Skipbox?

Não. Nos trabalhos Linux, troque o runs-on para skipbox. A máquina roda Ubuntu 24.04 com Docker, Node.js e Python, e os seus steps e actions rodam como estão.

### Posso testar de graça no meu próprio trabalho lento?

Sim. O teste dura 7 dias ou 3.000 minutos de trabalhos, o que vier primeiro, sem cartão. Mova o seu trabalho mais lento para runs-on: skipbox, rode-o duas vezes seguidas e compare os tempos de cada step com os do GitHub.

Atualizado em 2026-11-11 · https://skipbox.dev/pt-br/guides/github-actions-slow