O CRACI é o runner onde os seus builds são executados

Uma linha muda o build de sítio

O CRACI substitui o runner, não o GitHub Actions. Os seus ficheiros de workflow, actions e segredos ficam onde estão; o que muda é o local onde o job é executado:

jobs:
  build:
    runs-on: craci

As execuções continuam a aparecer no GitHub, pelo que os pull requests, os checks e os logs permanecem onde a sua equipa já os consulta. Essa configuração cabe à GitHub App, que instala em todos os repositórios ou apenas nos que escolher.

O que são os runners

• Tamanhos de 1 a 32 unidades de computação, cada uma com 1 vCPU e 3 GB de RAM, sendo 2 o tamanho predefinido. Defina o tamanho por job com cracicorp/setup@v1 e o respetivo input size:.
• x86-64 e ARM64 nativos à mesma tarifa.
• Imagens: CRACI Slim, CRACI Slim ARM64 e uma imagem Ubuntu 24.04 compatível com o GitHub, com Docker Engine, Buildx e Compose v2.
• Máquinas virtuais isoladas por job. A virtualização aninhada está disponível em x86-64 e em preview em ARM64.
• Cache: cache do GitHub Actions e ainda cache de camadas de contentores, com caches de camadas locais, remotas e por bind mount.
• Infraestrutura do pipeline: um intervalo estável de IP de saída e templates de runners ao nível da organização.
• Linux hoje. Os runners Windows e macOS estão no roadmap.

Os runners são geridos pelo CRACI e executados em infraestrutura bare-metal europeia, com residência de dados na UE. Os runners alojados pelo cliente estão no roadmap para o plano Enterprise; consulte runners geridos face a runners self-hosted para conhecer as contrapartidas.

Porque é que a segurança da cadeia de abastecimento pertence ao runner

O build de produção não é o build feito num portátil. Os intervalos de versões são resolvidos de outra forma, as tags mudam, as caches estão quentes ou frias e o ambiente não é o mesmo. O único registo fiável do que foi distribuído é o que é feito enquanto o build da versão decorre, e é por isso que o CRACI colocou o mecanismo de registo dentro do runner e não ao lado dele. O argumento completo está em porque é que a segurança da cadeia de abastecimento pertence à CI.

Como o CRACI controla o runner, pode fazer coisas que um scanner não consegue:

• Registar, não analisar. Um proxy que reconhece pacotes observa o que o job efetivamente descarrega, incluindo dependências transitivas e pacotes restaurados de caches de CI. A SBOM de cada job inclui um estado de completude.
• Aplicar uma política de egress. A política é aplicada no runner, validada antes do início do job e falha em modo fechado.
• Devolver as evidências. A API devolve SBOM, traços de rede e proveniência de cada job.

Cerca de duas vezes mais rápido do que os runners alojados no GitHub

O CRACI executa builds cerca de duas vezes mais depressa do que os runners alojados padrão do GitHub, com os mesmos workflows e sem os alterar. O job que demorava dez minutos passa a demorar cerca de cinco.

Uma CI mais rápida vale mais do que os minutos que poupa. Um pull request que fica verde em cinco minutos ainda tem um revisor a olhar para ele; um que demora vinte já foi posto de parte pelo autor, que passou a outra tarefa. O tempo de build é o intervalo entre escrever uma alteração e saber se funciona, e é pago em cada push por cada engenheiro da equipa.

Há três fatores que o explicam: o hardware, tempos de espera mais curtos e a cache.

Quanto custa a aceleração

Como o CRACI mede ao segundo e cobra menos por minuto, ser duas vezes mais rápido soma-se à poupança em vez de a anular. Num build que demora dez minutos num runner x64 de 2 núcleos alojado no GitHub (preços de tabela do GitHub em setembro de 2026, do CRACI em outubro de 2026):

Build de dez minutos, 1.000 vezes por mês	GitHub-hosted	CRACI
Tempo real por build	10 minutos	Cerca de 5 minutos
Custo por build	$0.060	$0.020
Custo por mês	Cerca de $60	Cerca de $20

Isto representa cerca de 67% menos, ou 3 vezes mais barato. Sem a aceleração, a poupança resume-se à diferença de preço de tabela, cerca de 33% em x64 de 2 núcleos. Quanto mais rápidos ficam os seus próprios builds depende da carga de trabalho, por isso mude um workflow e meça.

Faturação ao segundo

Os minutos de build são medidos ao segundo, arredondados ao segundo mais próximo. O GitHub arredonda cada job para cima até ao minuto inteiro, pelo que uma matriz de jobs curtos é faturada por tempo que nunca utilizou: um job de 30 segundos custa cerca de 67% menos no CRACI, e um job de 70 segundos cerca de 61% menos. Nos jobs longos, a diferença aproxima-se da diferença de preço de tabela.

Os minutos de build custam $0.002 por vCPU-minuto, ou $0.004 por minuto num runner de tamanho 2, à mesma tarifa em ARM64. O CRACI não é o runner mais barato do mercado, e o preço não é o argumento: o argumento é aquilo que o runner regista enquanto é executado. Consulte os preços.

Como o CRACI se compara com outros runners de GitHub Actions

O Blacksmith, o Depot, o Namespace e o WarpBuild funcionam da mesma forma que o CRACI: os seus workflows ficam no GitHub Actions e muda apenas o local onde o job é executado. Em velocidade e preço estão próximos uns dos outros, e vários anunciam um preço ARM inferior ao do CRACI. A diferença está naquilo que o runner regista e controla enquanto o job decorre.

O CRACI é um dos runners mais acessíveis, e é o que produz uma SBOM do que o job efetivamente obteve, aplica uma política de egress que falha em modo fechado e devolve dados de proveniência através da sua API, como subproduto da execução do build, sem nada acrescentado ao workflow. Se quiser a versão completa, linha a linha: runners de GitHub Actions comparados.

O que corre bem no CRACI

Tudo o que um job de GitHub Actions faz: builds de aplicações, imagens de contentores, suites de testes. Dois casos que merecem destaque são os builds Yocto e BitBake de imagens de Linux embebido, documentados até runners de tamanho 32, e os builds pi-gen do Raspberry Pi OS.

No roadmap

• Runners Windows e macOS: no roadmap.
• Runners alojados pelo cliente: no roadmap, para o plano Enterprise.
• Outros sistemas de CI: GitHub Actions hoje, outros no roadmap, ainda sem data.