CRACI vs RunsOn

A resposta curta

O RunsOn são runners self-hosted de GitHub Actions sem a manutenção de uma frota de runners. Uma stack CloudFormation ou um módulo Terraform implementa-o na sua conta AWS; a partir daí, cada job recebe uma nova instância EC2 do tipo que escolher, e a AWS fatura a computação a preço de custo. Se quer runners dentro da sua própria conta de cloud e a fatura de computação mais baixa possível, sobretudo com instâncias spot, é difícil bater o RunsOn.

O CRACI é uma CI que trata nativamente da segurança da cadeia de abastecimento. É um runner gerido, compatível com GitHub Actions, e a segurança faz parte do runner em vez de ser uma ferramenta acrescentada: o CRACI regista todas as dependências externas que o build obteve, aplica uma política de egress na rede do build e transforma esse registo em SBOM, monitorização de vulnerabilidades e evidências. Ambos os produtos substituem o runner onde os seus jobs correm, pelo que tem de escolher um.

Visão geral

O que o RunsOn faz bem

A sua conta, os seus dados. O plano de controlo, as VM dos runners, a cache S3 e os registos ficam todos na sua conta AWS, e os fluxos de dados do próprio RunsOn limitam-se à validação da licença, à telemetria e ao suporte. Para as equipas cuja revisão de segurança para em "um terceiro executa o nosso código e os nossos segredos", é essa a resposta que o RunsOn foi feito para dar. Os runners do CRACI são hoje geridos; os runners alojados pelo cliente estão no seu roadmap para o Enterprise.

Qualquer instância, uma por job. A etiqueta runs-on escolhe a máquina, pelo que um job pode pedir uma grande instância otimizada para computação, uma GPU, armazenamento NVMe local ou Windows. Cada job recebe uma nova instância EC2 que é destruída quando termina, e o RunsOn afirma que os jobs arrancam normalmente em cerca de 30 segundos, ou em menos de 6 com warm pools.

Custo. O RunsOn não acrescenta margem à computação da AWS e cobra uma licença fixa, a partir de cerca de $348 (€300) por ano. Afirma que o resultado é 7 a 12 vezes mais barato do que os runners alojados no GitHub. As instâncias spot com recurso automático a on-demand baixam ainda mais a fatura. Estes números são do RunsOn; a sua combinação de instâncias e a região decidem o valor real.

Cache e observabilidade. Uma cache suportada por S3 na sua VPC substitui a cache do GitHub sem o respetivo limite de tamanho, a cache de camadas Docker está integrada, e os sticky disks EBS e os volumes partilhados EFS mantêm o estado entre jobs. As métricas por job e os relatórios de custos seguem para CloudWatch e OpenTelemetry.

Complementos de segurança. Uma integração com o StepSecurity Harden-Runner acrescenta monitorização e filtragem de egress e deteção de adulteração do código-fonte durante o build, com uma licença enterprise da StepSecurity.

Preço e dimensionamento

Apenas na computação, o RunsOn em instâncias spot custa uma fração dos $0.004 por minuto com 2 vCPU do CRACI. A comparação não se faz, porém, apenas ao minuto. Com o RunsOn, paga também a licença e os serviços da AWS em torno dos runners, como NAT gateways para IP estáticos, e a sua equipa fica responsável pela stack: atualizações, quotas da AWS e incidentes. O CRACI tem um único preço por minuto, medido ao segundo, sem mensalidade, e é o CRACI que opera a infraestrutura. Consulte os preços do CRACI para as condições atuais e runners geridos vs self-hosted para uma análise mais ampla das contrapartidas.

Em velocidade, o CRACI executa builds cerca de duas vezes mais depressa do que os runners alojados no GitHub, graças a hardware mais rápido, tempos de fila mais curtos e cache. A velocidade do RunsOn depende do tipo de instância que escolher. Não comparámos os dois em testes de desempenho.

Onde o CRACI é diferente

Um registo do que o build obteve

Enquanto cada job corre, um proxy que reconhece pacotes regista o tráfego para fontes de pacotes: npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk e Git, além de predefinições de descarga. A evidência das dependências acompanha as caches de CI, pelo que os pacotes restaurados de uma cache continuam a ser contabilizados. Isto inclui as dependências ocultas que nenhum lockfile lista, como código transferido por hooks de instalação ou scripts de build, e as camadas da imagem base. Cada job produz uma SBOM CycloneDX ou SPDX com um estado de completude por job e por cache.

Controlo sobre o que o build pode alcançar

Os security groups decidem que redes um runner do RunsOn pode alcançar; não sabem que registo de pacotes um job deve usar. A política de egress do CRACI sabe: negação ou permissão por defeito, 24 predefinições integradas de fontes de software, fontes personalizadas tipadas para npm, PyPI, apt, apk, o proxy de Go, Nix, Cargo, registos OCI e Git sobre HTTPS e SSH, e regras explícitas de TLS, TCP, UDP e ICMP. As políticas são validadas antes de o job arrancar, falham em modo fechado e enviam um alerta em caso de violação. Como a política permite apenas aquilo de que o build precisa, bloqueia a exfiltração para hosts de que o build não precisa, mesmo num ataque que ninguém viu antes.

O Harden-Runner no RunsOn vai mais longe num ponto: vigia também a modificação de ficheiros de código-fonte durante o build, o que o CRACI não faz.

Proveniência e monitorização

A API devolve SBOM, traços de rede e proveniência. O CRACI não assina a proveniência e não reivindica nenhum nível SLSA. Agrega vulnerabilidades de todos os builds e repositórios e continua a reavaliar as SBOM monitorizadas.

Duas perguntas de segurança diferentes

O RunsOn responde a "quem guarda o meu código, os meus segredos e o estado dos runners?" mantendo tudo isso na sua conta AWS. O CRACI responde a outra pergunta: "o que trouxe este build e a que se ligou?" O CRACI executa cada job na sua própria VM isolada, não guarda o seu código-fonte e tem certificação ISO 27001. A segunda resposta é a que um auditor, um cliente ou o Cyber Resilience Act lhe pede.

Marque uma demo para ver a SBOM, o traço de rede e a proveniência de um dos seus próprios workflows.

Qual se adequa melhor

O RunsOn é a melhor opção quando

• Os runners têm de correr dentro da sua própria conta AWS, junto dos seus recursos da VPC.
• O custo de computação mais baixo é o que mais importa, e está à vontade para operar uma stack na AWS.
• Precisa hoje de runners Windows, instâncias com GPU ou tipos específicos de instância EC2.
• Os seus projetos não são comerciais, caso que o RunsOn cobre gratuitamente.

O CRACI é a melhor opção quando

• Distribui software em que tem de mostrar o que entrou em cada versão, a partir do próprio build.
• Quer restringir o que os builds podem alcançar, com uma política que falha em modo fechado e não exige licença adicional.
• Precisa de monitorizar o que foi distribuído, sem acrescentar ferramentas a cada workflow.
• Prefere não operar infraestrutura de CI e quer builds em infraestrutura europeia.

O que abdica com o CRACI. Runners na sua própria conta AWS, que estão no roadmap para o Enterprise, runners Windows, também no roadmap, e a fatura de computação mais baixa. O que ganha é um registo do build que as equipas de segurança e conformidade podem usar sem outro scanner no pipeline, em infraestrutura que não tem de operar.

Para o Cyber Resilience Act

O Cyber Resilience Act da UE espera que os fabricantes saibam o que está em cada versão e tratem as respetivas vulnerabilidades, com obrigações de reporte a partir de setembro de 2026 e aplicação plena a partir de dezembro de 2027. Um runner self-hosted não produz essas evidências por si só; teria de acrescentar ferramentas de SBOM e de análise aos seus workflows. O CRACI produz essas evidências a partir do registo do build e exporta SBOM em CycloneDX ou SPDX. Automatiza uma parte significativa da visibilidade da cadeia de abastecimento de software e das evidências de que as empresas precisam para o seu processo mais amplo de conformidade com o CRA.

Migrar do RunsOn

O CRACI substitui o runner, não o GitHub Actions. Os workflows e a interface do GitHub ficam iguais, e a etiqueta do job passa a ser runs-on: craci. Os jobs têm Docker Engine, Buildx e Compose v2, uma imagem Ubuntu 24.04 compatível com o GitHub e virtualização aninhada em x86-64. Saiba mais sobre a integração de CI/CD e a geração de SBOM durante o build. As startups podem candidatar-se ao programa para startups.

RunsOn vs CRACI: perguntas frequentes

Preços, alojamento, plataformas e segurança, com base na informação publicada por cada fornecedor

O que é o RunsOn?

O RunsOn são runners self-hosted de GitHub Actions em forma de produto. Implementa uma stack CloudFormation ou um módulo Terraform na sua própria conta AWS, e o RunsOn lança uma nova instância EC2 para cada job e encerra-a quando o job acaba. Os runners, as caches, os registos e as credenciais ficam na sua conta AWS. Foi fundado em 2023 por Cyril Rohr, radicado em Rennes, França.

Quanto custa o RunsOn?

Em setembro de 2026, o RunsOn cobra uma licença anual fixa por entidade jurídica: a partir de cerca de $348 (€300) por ano no Starter, cerca de $1,044 (€900) no Growth, cerca de $2,088 (€1,800) no Scale e cerca de $4,176 (€3,600) no Enterprise, consoante o número de runners que lança por mês. A AWS fatura diretamente a computação, ao segundo, sem margem do RunsOn. O RunsOn indica uma instância spot x64 de 2 vCPU em us-east-1 a cerca de $0.0009 por minuto. É gratuito para uso não comercial e tem um teste de 15 dias.

O RunsOn é mais barato do que o CRACI?

Na computação, sim, e por uma larga margem em instâncias spot. O CRACI cobra $0.004 por minuto com 2 vCPU, enquanto uma instância spot de 2 vCPU através do RunsOn custa cerca de $0.0009 por minuto em us-east-1, mais a licença. O total inclui também a rede e o armazenamento da AWS e o tempo para operar a stack. O que o CRACI acrescenta no runner é o registo do build: uma SBOM para cada job, uma política de egress, dados de proveniência e monitorização de vulnerabilidades.

O RunsOn gera SBOM ou proveniência de build?

Não consta das suas funcionalidades documentadas. O RunsOn concentra-se em computação, cache, custos e observabilidade na sua conta AWS. O CRACI regista os pacotes que cada job obtém, incluindo os restaurados de caches, e produz uma SBOM CycloneDX ou SPDX com um estado de completude. A API devolve SBOM, traços de rede e proveniência.

O RunsOn pode restringir o que um build alcança na rede?

Os runners do RunsOn ficam na sua VPC, pelo que se aplicam os security groups e o encaminhamento da AWS, e os IP de egress estáticos vêm de NAT gateways. Para a filtragem de egress dentro do job, o RunsOn integra o StepSecurity Harden-Runner, que constrói uma linha de base do tráfego de saída de cada job e pode aplicá-la como lista de permissões; no RunsOn, exige uma licença enterprise da StepSecurity. O CRACI aplica uma política de egress no próprio runner: negação ou permissão por defeito, 24 predefinições integradas de fontes de software, validada antes de o job arrancar e com falha em modo fechado.

Posso executar o CRACI na minha própria conta AWS?

Hoje não. Os runners do CRACI são geridos, em infraestrutura europeia, e os runners alojados pelo cliente estão no roadmap para o plano Enterprise. Se os runners dentro da sua própria conta AWS forem um requisito absoluto, o RunsOn foi feito exatamente para isso.

O CRACI suporta runners Windows ou macOS?

O CRACI executa hoje Linux em x86-64 e ARM64, com Windows e macOS no roadmap. O RunsOn oferece Windows Server 2022 e 2025 e instâncias com GPU; com o RunsOn, os jobs macOS também ficam em runners alojados no GitHub.

Tenho de reescrever os meus workflows de GitHub Actions para mudar?

Não. Ambos os produtos substituem o runner, não o GitHub Actions. Os workflows, os triggers e a interface do GitHub ficam iguais; no CRACI, a etiqueta do job passa a ser runs-on: craci.