Need help with other JFrog products?
Using the latest JFrog Artifactory version? See the documentation here.
Deploying a Single Artifact
To deploy a single artifact, simply fill in the fields in the Deploy dialog and click "Deploy".
Deploying According to Layout
The Deploy dialog displays the repository package type and layout configured. To deploy your package according to the configured layout, check Deploy According to Layout.
Artifactory displays entry fields corresponding to the layout tokens for you to fill in.
If you are deploying a Maven artifact, you may need to configure additional attributes as described in the next section.
Suggested Target Path
Artifactory will suggest a Target Path based on the details of your artifact (this works for both Maven and Ivy). For example, if a JAR artifact has an embedded POM under its internal
META-INF directory, this information is used.
Deploying Maven Artifacts
If you are deploying an artifact that conforms to the Maven repository layout, you should set Deploy as Maven Artifact to expose fields that specify the corresponding Maven attributes - GroupID, ArtifactID, Version, Classifier and Type.
The fields are automatically filled in according to the artifact name, however you can edit them and your changes will also be reflected in the Target Path.
If your target repository does not include a POM, set Generate Default POM/Deploy Jar's Internal POM, to use the POM within the artifact you are deploying, or generate a default POM respectively.
Take care when editing the POM manually
If you are editing the POM manually, be very careful to keep it in a valid state.
Deploying with Properties
Properties can be attached to the uploaded file by specifying them on the Target Path.
First, unset the Deploy as Maven Artifact check box, if necessary.
Then, in the TargetPath field, add the properties delimited from the path and from each other by semicolons.
For example, to upload an artifact with the property qa set to "passed", and build.number set to "102", use the following Target Path:
Deploying with Multiple Properties
To deploy multiple values to the same key add the same key again with the new value, e.g.
key1=value1;key1=value2 will deploy the file with property
key1 with value of
For example, to upload a file with property passed and values qa, stress use the following Target Path:
Deploying Multiple Files
To deploy multiple files together, set the deploy Type to Multi, fill in the rest of the fields in the dialog and click "Deploy".
Deploying an Artifact Bundle
An artifact bundle is deployed as a set of artifacts packaged in an archive with one of the following supported extensions: zip, tar, tar.gz, tgz.
When you specify that an artifact should be deployed as a bundle, Artifactory will extract the archive contents when you deploy it.
File structure within the archive
Artifacts should be packaged within the archive in the same file structure with which they should be deployed to the target repository.
To deploy an artifact bundle, in the Deploy dialog, first upload the archive file you want to deploy.
Check the Deploy as Bundle Artifact checkbox and click Deploy.
Deploying to a Virtual Repository
From version 4.2, Artifactory supports deploying artifacts to a virtual repository.
To enable this, you first need to designate one of the local repositories that is aggregated by the virtual repository as a deployment target. This can be done through the UI by setting the Default Deployment Repository in the Basic Settings of the Edit Repository screen.
You can also set the Default Deployment Repository using the
defaultDeploymentRepo parameter of the Virtual Repository Configuration JSON used in the Create or Replace Repository Configuration and Update Repository Configuration REST API endpoints. Once the deployment target is configured, you may deploy artifacts to it using any packaging format client configured to work with Artifactory. For example,
docker push, npm publish, NuGet push, gem push etc.
You can also use Artifactory's REST API to deploy an artifact and use the virtual repository key in the path to deploy.
From version 4.4, if you do specify a Default Deployment Repository for a virtual repository, the corresponding Set Me Up dialog for the repository will also include instructions and code snippets for deploying to that repository.
The most common reasons for a rejected deployment are:
- Lack of permissions
- A conflict with the target repository's includes/excludes patterns
- A conflict with the target repository's snapshots/releases handling policy.