Local Repositories

Package Type

The package type must be specified when the repository is created, and once set, cannot be changed.

Repository Key

The repository key is a mandatory, unique identifier for the repository. It cannot begin with a number or contain spaces or special characters.

Stage

Defines one or more stages in which this repository will reside. Stages aggregate project resources (repositories, Pipeline sources, etc.) to simplify their management. For more information, see Stages & Lifecycle.

📘

Note

Defining a stage is mandatory when creating a repository within a specific project. The default selection is DEV.

Repository Layout

Sets the layout that the repository should use for storing and identifying modules. A recommended layout that corresponds to the package type defined is suggested.

Public Description

A free text field that describes the content and purpose of the repository. This description can be viewed by all users with access to the repository.

Internal Description

A free text field to add additional notes about the repository. These notes are visible only to the administrator.

Include and Exclude Patterns

The Include Patterns and Exclude Patterns fields allow you to filter out specific repositories when resolving the location of different artifacts.

In each field, you can specify a list of Ant-like patterns to filter in and filter out artifact queries. Filtering works by subtracting the excluded patterns (default is none) from the included patterns (default is all).

📘

Note

If you remove the "include all" default setting (**/*) by clicking on the X at the right end of the row, the "include all" default setting is removed from the UI but it is still in effect.

Example:

Consider that the Include Patterns and Exclude Patterns for a repository are as follows:

• Include Patterns: org/apache/**,com/acme/**
• Exclude Patterns: com/acme/exp-project/**

In this example, the repository is searched for org/apache/maven/parent/1/1.pom and com/acme/project-x/core/1.0/nit-1.0.jar, but not for com/acme/exp-project/core/1.1/san-1.1.jar because com/acme/exp-project/** is specified as an Exclude pattern.

❗️

Important

Include and exclude patterns apply to regular users. Admin users can see all items regardless of the patterns defined here.

Property Sets

Defines the property sets that will be available for artifacts stored in this repository. For more information, see Property Sets.

Priority Resolution

Setting Priority Resolution takes precedence over the resolution order when resolving virtual repositories. Setting repositories with priority will cause metadata to be merged only from repositories set with this field. If a package is not found in those repositories, Artifactory will merge metadata from the repositories that have not been set with the Priority Resolution field.

📘

Note

The following package types do not support this field: Cargo, Chef, Debian, Git LFS, Ivy, NuGet, Opkg, Pub, Puppet, Swift, Terraform, Vagrant, and HuggingFace ML.

For Docker repositories, Priority Resolution requires the resolveDockerTagsByTimestamp parameter to be set to true.

Disable Artifact Resolution in Repository

If set, Artifactory ignores this repository when trying to resolve artifacts. The repository is also not available for download or deployment of artifacts.

📘

Note

The following package types do not support this field: HuggingFace ML, Debian, Terraform, Terraform BE, Chef, Git LFS, Puppet, Vagrant

Allow Artifact Content Browsing

When set, allows Artifactory users to browse the internal contents of archives (for example, browsing specific Javadoc files from within a Javadoc archive).

When archive browsing is allowed, strict content moderation should be employed to ensure malicious users do not upload content that may compromise security (e.g. cross-site scripting attacks)

Enable CDN Download

Enables CDN Download requests to this repository will redirect the client to download the files directly from AWS CloudFront. Supported for Enterprise+ and Enterprise Licenses. For more information, see JFrog Cloud with CDN Distribution.

📘

Note

The following package types do not support this field: Alpine, Ansible, Cargo, Chef, CocoaPods, Conda, OCI, Gems, Go, Ivy, NuGet, Opkg, Pub, Puppet, SBT, Swift, Terraform BE, HuggingFace ML, Machine Learning

Allow anonymous download and search

The Cargo client does not send credentials when downloading and searching for crates. When this option is selected, anonymous access is allowed to these resources (only).

📘

Note

This option overrides the security anonymous access option.

Enable sparse index support

When selected, this option enables internal index support based on Cargo sparse index specifications, instead of the Git index. For more information, see Index Cargo Repositories Using Sparse Indexing.

Primary Key Name

The name of the GPG primary key used by the repository.

Secondary Key Name

The name of the GPG secondary key used by the repository.

Trivial Layout

When set, the repository will use the deprecated trivial layout.

❗️

Important

Artifactory no longer supports the trivial layout for virtual Debian repositories.

Enable indexing with debug symbols (.ddeb)

When set, it enables the indexing of debug symbols for more efficient debugging.

Optional Index Compression Formats

Used for selecting the index file formats to create in addition to the default Gzip (.gzip extension) format, which is created for every Debian repository and cannot be disabled.

API Version

Select the Docker API version to use, V1 or V2.

📘

Note

OCI does not support Docker v1.

Max Unique Tags

Specifies the maximum number of unique tags, per repository, that should be stored for a Docker image. If the number of tags for an image exceeds this number, older tags will be removed. Leaving the field blank (default) means all tags will be stored. For more information, see Use Max Unique Tags.

Docker Tag Retention

Controls how many overwrites of the same tag are saved in Artifactory. Tag overwriting occurs when you upload a new revision of a tag name that already exists in your repository. For more information, see Use Tag Retention.

Block pushing of image manifest v2 schema 1

When set, Artifactory will block the pushing of Docker images with manifest v2 schema 1 to this repository.

Checksum Policy

The checksum effectively verifies the integrity of a deployed resource. The Checksum Policy determines how Artifactory behaves when a client checksum for a deployed resource is missing or conflicts with the locally calculated checksum.

There are two options:

• Verify against client checksums (default) - If a client has not sent a valid checksum for a deployed artifact then Artifactory will return a 404 (not found) error to a client trying to access that checksum. If the client has sent a checksum, but it conflicts with the one calculated on the server then Artifactory will return a 409 (conflict) error until a valid checksum is deployed.
• Trust server generated checksums - Artifactory will not verify checksums sent by clients and will trust the server's locally calculated checksums. An uploaded artifact is immediately available for use, but integrity might be compromised.

Maven Snapshot Version Behavior

Artifactory supports centralized control of how snapshots are deployed into a repository, regardless of end user-specific settings. This can be used to guarantee a standardized format for deployed snapshots within your organization. There are three options:

• Unique: Uses a unique, time-based version number.

• Nonunique: Uses the default self-overriding naming pattern: artifactID-version-SNAPSHOT.type

• Deployer: Uses the format sent by the deployer as is.

📘

Deployer parameter option

Metadata will not be generated when selecting the Deployer option. This option should not be used when setting up replication, since each Artifactory instance will need to generate its metadata locally.

✅

Maven 3 Only Supports Unique Snapshots

Maven 3 has dropped support for resolving and deploying non-unique snapshots. Therefore, if you have a snapshot repository using non-unique snapshots, we recommend that you change your Maven snapshot policy to 'Unique' and remove any previously deployed snapshots from this repository.

The unique snapshot name generated by the Maven client on deployment cannot help in identifying the source control changes from which the snapshot was built and has no relation to the time sources were checked out. Therefore,we recommend that the artifact itself should embed the revision/tag (as part of its name or internally) for clear and visible revision tracking. Artifactory allows you to tag artifacts with the revision number as part of its Build Integration support.

Max Unique Snapshots

Specifies the maximum number of unique snapshots of the same artifact that should be stored. Once this number is reached and a new snapshot is uploaded, the oldest stored snapshot is removed automatically. Blank (default) indicates that there is no limit on the number of unique snapshots.

Handle Releases

When set, enables you to deploy release artifacts into this repository.

Handle Snapshots

When set, enables you to deploy snapshot artifacts into this repository.

Suppress POM Consistency

When deploying an artifact to a repository, Artifactory verifies that the value set for groupId:artifactId:version in the POM is consistent with the deployed path.

If there is a conflict between these then Artifactory will reject the deployment. You can disable this behavior by setting this checkbox.

Enable Composer V1 Indexing

When selected, uses Composer V1 indexing on the repository.

📘

Note

From Artifactory 7.24.1, all local PHP repositories are created automatically using PHP Composer V2, which supports faster download times and enhanced performance.

Primary Key Name

The name of the GPG primary key used by the repository.

Secondary Key Name

The name of the GPG secondary key used by the repository.

RPM Metadata Folder Depth

Informs Artifactory under which level of directory to search for RPMs and save the repodata directory.

By default this value is 0 and refers to the repository's root folder. In this case, Artifactory searches the entire repository for RPMs and saves the repodata directory at $REPO-KEY/repodata.

Using a different depth is useful in cases where generating metadata for a repository separates its artifacts by name, version and architecture. This will allow you to create multiple RPM repositories under the same Artifactory RPM repository.

For example:

If the repository layout is similar to that shown below and you want to generate RPM metadata for every artifact divided by name, set the Depth to 1 and the repodata directory is saved at REPO_ROOT/ARTIFACT_NAME/repodata :

REPO_ROOT/$ARTIFACT_NAME/$ARTIFACT_VERSION/$ARCHITECTURE/FILE_NAME
- or -
rpm-local/foo/1.0/x64/foo-1.0-x64.rpmm

📘

Note

When changing the configured depth of existing repository, packages indexed in the old depth might need to be re-indexed or moved to a new depth to be available in the new configured depth, and YUM clients might need to change their configuration to point to the new depth.depth.

Auto Calculate RPM Metadata

When set, RPM metadata calculation is automatically triggered by the actions described by the setting above.

Enable File List Indexing

When set, RPM metadata calculation will also include indexing the filelists.xml metadata file.

RPM Group File Names

A comma-separated list of YUM group files associated with your RPM packages.

Note that at each level (depth), the repodata directory in your repository may contain a different group file name, however each repodata directory may contain only 1 group metadata file (multiple groups should be listed as different tags inside the XML file. For more details, see YUM documentation.

Terraform Registry Type

Select one of the following Terraform repository layouts:

• Module: Applies the terraform-module-default repository layout. For more information, see Resolve Terraform Modules.
• Provider: Applies the terraform-provider-default repository layout. For more information, see Resolve Terraform Providers.