CRACI vs Jenkins

A resposta curta

O Jenkins apresenta-se como "the leading open source automation server", e com razão: corre onde quer que o instale, distribui o trabalho por tantas máquinas quantas lhe der, e mais de 2.300 plugins da comunidade ligam-no a quase qualquer ferramenta. Se os builds têm de ficar inteiramente dentro da sua própria rede, ou se os seus pipelines dependem de plugins sem equivalente noutro lado, o Jenkins é difícil de substituir.

O CRACI é um tipo de produto diferente. É um runner gerido para GitHub Actions: não há controlador para atualizar nem agente para corrigir. Enquanto cada job corre, o CRACI regista todas as dependências externas que o build obtém, aplica uma política de egress à rede do build e produz SBOM, dados de proveniência e monitorização de vulnerabilidades a partir desse registo. O Jenkins consegue fazer partes disto através de plugins que escolhe, configura e mantém atualizados; o CRACI faz do próprio runner o registo de segurança.

Há um ponto prático que vem primeiro. O CRACI suporta hoje GitHub Actions, com Jenkins e GitLab CI no roadmap e sem data. Para correr hoje no CRACI, um pipeline Jenkins passa primeiro para um workflow de GitHub Actions.

Visão geral

O que o Jenkins faz bem

Corre onde precisa. O Jenkins corre nos seus próprios servidores, na sua própria rede, sem nenhum plano de controlo SaaS envolvido. Os agentes podem ser Linux, Windows, macOS ou qualquer outra máquina que consiga ligar, pelo que um só controlador pode construir um backend, um cliente de desktop e firmware.

Plugins para quase tudo. O ecossistema de plugins é o maior ponto forte do Jenkins. Controlo de código-fonte, ferramentas de build, relatórios de testes, destinos de implementação e scanners de segurança têm todos plugins, e as equipas com toolchains invulgares descobrem muitas vezes que o Jenkins é a única CI que já as suporta.

Sem custo de licença. O Jenkins é gratuito e open source. Os seus custos são as máquinas em que corre e o tempo que a sua equipa gasta a operá-lo.

Onde o CRACI é diferente

Nada para operar

Uma instalação Jenkins é um sistema que pertence à sua equipa: o controlador, os agentes, os plugins e as atualizações. O projeto Jenkins publica com frequência avisos de segurança para o core e para plugins, vários por mês em 2026 (por exemplo, a 2 e 16 de setembro e a 5 de agosto), e aplicar cada um deles é tarefa sua. O CRACI executa jobs em runners geridos, em máquinas virtuais isoladas com uma VM por job, pelo que não há nenhum servidor de build para corrigir.

A SBOM vem do build

No Jenkins, uma SBOM vem de um plugin ou de um passo de scanner que adiciona, que normalmente lê manifestos e lockfiles a posteriori. Os builds fazem muitas vezes mais do que esses ficheiros dizem: scripts de instalação transferem código, scripts de build obtêm elementos durante o build, e as caches restauram pacotes que nenhum lockfile menciona. O CRACI vê esse tráfego porque é o runner. Um proxy que reconhece pacotes regista o que cada job obtém de origens de pacotes, em origens npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk e Git, e a evidência das dependências acompanha as caches de CI. Cada SBOM CycloneDX ou SPDX indica quão completa é, por job e por cache.

Uma política na rede do build

No Jenkins, controlar o que um build pode alcançar significa regras de firewall ou proxies em torno dos seus agentes, que concebe e mantém. No CRACI, uma política de egress em cada job decide que hosts pode alcançar: negação ou permissão por defeito, com 24 predefinições integradas de origens de software e origens personalizadas tipadas, validadas antes de o job arrancar. As políticas falham em modo fechado, e as violações enviam um alerta.

Monitorizar o que foi distribuído

A API devolve SBOM, traços de rede e proveniência. O CRACI agrega vulnerabilidades de todos os builds e repositórios, continua a reavaliar as SBOM monitorizadas à medida que surgem avisos de segurança e mostra que builds anteriores continham uma dependência vulnerável, para que saiba durante que período esteve afetado.

Preços por minuto de build

O Jenkins não tem custo de licença, mas não é gratuito de operar: paga o controlador e os agentes, parados ou ocupados, e as pessoas que os mantêm atualizados. O CRACI cobra apenas os minutos de build: $0.002 por vCPU-minuto ($0.004 para um runner predefinido de 2 vCPU), medido ao segundo, sem mensalidade e sem custo por SBOM.

Qual é o mais adequado

• Fique com o Jenkins se os builds têm de correr inteiramente na sua própria infraestrutura, se depende de plugins sem equivalente em GitHub Actions, se precisa de builds Windows ou macOS, ou se tem as pessoas para o operar e funciona.
• Escolha o CRACI se o seu código está no GitHub, está a migrar ou pronto para migrar pipelines para GitHub Actions, e quer deixar de operar servidores de build ao mesmo tempo que ganha um registo do que entrou em cada versão.
• Use ambos durante uma migração gradual: passe os novos projetos e os pipelines Linux para GitHub Actions no CRACI e deixe os jobs estáveis do Jenkins onde estão.

Tenha bem presente aquilo de que abdica ao escolher hoje o CRACI. Executa apenas jobs Linux, com Windows e macOS no roadmap; os runners alojados pelo cliente estão no roadmap para Enterprise; e os pipelines Jenkins têm de se tornar workflows de GitHub Actions até o suporte de Jenkins chegar.

Para produtos regulados

Referenciais como o Cyber Resilience Act da UE esperam que os fabricantes saibam o que está em cada versão e tratem as suas vulnerabilidades, com obrigações de reporte a partir de setembro de 2026. No Jenkins, essas evidências vêm dos plugins e scanners que ligar a cada pipeline. O CRACI produ-las 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 uma empresa precisa para o seu processo mais amplo de CRA; nenhuma das ferramentas torna um produto conforme por si só.

Migrar um pipeline para o CRACI

O próprio GitHub Actions Importer do GitHub converte pipelines Jenkins em workflows de GitHub Actions. O GitHub aponta para a conversão automática de 80% de cada workflow e diz que cada workflow convertido deve ser inspecionado antes de correr em produção, por isso conte com algum trabalho manual. Quando um pipeline corre como workflow de GitHub Actions, corre no CRACI com uma linha:

runs-on: craci

As execuções continuam a aparecer na interface do GitHub. Saiba mais sobre a geração de SBOM durante o build, veja as alternativas ao Jenkins, compare plataformas de CI/CD ou consulte os preços.