CRACI vs Depot

A resposta curta

O Depot é aceleração de builds: runners de GitHub Actions, um serviço remoto de builds Docker com uma cache de camadas persistente, uma cache remota para ferramentas como Bazel e Gradle, e o seu próprio motor de CI. 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 realmente obteve e corre sob uma política de egress definida por si.

A diferença numa frase: o Depot otimiza a velocidade do seu build, e o CRACI regista e controla o que entra nele. Ambos substituem o runner alojado no GitHub, pelo que terá de escolher um.

Visão geral

O que o Depot faz bem

O Depot construiu uma plataforma de runners e de builds ampla e bem documentada. Destaques da sua própria documentação:

• Um catálogo alargado de runners. Runners Linux em AMD EPYC (etiquetas Intel) e AWS Graviton4 (Arm), de 2 vCPU e 8 GB de RAM até 64 vCPU e 256 GB, além de Windows Server 2022 e 2025, e runners macOS nos planos Startup e Business.
• Cache. Os runners estão ligados à cache distribuída do Depot, que, segundo o Depot, atinge velocidades de carregamento e de transferência de até 1000 MiB/s. O Depot descreve os seus runners como "up to 3x faster than a GitHub-hosted runner" com "10x faster caching".
• Builds Docker. O depot build é um substituto direto de docker build que corre num host BuildKit remoto com uma cache de camadas NVMe persistente partilhada pela sua equipa, e compila imagens x86 e Arm de forma nativa, sem emulação QEMU. O Depot afirma que isto é até 40x mais rápido do que compilar localmente ou num fornecedor de CI.
• Isolamento. Cada job de GitHub Actions corre numa instância EC2 nova e single-tenant, que nunca é reutilizada.
• Filtragem de egress. Regras de permissão e de negação para IP, CIDR e hostnames, com uma regra predefinida que pode configurar para permitir ou negar. Aplica-se atualmente aos runners Linux.
• Opções empresariais. No plano Business, o Depot Managed implementa o plano de dados na sua própria conta AWS, com AWS PrivateLink, IP de saída estáticos e SSO. O Depot indica um relatório SOC 2 Type II.

Se o tempo de build de imagens Docker é o principal estrangulamento da sua CI, o Depot foi construído exatamente para esse problema.

Onde o CRACI é diferente

O CRACI trata o build como a fonte de verdade daquilo que distribui. O runner é onde essas evidências são recolhidas.

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 origens de pacotes: origens npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk e Git, além de predefinições de transferência. A evidência das dependências acompanha 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, inclui um estado de completude por job e por cache, para que saiba quando o registo está completo e quando não está.

O Depot também pode produzir uma SBOM: acrescente --sbom=true a depot build e gera uma SBOM SPDX com o Syft. Trata-se de uma análise da imagem que o build produziu. O registo do CRACI cobre todo o job, incluindo ferramentas de build e pacotes que nunca chegam a uma imagem, e jobs que nem sequer compilam imagens.

Uma política de egress feita para origens de software

Ambos os produtos permitem bloquear tráfego de saída inesperado de um runner. As políticas do CRACI são de negação ou de permissão por defeito, com 24 predefinições integradas de origens de software, origens 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 começar, falham em modo fechado e enviam um alerta em caso de violação. As regras do Depot funcionam ao nível de IP, CIDR e hostnames, o que é mais simples de compreender se for tudo aquilo de que precisa.

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. Os builds de imagens do Depot podem incluir atestações de proveniência BuildKit, definidas com a flag --provenance.
• Monitorização do que foi distribuído. As SBOM monitorizadas são reavaliadas continuamente face a novas vulnerabilidades, e as conclusões são agregadas entre builds e repositórios.

Preço e tamanhos

Em setembro de 2026, o Depot cobra $0.006 por minuto pelo seu runner Linux de 2 vCPU e 8 GB para além dos minutos incluídos no seu plano, e os tamanhos maiores escalam linearmente: 32 vCPU custam $0.096 por minuto. O plano Developer custa $20 por mês com 2.000 minutos de GitHub Actions, e o plano Startup custa $200 por mês com 20.000. O Depot mede a utilização ao segundo, sem mínimo de um minuto por execução, e oferece uma avaliação gratuita de 7 dias.

O CRACI cobra $0.002 por vCPU-minuto, pelo que 2 vCPU custam $0.004 por minuto e 32 vCPU custam $0.064 por minuto, com ARM64 à mesma tarifa. A medição é ao segundo e não há mensalidade. Para além dos minutos do plano do Depot, isso representa cerca de 33% menos por minuto em todos os tamanhos. Ajuste a memória antes de comparar: uma unidade de computação do CRACI tem 3 GB de RAM por vCPU, enquanto os runners do Depot têm 4 GB por vCPU. Consulte os preços do CRACI para as condições atuais.

Qual é o mais adequado

O Depot é a melhor opção quando

• Os builds de imagens Docker dominam o seu tempo de CI.
• Precisa de runners Windows ou macOS. O CRACI é hoje apenas Linux; Windows e macOS estão no roadmap.
• Precisa de runners dentro da sua própria conta AWS. O CRACI ainda não oferece runners alojados pelo cliente; estão no roadmap para o Enterprise.
• Depende de cache remota para Bazel, Gradle, Turborepo ou sccache.

O CRACI é a melhor opção quando

• Precisa de mostrar o que entrou numa versão, a partir do próprio build, com um estado de completude.
• Quer o egress do build controlado por origem de pacotes, validado antes de cada job.
• Quer a monitorização das SBOM distribuídas num só lugar.
• Precisa de residência de dados na UE, disponível no plano Enterprise do CRACI.

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 Depot é infraestrutura de build, e a sua documentação foca-se na velocidade, na cache e no isolamento. O CRACI 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: SBOM durante o build, acompanhamento de vulnerabilidades, proveniência e exportação de SBOM em CycloneDX ou SPDX.

Mudar do Depot para o CRACI

Instale a GitHub App do CRACI na sua organização, com acesso a todos os repositórios ou a um conjunto selecionado, e depois altere a etiqueta do runner num job:

runs-on: craci

Os seus workflows e a interface do GitHub mantêm-se. Mude um job de cada vez, começando por um job que compile algo que distribui. Analise a SBOM e o traço de rede desse job e, depois, escreva uma política de egress que permita as origens de que precisa. Saiba mais sobre a integração com CI/CD e a geração de SBOM durante o build.