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

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.

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:

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:

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

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

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.

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.

Atualizado em 11 de novembro de 2026