JFrog Container Registry

The JFrog Container Registry is powered by JFrog Artifactory with a set of features that have been customized to serve the primary purpose of running Docker and Helm packages in a Container Registry.

As JFrog Container Registry is a version of Artifactory, refer to the JFrog Artifactory documentation when working with JFrog Container Registry. For example, Configuring Artifactory, Installing Artifactory, Upgrading Artifactory, and Artifactory Release Notes.Installing ArtifactoryUpgrading ArtifactoryArtifactory Release Notes

To view a list of supported JFrog Container Registry features, see the JCR Functionality Table and to compare JFrog Container Registry with other versions, see the Self-Hosted JFrog Platform Comparison Matrix or the Cloud JFrog Platform Comparison Matrix depending on your needs.Artifactory Comparison MatrixJFrog Cloud Comparison Matrix

You can host JFrog Container Registry on your own infrastructure, in the Cloud, or use the SaaS solution providing maximum flexibility and choice.

You can set up a secure private Docker registry in minutes to manage all your Docker images while exercising fine-grained access control. JFrog Container Registry places no limitations and lets you set up any number of Docker registries, through the use of local, remote and virtual Docker repositories, and works transparently with the Docker client to manage all your Docker images, whether created internally or downloaded from remote Docker registries such as the Docker Hub. To start configuring your Docker registry, see Configuring Docker Repositories.

JFrog Container Registry natively supports Helm registries, giving you full control of your deployment process to Kubernetes. It supports proxying remote Helm registries, deploying Helm Charts to local repositories and, of course, using a virtual repository to aggregate all those Helm Chart repositories so you can access them through a single endpoint.

The Helm package search in JFrog Container Registry is customized to allow users to search for Helm repositories by “App version” and not only by “Version”, which refers to the Chart version. App Version is a useful piece of information as it lets your users know what version of your app they are using, as the chart version could differ. You can search for the parameter after you add it to the Chart.yaml file. For more information, see Helm Registry.

JFrog Container Registry supports Generic repositories that are not associated with any particular package type and can be used to upload packages in any format. Generic repositories do not maintain separate package indexes, because they are not specific to any package type. They are useful when you want to proxy unsupported package types, store installers, navigation files, audio files, etc.

You can start managing your container images by setting up Local repositories that are physical, locally-managed repositories. Typically these are used to deploy internal and external releases as well as development builds, but they can also be used to store images that are not widely available on public repositories such as 3rd party commercial images.

Remote repositories allow you to set up a caching proxy for external registries such as the Docker Hub. Artifacts are stored and updated in remote repositories according to various configuration parameters that control the caching and proxying behavior. You can even set up your remote repository as a Smart Remote Repository to proxy a local or remote repository from a different JFrog Container Registry, essentially caching all distant repository content inside your own JFrog Container Registry instance. Smart remote repositories are especially useful when changes are made to the original container image, e.g. when its properties are changed or when it is deleted.

Virtual repositories encapsulate any number of local and remote repositories and represents them as a unified repository accessed from a single URL. It gives you a way to manage which repositories are accessed by developers since you have the freedom to mix, match and modify the actual repositories included within the virtual repository.

Useful for separating teams/projects and for promoting images from one environment to the next (Development, Staging, and Production).