CRACI vs WarpBuild

A resposta curta

O WarpBuild é um fornecedor de runners de GitHub Actions. Oferece runners alojados em Linux, Windows e macOS, uma cache rápida, snapshot runners, builders Docker remotos e uma opção bring-your-own-cloud (BYOC) que executa os mesmos runners na sua conta AWS, GCP ou Azure. Se quer a mais ampla cobertura de plataformas de um só fornecedor de runners, ou runners dentro da sua própria cloud, o WarpBuild é uma opção forte.

O CRACI é um runner compatível com GitHub Actions construído em torno da segurança da cadeia de abastecimento: cada job produz uma SBOM do que obteve e corre sob uma política de egress. O WarpBuild compete em velocidade, preço e no local onde o runner reside; o CRACI naquilo que o runner regista e controla. Ambos substituem o runner alojado no GitHub, pelo que terá de escolher um.

Visão geral

O que o WarpBuild faz bem

• Plataformas e tamanhos. Runners Linux em x86-64 (Ubuntu 22.04, 24.04 e 26.04) e arm64 (24.04 e 26.04) de 2 vCPU e 8 GB de RAM até 32 vCPU e 128 GB, runners Windows Server 2022 e 2025 a partir de 4 vCPU, macOS 14, 15 e 26 em Apple M4 Pro, e runners Linux arm64 em Apple Silicon. A virtualização aninhada está disponível em Linux x86-64.
• Isolamento. Cada runner é uma máquina virtual efémera, criada para o job e destruída depois, com o seu próprio volume de armazenamento cifrado. O WarpBuild diz que não acede ao seu código nem guarda segredos de build.
• Cache e Docker. Uma cache sem limite de tamanho, faturada a $0.20 por GB-mês nos runners alojados, cache de camadas de contentores, snapshot runners que restauram um estado preparado da máquina e builders Docker remotos com builds nativos amd64 e arm64 que também funcionam a partir de outros sistemas de CI.
• Bring your own cloud. O BYOC executa runners geridos pelo WarpBuild na sua própria conta AWS, GCP ou Azure, em qualquer região, com IP estáticos, instâncias spot, discos em standby e imagens de VM personalizadas. O WarpBuild tabela os runners BYOC Linux e Windows a $0.002 por minuto, com extras gratuitos, além do que paga ao seu fornecedor de cloud.
• Enterprise. SOC 2 Type II a cobrir segurança, disponibilidade e confidencialidade, infraestrutura específica por região, SAML SSO, SCIM, um SLA de disponibilidade de 99,9% garantido por créditos, warm pools que iniciam jobs em menos de 10 segundos, depuração por SSH e suporte para GitHub Enterprise Server.

Quanto à velocidade, o WarpBuild anuncia builds duas vezes mais rápidos do que os runners alojados no GitHub, e de duas a dez vezes mais rápidos na sua página de preços. Estas afirmações são do WarpBuild, e não comparámos o CRACI com o WarpBuild em benchmark; o seu próprio pipeline é o teste justo.

Preço e dimensionamento

Em x86-64, os dois têm o mesmo preço de tabela por minuto, $0.004 com 2 vCPU e $0.064 com 32 vCPU. O preço do WarpBuild em arm64 é mais baixo, porque o CRACI cobra ARM64 à mesma tarifa que x86-64. O BYOC transfere o custo de computação para a sua própria fatura de cloud. O CRACI mede ao segundo e não ao minuto, pelo que os jobs curtos são faturados pelos segundos que correm. A memória por vCPU também difere (3 GB no CRACI, 4 GB no WarpBuild Linux), por isso ajuste-a às necessidades dos seus builds antes de comparar. Consulte os preços do CRACI para as condições atuais.

Onde o CRACI é diferente

O CRACI trata o build como a fonte de verdade daquilo que lança.

Um registo do que o build obteve

Durante a execução de cada job, um proxy que reconhece pacotes regista o tráfego para as fontes de pacotes: fontes npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk e Git, bem como predefinições de descarga. As evidências de dependências acompanham as caches de CI, pelo que um pacote restaurado de uma cache continua a ser contabilizado. A SBOM de cada job, em CycloneDX ou SPDX, indica um estado de completude por job e por cache, para que saiba quando o registo está completo e quando não está.

Uma política de egress que vem com o runner

As políticas do CRACI são de negação ou permissão por defeito, com 24 predefinições integradas de fontes de software, fontes personalizadas tipadas para npm, PyPI, apt, apk, o proxy Go, Nix, Cargo, registos OCI e Git por 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. Os runners do CRACI usam também um intervalo estável de IP de egress.

A documentação do WarpBuild não descreve uma política de egress por job para os seus runners alojados. Com BYOC, os runners ficam na sua própria rede, e o guia de reforço de segurança para AWS do WarpBuild mostra como apertar as regras de saída com os seus próprios security groups, listando os endpoints de que um runner precisa. Funciona, mas é infraestrutura de rede que mantém na sua conta de cloud, e não uma política associada ao job.

Proveniência e monitorização

• Dados de proveniência. 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.
• Monitorização do que foi lançado. As SBOM monitorizadas são reavaliadas continuamente face a novas vulnerabilidades, e as conclusões são agregadas entre builds e repositórios.

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 WarpBuild é a melhor opção quando

• Precisa de runners macOS ou Windows. O CRACI é hoje apenas Linux; Windows e macOS estão no roadmap.
• Quer runners na sua própria conta AWS, GCP ou Azure. O CRACI ainda não oferece runners alojados pelo cliente; estão no roadmap para o Enterprise.
• Usa o GitHub Enterprise Server, que o CRACI hoje não suporta.
• Depende hoje de snapshot runners ou de builders Docker remotos.
• O custo por minuto mais baixo em arm64 ou BYOC é o objetivo principal.

O CRACI é a melhor opção quando

• Precisa de mostrar o que entrou numa versão, com um estado de completude, a partir do próprio build.
• Quer uma política de egress associada a cada job sem a construir na sua rede de cloud.
• Quer monitorizar as SBOM do que foi lançado.
• Precisa de residência de dados na UE, disponível no plano Enterprise do CRACI.

O que perde com o CRACI. Os jobs Windows e macOS, os runners na sua própria cloud e o GitHub Enterprise Server, tudo o que o WarpBuild oferece hoje, além dos preços mais baixos em arm64 e BYOC. O que ganha é um registo de build que as equipas de segurança e de conformidade podem usar sem mais um scanner no pipeline.

Para o Cyber Resilience Act

O Cyber Resilience Act pede aos fabricantes que conheçam os componentes dos seus produtos, tratem as vulnerabilidades neles presentes e guardem evidências. O produto do WarpBuild é infraestrutura de CI. O CRACI automatiza uma parte significativa da visibilidade e das evidências da cadeia de abastecimento de software de que as empresas precisam para o seu processo mais amplo de conformidade com o CRA: SBOM durante o build exportadas em CycloneDX ou SPDX, acompanhamento de vulnerabilidades e proveniência através da API. Consulte evidências para o CRA.

Migrar do WarpBuild

O CRACI substitui o runner, não o GitHub Actions. Os workflows e a interface do GitHub mantêm-se, 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 com CI/CD e a geração de SBOM durante o build.

WarpBuild vs CRACI: perguntas frequentes

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

O que é o WarpBuild?

O WarpBuild é um fornecedor de runners de GitHub Actions. Executa os seus jobs em runners Linux, Windows e macOS próprios, ou em runners geridos pelo WarpBuild dentro da sua conta AWS, GCP ou Azure (BYOC). Vende também builders Docker remotos, snapshot runners e uma cache para artefactos e camadas de contentores.

Quanto custa o WarpBuild?

Em setembro de 2026, os runners Linux alojados do WarpBuild custam $0.004 por minuto para 2 vCPU em x86-64 e $0.003 em arm64, chegando a $0.064 e $0.048 com 32 vCPU. O Windows começa em $0.016 por minuto para 4 vCPU e o macOS em M4 Pro em $0.08 para 6 vCPU. Os runners BYOC custam $0.002 por minuto além da sua fatura de cloud. O armazenamento em cache custa $0.20 por GB-mês, e a faturação é ao minuto.

O WarpBuild é mais barato do que o CRACI?

Em arm64, sim; em x86-64, o preço de tabela é o mesmo. O CRACI cobra $0.004 por minuto com 2 vCPU tanto em x86-64 como em ARM64, contra os $0.004 do WarpBuild em x86-64 e $0.003 em arm64. Com 32 vCPU, ambos têm um preço de tabela de $0.064 por minuto em x86-64. O WarpBuild apresenta o BYOC como a sua opção mais barata em grande escala, já que o cliente paga $0.002 por minuto mais a sua própria fatura de cloud. O CRACI mede ao segundo e não ao minuto, pelo que os jobs curtos são faturados pelos segundos que correm. 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 que é o WarpBuild BYOC, e o CRACI pode correr na minha própria cloud?

O BYOC executa runners geridos pelo WarpBuild na sua própria conta AWS, GCP ou Azure, em qualquer região, com IP estáticos, instâncias spot, discos em standby e imagens de VM personalizadas. O CRACI executa hoje runners geridos em infraestrutura europeia, com runners alojados pelo cliente no roadmap para o Enterprise.

O WarpBuild gera SBOM ou proveniência de build?

Não consta das funcionalidades documentadas. O WarpBuild foca-se em computação, cache e no local onde o runner reside. O CRACI regista os pacotes que cada job obtém, incluindo pacotes 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 WarpBuild pode restringir o que um build alcança na rede?

A documentação do WarpBuild não descreve uma política de egress por job para os seus runners alojados. Com BYOC, os runners ficam na sua própria rede, e o guia de reforço de segurança para AWS do WarpBuild mostra como apertar as regras de saída com os seus próprios security groups. O CRACI aplica uma política de egress no runner em cada job: 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.

O CRACI suporta Windows, macOS ou GitHub Enterprise Server?

Hoje não. O CRACI executa Linux em x86-64 e ARM64, com Windows e macOS no roadmap, e não suporta o GitHub Enterprise Server. O WarpBuild oferece runners Windows e macOS, e suporte para GitHub Enterprise Server no seu plano enterprise.

O WarpBuild está em conformidade com o SOC 2, e onde ficam os dados?

O WarpBuild afirma ter certificação SOC 2 Type 2 para segurança, disponibilidade e confidencialidade, e diz que não acede ao seu código nem aos seus segredos de build. Os planos Enterprise podem manter os dados numa região à escolha. O CRACI executa builds em infraestrutura bare-metal europeia, oferece residência de dados na UE no plano Enterprise, não guarda o seu código-fonte e documenta os controlos de segurança no seu Trust Center.

O WarpBuild é mais rápido do que o CRACI?

O WarpBuild anuncia builds duas vezes mais rápidos do que os runners alojados no GitHub na sua página inicial, e de duas a dez vezes mais rápidos na sua página de preços. Não comparámos o CRACI com o WarpBuild em benchmark, por isso execute o mesmo workflow em ambos e compare.

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 mantêm-se; no CRACI, a etiqueta do job passa a ser runs-on: craci.