Package Manager and Build Tool Commands

JFrog CLI integrates with popular build tools to resolve dependencies from Artifactory, deploy artifacts, and collect build information — all through a consistent interface.

Workflow: Configure, Build, Publish

Every build tool integration follows the same three-step pattern:

Configure the tool (run once per project) using jf <tool>-config.
Build with the tool, optionally collecting build-info using jf <tool> <command> --build-name=<name> --build-number=<number>.
Publish build-info to Artifactory using jf rt build-publish <name> <number>.

Common Build-Info Flags

--build-name and --build-number must always be provided together. When present, the CLI records resolved dependencies and produced artifacts locally, then jf rt build-publish sends that record to Artifactory. Two additional flags are available on all build-tool commands.

Flag	Description
`--project`	Associates the build-info with a JFrog Project
`--module`	Names a logical component within the build-info (for multi-module builds)

Build-Info Enrichment

Before publishing build-info, you can enrich it with environment variables and Git context. The following commands work with any build tool.

Command	Purpose
`jf rt build-collect-env`	Collects environment variables into the build-info
`jf rt build-add-git`	Adds Git commit hash, branch, and message
`jf rt build-add-dependencies`	Adds arbitrary file dependencies
`jf rt build-publish`	Publishes the enriched build-info to Artifactory

In CI/CD pipelines, the recommended sequence after a build is: build-collect-env -> build-add-git -> build-publish. For step-by-step instructions, see Getting Started.

Verifying Your Build

After publishing build-info, you can verify that artifacts and build-info are in Artifactory using jf rt search and jf rt curl. For verification steps, see Getting Started — Verifying Success.

Supported Build Tools

Package Manager	Config Command	Build Command	Publish Command	Build-Info	Native Mode
Maven	`jf mvn-config`	`jf mvn <goals>`	Via `install` goal (or later)	Yes	Yes
Gradle	`jf gradle-config`	`jf gradle <tasks>`	Via publish task	Yes	Yes
npm	`jf npm-config`	`jf npm install` / `ci` / `publish`	`jf npm publish`	Yes	Yes
Yarn	`jf yarn-config`	`jf yarn <command>`	—	Yes	—
pnpm	`jf pnpm-config`	— (config only)	—	—	—
pip	`jf pip-config`	`jf pip install`	Via `jf twine`	Yes	—
Pipenv	`jf pipenv-config`	`jf pipenv install`	Via `jf twine`	Yes	—
Poetry	`jf poetry-config`	`jf poetry <subcommand>`	`jf poetry publish`	Yes	Yes
Twine	Uses pip/pipenv config	`jf twine upload`	`jf twine upload`	Yes	—
Go	`jf go-config`	`jf go <subcommand>`	`jf go-publish`	Yes	—
NuGet	`jf nuget-config`	`jf nuget restore`	—	Yes	—
.NET	`jf dotnet-config`	`jf dotnet restore` / `build`	—	Yes	—
Docker	—	`jf docker pull` / `push` / `build`	`jf docker push`	Yes	Yes
Helm	—	`jf helm <command>`	`jf helm push`	Yes	Native-only
Conan	—	`jf conan <subcommand>`	Via Conan native	Yes	Native-only
Terraform	`jf terraform-config`	`jf terraform`	Via `jf terraform`	Yes	—
Ruby	`jf ruby-config`	— (config only)	—	—	—

Which Python tool? Use jf pip for requirements.txt projects, jf pipenv for Pipfile projects, or jf poetry for pyproject.toml projects. pip and Pipenv publish via jf twine; Poetry publishes with jf poetry publish.

For tools with Native Mode support, see the Native Mode page for setup and when to use each mode.

Why Use JFrog CLI Instead of Native Build Tools?

Running builds through JFrog CLI (for example, jf npm install instead of npm install) provides:

Dependency resolution from Artifactory — reproducible builds and organizational caching.
Build information collection — automatic record of resolved dependencies and produced artifacts.
Security scanning — integrates with JFrog Xray for vulnerability analysis.
Audit trail — every build is traceable: who built it, what sources, which dependencies.

If you don't need these features, use native tools pointed at Artifactory directly, or enable Native Mode for supported tools.

Common Prerequisites

All build tool commands share these prerequisites. Individual tool pages list tool-specific requirements.

JFrog CLI installed — Installation guide
JFrog CLI authenticated — Run jf config add (or jf c add) to configure your Artifactory server connection
Native build tool installed — The package manager itself must be installed on the machine (for example, mvn, npm, go, docker, or pip)
Artifactory repositories — The repositories referenced in --repo-resolve and --repo-deploy must already exist in Artifactory

Air-gapped or offline? See Air-Gapped and Offline Setup for Maven and Gradle extractor configuration.

Debugging Build Tool Commands

If a build tool command fails or behaves unexpectedly, enable debug logging to see detailed output:

export JFROG_CLI_LOG_LEVEL=DEBUG
jf <tool> <command>

Supported log levels: DEBUG, INFO (default), WARN, ERROR.

Frequently Asked Questions

How do I choose the right build tool command?

Match your project's package manager to the corresponding JFrog CLI command. If your project uses pom.xml, use jf mvn. If it uses package.json, use jf npm (or jf yarn/jf pnpm). See the Supported Build Tools table for the full mapping.

What is the difference between `--repo-resolve` and `--repo-deploy`?

--repo-resolve specifies the Artifactory repository used to download dependencies (typically a virtual repository that aggregates local and remote sources). --repo-deploy specifies the repository used to upload artifacts you produce (typically a local repository).

Do I need to run `*-config` every time I build?

No. Run the config command once per project. It creates a .jfrog/projects/<tool>.yaml file that persists across builds. Re-run only when changing repository assignments.

Can I use JFrog CLI in CI/CD pipelines?

Yes. Pass all flags non-interactively to *-config commands for automated setup. In GitHub Actions, use the jfrog/setup-jfrog-cli action. For Jenkins and GitLab CI, configure the server with jf config add using environment variables.

What is build-info and why should I collect it?

Build-info is a JSON record of every dependency resolved and artifact produced during a build. Publishing it to Artifactory (via jf rt build-publish) enables dependency traceability, build promotion, and JFrog Xray vulnerability scanning across your entire supply chain.

Glossary

Term	Definition
Server ID	A local alias for a JFrog Platform connection, created with `jf config add`. Each server ID stores a URL, authentication credentials, and an optional default flag. Config commands reference server IDs via `--server-id-resolve` and `--server-id-deploy`.
Virtual Repository	An Artifactory repository that aggregates multiple local and remote repositories under a single URL. Used for dependency resolution (e.g., `--repo-resolve`). Example: `npm-virtual` combines `npm-local` and `npm-remote`.
Local Repository	An Artifactory repository for storing your own artifacts. Used for deployment (e.g., `--repo-deploy`). Example: `npm-local`.
Remote Repository	An Artifactory repository that proxies and caches packages from an external source (e.g., npmjs.org, Maven Central, PyPI). Typically included behind a virtual repository.
Build-Info	A JSON object that records which dependencies were resolved and which artifacts were produced during a build. Collected with `--build-name` and `--build-number`, then published to Artifactory with `jf rt build-publish`. Build-info enables traceability, promotion, and Xray scanning.
`.jfrog/projects/` directory	A directory created in your project root by `*-config` commands. Contains YAML files (e.g., `maven.yaml`, `npm.yaml`) that store repository associations. Committed to version control so all team members share the same configuration.
Xray Scan	A security scan that checks dependencies or Docker images against JFrog Xray vulnerability databases and policies. Triggered with `--scan` (for build tools) or `jf docker scan` (for containers). Note: the legacy `jf rt build-scan` command is deprecated; use the Xray-based build scan instead.