Using the latest version?
JFrog Container Registry Guide

Skip to end of metadata
Go to start of metadata


Several of the settings are common for local, remote and virtual repositories. These are found in the Basic Settings tab of the corresponding New/Edit screen under the General section. Additional settings may be found in the type-specific section according to the package types specified for the repository.

Common Basic Settings

Page Contents

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 identifier for the repository and must be unique within a JFrog Container Registry instance. It cannot begin with a number or contain spaces or special characters. For local repositories we recommend using a "-local" suffix (e.g. "libs-release-local").
Repository Layout
Sets the layout that the repository should use for storing and identifying modules. JFrog Container Registry will suggest a layout that corresponds to the package type defined, and index packages uploaded and calculate metadata accordingly.
Public Description
A free text field that describes the content and purpose of the repository.
Internal Description
A free text field to add additional notes about the repository. These are only visible to the JFrog Container Registry administrator.
Include and Exclude Patterns

The Include Patterns and the Exclude Patterns fields provide a way to filter out specific repositories when trying to resolve 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).


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

Include Patterns: com/project/a/**, com/project/b/**
Exclude Patterns: com/project/final/**

In this example, JFrog Container Registry will search and will be able to pull images from artprod.mycompany/<DOCKER_REPOSITORY>/com/project/a/mysql:5.6 and artprod.mycompany/<DOCKER_REPOSITORY>/com/project/b/images/mongo:3.3 but not from artprod.mycompany/<DOCKER_REPOSITORY>/com/project/final/alpine:3.9 because com/project/final/** is specified as an Exclude pattern.

JFrog Xray Integration
If JFrog Container Registry is connected to an instance of Xray, indicates if the repository is indexed for analysis.

Avoiding Security Risks with an Exclude Pattern

Any proprietary artifacts you deploy to JFrog Container Registry are stored within local repositories so that they are available for secured and authorized internal use.

Anyone searching for one of your internal artifacts by name will extract it through JFrog Container Registry from the local repository.

However, consider what happens if a request for an internal artifact is inadvertently directed outside of the organization.

Two examples of how this could happen are:

  • there is a simple typo in the requested artifact name
  • the developer has requested a snapshot with a version number that does not exist.

In this case, since JFrog Container Registry does not find the requested artifact in a local repository, it continues to search through the remote repositories defined in the system. JFrog Container Registry will, in fact, search through all the remote repositories defined in your system before returning "Not found".

This presents a security risk since any request made on a remote repository may be logged exposing all details of the query including the full artifact name which may include sensitive business information.

Best practices using an excludes pattern for remote repositories to avoid security risks

To avoid exposing sensitive business information as described above, we strongly recommend the following best practices:

  • The list of remote repositories used in an organization should be managed under a single virtual repository to which all requests are directed
  • All internal artifacts should be specified in the Exclude Pattern field of the virtual repository (or alternatively, of each remote repository) using wildcard characters to encapsulate the widest possible specification of internal artifacts.

Avoiding Performance Issues with an Include Pattern

In a typical scenario, JFrog Container Registry will reference large all-purpose repositories such as JCenter or Maven Central for resolving artifacts.

In addition, JFrog Container Registry may reference any number of additional repositories which may host a more specialized and specific set of of artifacts.

If JFrog Container Registry receives a request for a deterministic set of artifacts (e.g. a specific version of an artifact), then it searches through the different repositories according to its resolution order until the artifact is found.

However, if JFrog Container Registry receives a request for a non-deterministic set of artifacts ( e.g. all versions of maven-metadata.xml) then it must search through all of the repositories it references until it can provide a complete response.

In most cases, the majority of artifacts downloaded by an organization will come from one of the large all-purpose repositories, but in non-deterministic requests performance is downgraded because JFrog Container Registry continues to search through all the specialized repositories before it can return a response.

Best practices using an includes pattern for remote repositories to avoid needless and wasteful search

To avoid performing needless and wasteful search when responding to non-deterministic requests we strongly recommend that all specialized repositories be configured with an appropriate Include Pattern specifying only the set of artifacts that the organization might need.

In this case, non-deterministic requests for artifacts that are typically found in general purpose repositories will skip over the specialized repositories thereby improving performance.

Local and Remote Repositories

In addition to the settings above, Local and Remote repositories share the following settings in the type-specific section for relevant package types.

  • No labels