Runners self-hosted de GitHub Actions vs runners geridos do CRACI

O que é um runner self-hosted de GitHub Actions?

Um runner self-hosted é uma máquina que implementa e gere e que executa jobs de GitHub Actions em vez de uma VM alojada no GitHub. Pode ser um servidor físico, uma máquina virtual, um contentor, on-premise ou na sua conta cloud, e o GitHub diz que é o utilizador o responsável pela máquina e por todo o seu software.

• Registo: um runner regista-se num repositório, organização ou enterprise de cada vez. Registe-o ao nível da organização e use runner groups para partilhar runners entre repositórios.
• Plataformas: a aplicação de runner suporta distribuições Linux comuns, Windows 10, 11 e Windows Server, e macOS 11 e posteriores, em x64 e ARM64.
• Rede: o runner liga-se ao GitHub através de HTTPS de saída na porta 443.
• Atualizações: a aplicação de runner tem de ser atualizada no prazo de 30 dias após uma nova versão. Atualiza-se sozinha, salvo se desativar essa opção.
• Limites: um job pode durar até 5 dias, face a 6 horas nos runners alojados no GitHub, e um job em fila durante mais de 24 horas falha.
• Escalabilidade: o Actions Runner Controller (ARC), um operador de Kubernetes, escala runner scale sets com o número de workflows em execução. Os runners registados com --ephemeral aceitam um único job.

Porque é que as equipas usam runners self-hosted

As equipas usam runners self-hosted para reduzir os custos por minuto, para chegar a sistemas internos ou a hardware específico, e para usar capacidade que já pagam. Os runners maiores do GitHub também não podem usar minutos incluídos, pelo que as máquinas grandes ficam caras em runners alojados.

Hoje o GitHub não cobra por minuto pelos runners self-hosted. Anunciou uma taxa de plataforma cloud de $0.002 por minuto para runners self-hosted a partir de 1 de março de 2026 e depois adiou-a "to take time to re-evaluate our approach." Em setembro de 2026, a documentação de faturação do GitHub descreve a utilização self-hosted como gratuita. O que o GitHub não paga é tudo o que rodeia o runner.

As três partes do custo self-hosted

O custo self-hosted é infraestrutura, tempo de engenharia e reforço da segurança. Só a primeira parte aparece numa fatura.

Infraestrutura

Paga os hosts quer executem jobs quer fiquem inativos, pelo que dimensiona para a hora de maior atividade. Some o armazenamento para caches e imagens, o tráfego de rede e o que usar para monitorizar e escalar automaticamente a frota.

Tempo de engenharia

A documentação do GitHub é direta quanto à responsabilidade: com runners self-hosted, "you are responsible for updating the operating system and all other software." Na prática, isso significa também atualizações de versão do runner, divergência de imagens entre hosts, limpeza de disco, scripts de escalamento automático e alguém de prevenção quando a fila deixa de andar.

Reforço da segurança

As orientações de segurança do GitHub para runners self-hosted incluem dois avisos que merecem ser lidos na íntegra:

Self-hosted runners should almost never be used for public repositories on GitHub, because any user can open pull requests against the repository and compromise the environment. GitHub Docs, Secure use reference

Self-hosted runners for GitHub do not have guarantees around running in ephemeral clean virtual machines, and can be persistently compromised by untrusted code in a workflow. GitHub Docs, Secure use reference

O GitHub recomenda runners just-in-time que executam no máximo um job antes de serem removidos. Fazer isto bem significa máquinas efémeras, isolamento entre jobs, controlos do tráfego de rede de saída e tratamento cuidadoso dos segredos. Cada um destes elementos é trabalho que tem de conceber, construir e manter em funcionamento.

Boas práticas para runners self-hosted em escala

As orientações de segurança do GitHub e as práticas publicadas pela AWS para runners em escala convergem na mesma lista. Cada item é um projeto em si:

• Runners efémeros: um job por máquina, para que nada passe de um job para outro.
• Runner groups: separe os runners por repositório e ambiente, idealmente em contas separadas.
• Credenciais de curta duração: OpenID Connect para a sua cloud em vez de chaves de acesso de longa duração.
• Controlo de egress: limite o que um job consegue alcançar, não apenas o que executa.
• Tempo de arranque: warm pools e imagens personalizadas, porque as máquinas efémeras demoram mais a arrancar.
• Custo: instâncias spot com alternativa para jobs de longa duração.
• Monitorização: métricas de jobs em fila, em execução e concluídos, com alertas.

No CRACI, o primeiro e o quarto vêm com o runner: cada job é executado numa máquina virtual isolada sob uma política de egress validada antes de o job arrancar e com falha em modo fechado.

Um modelo de custos que pode preencher

Exemplo A

Valores ilustrativos, não benchmarks. 60.000 minutos de build por mês em runners de 2 vCPU, $350 por mês para hosts de runners e 8 horas de manutenção por mês a $85 por hora.

• Self-hosted: $350 + (8 × $85) = $350 + $680 = $1,030 por mês
• CRACI: 60.000 × $0.004 = $240 por mês

Exemplo B

Valores ilustrativos, não benchmarks. Os mesmos 60.000 minutos, mas os hosts custam $115 por mês e a manutenção demora 2 horas a $85 por hora.

• Self-hosted: $115 + (2 × $85) = $115 + $170 = $285 por mês
• CRACI: $240 por mês

No Exemplo B, os dois ficam próximos só em computação. É um resultado real para equipas com hosts baratos e uma configuração estável. Para encontrar o seu ponto de equilíbrio, subtraia o custo dos seus hosts ao valor do CRACI e divida pelo seu custo por hora. Com os hosts do Exemplo B, isso dá ($240 menos $115) ÷ $85, ou cerca de 1,5 horas de manutenção por mês.

Há duas coisas que a fórmula não mostra. Primeiro, o valor do CRACI inclui mais do que computação (consulte a secção seguinte). Segundo, as horas são o valor que a maioria das equipas subestima. Conte as atualizações de imagens, os patches de segurança, o escalamento, a limpeza de disco e o tempo gasto com jobs falhados, e não apenas a configuração inicial.

O que os runners self-hosted não lhe dão

Um runner self-hosted executa o seu job, mas não regista o que o job fez. Nos runners do CRACI, cada build produz evidências à medida que é executado:

• Uma SBOM registada durante o build em CycloneDX ou SPDX, a partir de um proxy que reconhece pacotes e observa o que o job obtém, incluindo pacotes restaurados de caches de CI. A completude é indicada por job e por cache.
• Política de egress de rede, de negar ou permitir por predefinição, com 24 predefinições integradas de fontes de software e fontes personalizadas tipadas. As políticas são validadas antes de o job arrancar e falham em modo fechado. As violações acionam alertas.
• Um traço de rede por job, disponível através da API.
• Dados de proveniência, disponíveis através da API.
• Acompanhamento de vulnerabilidades em todos os builds e repositórios, com as SBOM monitorizadas reavaliadas continuamente.

Pode construir partes disto em runners self-hosted com o seu próprio proxy, ferramentas de SBOM e registo de rede. Se o fizer, o tempo para construir e manter tudo isso pertence ao modelo de custos acima.

O que o CRACI não oferece

Hoje o CRACI não oferece runners alojados pelo cliente nem on-premise; estão no roadmap para o plano Enterprise. Os builds são executados nos runners geridos do CRACI em infraestrutura europeia. Se um job tiver de ser executado dentro da sua própria rede, em hardware seu ou num ambiente air-gapped, mantenha um runner self-hosted para esse job.

• Hoje os runners do CRACI são apenas Linux; Windows e macOS estão no roadmap. Os builds macOS e Windows ficam onde estão.
• x86-64 e ARM64 têm a mesma tarifa.
• Imagens: CRACI Slim, CRACI Slim ARM64 e uma imagem Ubuntu 24.04 compatível com o GitHub. A virtualização aninhada está disponível em x86-64 e em pré-visualização em ARM64.
• O GitHub Actions é a integração de CI suportada.

Uma configuração mista é comum. Mover um job é uma alteração à sua linha runs-on, pelo que pode mover a maioria dos jobs e manter alguns em runners self-hosted. Só os jobs em runners do CRACI obtêm SBOM registadas durante o build e política de rede.

Como decidir

Decida com base nos seus próprios números: o custo e as horas de runners do último mês, as evidências que lhe pedem e um workflow real executado em cada opção.

1. Some a fatura de hosts do último mês e as horas que a sua equipa gastou com runners, incluindo incidentes.
2. Conte os seus minutos de build.
3. Coloque ambos nas fórmulas acima.
4. Liste as evidências que lhe pedem (SBOM, proveniência, controlos de rede) e o que seria necessário para as produzir nos seus runners atuais.
5. Marque uma demo e execute um workflow real no CRACI para comparar.

Mais sobre o funcionamento dos runners: integração de CI/CD, segurança no CRACI e a documentação.

Runners self-hosted de GitHub Actions: perguntas frequentes

Respostas curtas sobre custo, configuração, segurança e limites.

O que é um runner self-hosted de GitHub Actions?

Um runner self-hosted é uma máquina que implementa e gere e que executa jobs de GitHub Actions. Pode ser física, virtual, um contentor, on-premise ou numa conta cloud. Instala nela a aplicação de runner do GitHub, regista-a num repositório, organização ou enterprise, e direciona os jobs para ela com runs-on: self-hosted ou com as suas próprias etiquetas.

Os runners self-hosted de GitHub Actions são gratuitos?

Em setembro de 2026, o GitHub não cobra por minuto pelos runners self-hosted. Anunciou uma taxa de plataforma de $0.002 por minuto a partir de 1 de março de 2026 e depois adiou-a para reavaliar a sua abordagem. Continua a pagar as máquinas, o respetivo armazenamento e rede, e o tempo necessário para as manter atualizadas e seguras.

Um runner self-hosted pode servir vários repositórios?

Um runner regista-se num repositório, organização ou enterprise de cada vez. Para o partilhar entre repositórios, registe-o ao nível da organização e controle o acesso com runner groups, ou execute várias instâncias de runner na mesma máquina, cada uma registada em separado.

Que sistemas operativos podem executar um runner self-hosted?

O GitHub suporta a aplicação de runner em distribuições Linux comuns como Ubuntu 20.04 e posteriores, Debian 10 e posteriores e RHEL 8 e posteriores, em Windows 10, 11 e Windows Server 2016 a 2022, e em macOS 11 e posteriores. Funciona em x64 e ARM64, e em ARM32 no caso do Linux.

Quanto tempo pode durar um job num runner self-hosted?

Até 5 dias, face a 6 horas nos runners alojados no GitHub. Um job que fique em fila durante mais de 24 horas falha.

Os runners self-hosted são seguros para repositórios públicos?

O GitHub diz que os runners self-hosted quase nunca devem ser usados em repositórios públicos, porque qualquer pessoa pode abrir um pull request e executar código na máquina. A sua recomendação são runners efémeros just-in-time que executam no máximo um job, além de isolamento, controlo de egress e tratamento cuidadoso dos segredos.

O que faz o Actions Runner Controller?

O Actions Runner Controller (ARC) é um operador de Kubernetes que orquestra e escala runners self-hosted para GitHub Actions. Os runner scale sets crescem e diminuem com o número de workflows em execução. Continua a ser o utilizador a operar o cluster, as imagens e a rede à volta deles.

Os runners do CRACI podem ser executados na minha própria rede?

Hoje não. O CRACI oferece runners geridos em infraestrutura europeia, com runners alojados pelo cliente no roadmap para o plano Enterprise. Os jobs que têm de ser executados dentro da sua rede podem ficar em runners self-hosted enquanto os restantes passam para o CRACI.