Share your experience using JFrog Container Registry

My main use case for JFrog Container Registry is for a Docker repository, and I use it for uploading build artifacts, such as binary applications, for storing the application for upload and download from the local PC. I use Jenkins as well.

I generally access JFrog Container Registry through the command line interface and GUI. I download the artifacts from the build that is uploaded, and once it is released, I download from Artifactory. I also upload files to the repository directly, so I use both the command line and GUI.

I run it using Jenkins, so it is for sharing across the team. Once the build system builds the binary to the local PC, I upload it to Artifactory, and the corresponding code, binary, and libraries are shifted as a zip file to share with the customer.

The best features of JFrog Container Registry include managing space efficiently when uploading the same files, and it allows me to upload and download using a threaded option for faster transfers than what can be achieved on the network.

JFrog Container Registry has made it easier for everyone in the organization to share resources as everyone has user IDs and passwords for easy access.

The biggest friction point with JFrog Container Registry is sometimes network issues where I am unable to upload files due to frequent locks. When I interface with JFrog but encounter a network connection issue, uploads may fail after multiple attempts.

I have been using Frog Container Registry for five to six years.

When I first implemented JFrog Container Registry, it took almost six to eight years to interface it using JFrog command for upload and download because I felt that the systems were unstable during continuous uploads and downloads due to size issues. Nowadays, JFrog Container Registry is stable and has a feature where it will not take much time if the same files are uploaded to the same location, and it also takes less time if the files have already been downloaded due to its caching mechanism.

Previously, I was using Samba for storage in the local network, which was tough to manage due to continuous growth and slow network paths, which is why I am trying to use JFrog owing to its efficient size management features.

There are teams managing JFrog internal configuration, and I am from the developer and DevOps side, focusing on implementation and not monitoring JFrog architecture. If any size limit exceeds or if any issue arises in JFrog, I do not handle those issues. I maintain the interface between Jenkins and JFrog.

I am not the one deciding to use JFrog. Other team members considered it, while my role is to integrate JFrog and communicate how I can utilize it in the system.

I would suggest using JFrog Container Registry as it is flexible and has a low chance of breakage, making it ideal for building systems and sharing results. I collaborate in team meetings using Zoom and Teams. I would rate this product an 8 out of 10.

My main use case for JFrog Container Registry is that we have a central repository where we store all our Git repositories and code bases. If there are other external packages that we need to include in our projects, these are part of JFrog Container Registry.

Day-to-day and week-to-week, there are multiple use cases which vary for JFrog Container Registry. What I do is work on coding new things, new systems, and building new features. JFrog Container Registry helps me fetch specific packages and serves as a source of truth for various JAR files, Node Package Manager packages, and Docker images. It helps me reduce build times through local caching and provides its own vulnerability scanning features, aiding me with dependency resolution in general.

Adoption of JFrog Container Registry has been with both power and casual users. There are individuals who code extensively and individuals who conduct several proof of concepts on new packages and new images. Those people are our power users, and they have specific ingrained accesses and deeper knowledge of JFrog Container Registry, which is limited more or less to the technology department. Not every team or business unit uses it throughout the company, but most of them in the division that I am in do use it.

The best features of JFrog Container Registry include documentation of specific SSOs, custom layouts, and it helps set up charts for Kubernetes. It provides caching of external dependencies locally during deployments and has deeper access controls where some individuals or teams can be given certain accesses while others are not, which is a primary way we use it.

JFrog Container Registry has impacted my organization in a way that is hard to gauge at an organization level because I was not involved in cost analysis or benefit saving analysis. However, for our team, it has been very useful from a security standpoint, as we do not have to manually perform vulnerability scanning of every random open-source package. It provides a central way to install packages and Docker images from.

I cannot provide a cost reduction or efficiency gain, but I can say there is a very large security vulnerability gain we have. We do not get phased out by random packages, malware, or hackware, and monetary losses are generally reduced by not using open-source packages that can create vulnerabilities or have hidden code such as remote code execution. JFrog Container Registry helps us prevent all of that.

JFrog Container Registry has changed how my team collaborates by providing a central repository where we pull in all our packages. Although it is hard to quantify the collaboration impact, it generally helps us collaborate across the organization.

Regarding features I wish it had, if I talk about the free tier provided in one of the smaller organizations that I worked in, I think that was very limited. Unless you have a paid, pro, or enterprise tier, the features you get are somewhat limited and can have some hidden costs. Those are some of the things that could be made better.

I have been familiar with JFrog Container Registry for more than four years.

I do not know any friction points with JFrog Container Registry, as we have been using it very smoothly.

Before landing on JFrog Container Registry, we were using Nexus Sonatype at some stage, and we have also used AWS CodeArtifact before it was phased out.

The decision on JFrog Container Registry specifically over those alternatives was an organization-based decision. I think it is a straightforward tool that provides various different kinds of enterprise and pro-level plans, generally meant for large organizations, which is why it was adopted.

I am not aware of any features that came up during implementation that I am not actually using. I think it has something called X-ray related features, but I am not sure if I have used it or not. I would rate JFrog Container Registry highly on a scale of one to ten, and I have no additional advice to give to someone considering it with a similar workflow to mine. I feel that you have asked great questions, and nothing else needs to be covered. I have assigned this review a rating of nine out of ten.