CRACI and JFrog Artifactory

Two vantage points on the same supply chain

Many engineering organizations route package traffic through JFrog Artifactory. A remote repository acts as a caching proxy for a public registry such as npm or PyPI, fetching packages on demand and keeping a copy. Virtual repositories combine several sources behind one URL. Your own build outputs live in local repositories. That gives you one place to see and govern what enters the company.

CRACI sits somewhere else. It is the CI runner your GitHub Actions jobs run on, and while each job runs it records the external dependencies the job pulls in. Artifactory answers "what has flowed through our repositories?" CRACI answers "what did this specific build use, and which artifact came out of it?"

What Artifactory does well

Artifactory is a mature repository manager. It gives teams reliable, cached access to upstream packages, a home for internal artifacts, and a single control point for many package types. Around it, the JFrog Platform adds more:

• Build-info. With the JFrog CLI, you add a build name and number to your commands and publish a JSON record of the dependencies resolved, artifacts produced, environment variables and Git details. That record supports traceability, build promotion and Xray scanning.
• Xray. Scans artifacts and builds for vulnerabilities and exports SBOMs in SPDX and CycloneDX. JFrog's license matrix lists Xray as included in Pro X, Enterprise X and Enterprise+ subscriptions (as of September 2026).
• Curation. Blocks malicious or vulnerable packages at the remote repository before they reach developers, including packages already in the remote cache.

Package-level blocking at the registry is a real strength. CRACI does not block individual packages today; organization-wide package blocklisting is on the CRACI roadmap.

Where CRACI adds to it

Visibility that does not depend on routing

Artifactory sees what is routed through it. Builds do not always cooperate. A job may download a toolchain from a GitHub release, install OS packages, pull a base image from a public registry, or run a script that fetches a binary. JFrog's own documentation notes that dependencies fetched by other tools can be registered manually with build-add-dependencies, which means someone has to know about them.

CRACI records at the runner. A package-aware proxy observes traffic to package sources during the job, covering npm, PyPI, RubyGems, Cargo, Go, Nix and OCI, plus OS packages and source or download presets. If your npm or PyPI installs go through an Artifactory mirror, that works: CRACI records those packages too.

Per-build evidence without extra steps

Build-info is valuable, but it is something you add to each pipeline. On CRACI, the record exists for every job because the runner produces it. Dependency evidence travels with CI caches, so a package restored from a cache is still counted. Every SBOM carries a completeness state per job and per cache: Complete, Complete with connections, Incomplete, Unavailable or Not recorded. When a record has a gap, it says so.

Keep builds on the approved path

Because CRACI runs the job, you can set its network egress policy. Policies are default deny or default allow, with 24 built-in software-source presets, typed custom sources (npm, PyPI, apt, apk, the Go proxy, Nix, Cargo, OCI registries and Git) and explicit TLS, TCP, UDP and ICMP rules. They are validated before the job starts and fail closed. A policy that allows your Artifactory host and denies direct access to public registries helps make sure builds actually use the governed route. CRACI emails you when a job violates its policy.

Deployment context for each artifact

CRACI signs provenance that links each artifact, including OCI artifacts, to the build that produced it. Through the API you can trace an artifact to its producing build, its CycloneDX SBOM and the job network trace. Store the artifact in Artifactory as you do today; the evidence of how it was built comes from CRACI.

For teams facing the EU Cyber Resilience Act, that record feeds release-level evidence. CRACI aggregates vulnerabilities across builds and repositories, re-evaluates monitored SBOMs continuously, and exports reports in PDF, HTML, CSV, Excel and JSON. See compliance reports and CRA compliance.

How they fit together

1. Keep Artifactory as your package proxy, artifact store and release distribution point.
2. Move GitHub Actions jobs to CRACI by changing runs-on to craci. Workflows stay the same, and runs still appear in the GitHub UI.
3. Point npm and PyPI installs at your Artifactory mirrors as you do today.
4. Use a CRACI egress policy to keep builds on approved sources, including Artifactory.
5. Use CRACI's per-build SBOM, provenance and network trace as the evidence for each release.

If you rely on JFrog build-info or Curation today, keep them. CRACI supports GitHub Actions only, so pipelines on other CI systems stay where they are.

Common questions

Does CRACI replace Artifactory?

No. CRACI is not a repository manager. It does not store your packages or release binaries, and it does not distribute them. It runs your builds and records evidence about them.

Does CRACI overlap with Xray?

Partly. Both export SBOMs in CycloneDX and SPDX and both help you track vulnerabilities. The difference is the input. Xray scans the artifacts and builds that JFrog knows about. CRACI's SBOM and vulnerability view come from what each build fetched while it ran, across builds and repositories. If Xray is embedded in your release process, keep it and treat CRACI's per-build record as a second, independent source.

Which Artifactory repository types work with CRACI?

Artifactory npm and PyPI mirrors are confirmed to work with CRACI builds. For other package types, talk to us about your setup before you move those pipelines.