Pular para o conteúdo
LatchkeyLatchkey home

GitHub-Hosted vs Self-Hosted vs Runners Gerenciados (2026)

Há três formas de executar jobs do GitHub Actions. Elas trocam custo, velocidade e o quanto de infraestrutura você mantém.

Todo job do GitHub Actions roda em um runner. A sua escolha de modelo de runner é a maior alavanca sobre custo, velocidade e confiabilidade de CI. Veja como as três opções se comparam.

Os três modelos

GitHub-hostedSelf-hostedManaged (ex.: Latchkey)
Custo por minutoMais altoMais baixo (computação bruta) + tempo de operaçãoBaixo (~70% abaixo do hosted)
Você mantém a infraNãoSim - escalabilidade, patches, limpezaNão
Cold start / velocidadeOKRápido (se mantido aquecido)Rápido (warm pools)
CacheBásicoFaça você mesmoEmbutido
Autocorreção de falhasNãoNãoSim (Latchkey)
Ideal paraCI pequeno/ocasionalControle total, larga escalaBaixo custo + baixa operação

GitHub-hosted

Zero configuração, cobrado por minuto a preço premium. Ótimo para baixo volume; caro e inflexível em escala.

Self-hosted

Você roda o agente do runner nas suas próprias máquinas: computação mais barata, controle total - mas você cuida da escalabilidade, patches, limpeza, problemas de disco cheio e runners obsoletos, e das dores de confiabilidade que vêm com infraestrutura de vida longa.

Managed runners

Um provedor opera a frota por você: economia no estilo self-hosted sem a operação. Os melhores adicionam recursos de confiabilidade - o Latchkey adiciona autocorreção para que falhas transitórias se recuperem automaticamente.

How to evaluate a managed runner honestly

  • Compare at equal machine shape. A lower rate on fewer vCPUs is not cheaper per unit of work.
  • Check billing granularity: per-minute rounding costs real money across a wide matrix of short jobs.
  • Include queue and boot time. Cheaper per minute but slower to start can cost more per merge.
  • Count your re-runs. Paying twice for the same work is invisible on every rate card.
  • Switching is a one-line runs-on change in both directions, so a two-week trial beats modelling.

O veredito

Use o GitHub-hosted para pipelines pequenos ou ocasionais. Escolha self-hosted apenas se você quer controle total e tem o time para operá-lo. Para a maioria dos times que quer menor custo sem o fardo operacional - e pipelines que se recuperam sozinhos de falhas instáveis - os managed runners como o Latchkey são o ponto ideal.

Perguntas frequentes

GitHub-Hosted vs Self-Hosted vs Managed Runners (2026)?
Every GitHub Actions job runs on a runner. Your choice of runner model is the biggest lever on CI cost, speed, and reliability. Here is how the three options compare.
GitHub-hosted?
Zero setup, billed per minute at a premium. Great for low volume; expensive and inflexible at scale.
Self-hosted?
You run the runner agent on your own machines: cheapest compute, full control - but you own scaling, patching, cleanup, disk-full and stale-runner problems, and the reliability headaches that come with long-lived infrastructure.
Managed runners?
A provider operates the fleet for you: self-hosted-style economics without the ops. The best add reliability features - Latchkey adds self-healing so transient failures recover automatically.
Which should I choose?
Use GitHub-hosted for small or occasional pipelines. Choose self-hosted only if you want total control and have the team to run it. For most teams that want lower cost without the ops burden - and pipelines that recover from flaky failures on their own - managed runners like Latchkey are the sweet spot.

Guias relacionados