JFrog Container Registry Reviews

My usual use cases of JFrog Container Registry involve containerizing all our applications and storing the generated Docker containers and custom Helm charts into JFrog. We also perform X-ray scans with JFrog to segregate vulnerabilities into categories such as critical, high, medium, and low, and we take fixes for critical and high vulnerabilities while writing certain rules for tags that have been pushed into the repository.

The most valuable feature of JFrog Container Registry for me has been the X-ray scans because when we ship the product, we need to ensure that there are no vulnerabilities in our application, and X-ray helps us find vulnerabilities in our containers or Helm charts.

I have seen organizational value from JFrog Container Registry in our SDLC lifecycle, as it plays an important role in making the development lifecycle faster and adhering to sprint targets.

While using JFrog Container Registry, one limitation I have encountered is that it would be beneficial to have enhanced capabilities for vulnerability scanning, such as proper categorization of SAST, DAST, and IAST.

I have been using JFrog Container Registry occasionally for about 3 years and have also tried out JFrog, Nexus, Azure, and AWS registries.

The deployment process for JFrog Container Registry involves checking out the code, building the application, and then running a set of commands to Dockerize it before pushing the microservices one by one into JFrog.

Pushing into the registry usually takes around 2 minutes, depending upon the size of the image.

The most amount of time I have spent in deployment is about 10 minutes when deploying 10 images without using multi-stage Docker.

I would rate the stability of JFrog Container Registry an eight. The stability aspect is generally fine, but at times when I try to download multiple artifacts simultaneously, I face some network exceptions during concurrent operations.

I haven't found any issues with the scalability of JFrog Container Registry, but there was an occurrence when we had to store a Kubernetes artifact of about 3.5 GB, and the upload feature had restrictions preventing us from uploading more than 500 MB.

So far, we haven't needed to reach out to the technical support team of JFrog Container Registry.

I find the documentation for JFrog Container Registry pretty straightforward and useful.

Positive

Before using JFrog Container Registry, I used Harbor and Nexus. I decided to use JFrog Container Registry while still using Harbor because Harbor has unique features, such as being shipped as a private registry and being more lightweight than JFrog; it also has a separate microservice called Trivy that aids in vulnerability scanning.

I would rate the initial setup of JFrog Container Registry an eight. Sometimes depending on the tools, such as Azure DevOps, we found the service connection a bit challenging to configure; however, it was much more straightforward when using GitLab and Jenkins.

For the deployment of JFrog Container Registry, we have just two people in DevOps who manage it, and although the initial setup was challenging due to configuring 48 pipelines for our microservices, maintenance became easier after that.

Before choosing JFrog, I evaluated Nexus, JFrog, and Harbor, ultimately choosing Harbor and JFrog. Factors that made me choose JFrog Container Registry over other options include low latency in pushing and pulling images and a wide range of artifacts supported, such as zip files, containers, and Helm charts, along with its user-friendly interface.

When managing Docker images, I find that JFrog Container Registry has very low latency when pushing or pulling images, which is a significant reason we are using JFrog, along with easily configurable endpoints to the application.

We don't use the replication capabilities of JFrog Container Registry because we tag different sets of containers for every release.

Over the years, I have seen nice improvements to the user interface of JFrog Container Registry, and I hope that more additional capabilities come in the future so that we can keep using this tool.

Currently, JFrog Container Registry does not support my AI-driven workloads as we haven't explored that direction yet, but it's a consideration for future purposes.

We have plans to increase the usage of JFrog Container Registry in the future as we have other products in the pipeline, and once they complete the MVP phase, we will take the next initiatives.

Currently, we only have two endpoints for JFrog, one from AWS and one from Azure.

Overall, I would rate JFrog Container Registry an eight.

Hybrid Cloud

Other

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.

It was a good experience with JFrog Container Registry. We used that in our tool and process to manage artifacts.

We can use extra features, such as X-ray for scanning code or images. I think it should have been used more.

I am working for JFrog Group as a DevOps professional.

They are using these solutions: Sonocube, JFrog Container Registry, and Dynatrace.

Advanced scanning of images, container images, finding vulnerabilities, filtering those vulnerabilities, and building golden images are the security features I look for.

One of the concerns we had was regarding the pricing in terms of the amount of time utilized.

Pricing, purge of data or historical data, ease of usage, pricing model, setting the current pricing, changes in the configuration so that the pricing can be brought down, and better utilization of JFrog Container Registry are the issues I face.

We would prefer to have more control over pricing, more clarity on pricing, and improvements on the analytics part with JFrog Container Registry. If we are going to use security features, these are things we will look at.

I have been using JFrog Container Registry for more than one year, almost two years.

I will get back to you in two days.

I am working for an organization which is a customer for JFrog Container Registry.

On a scale of one to five, I rate JFrog Container Registry a four out of five.

I am using JFrog Container Registry for various projects that involve using different Docker setups for an enterprise-grade private container registry with JFrog Artifactory. I have set up high availability JFrog instances on Kubernetes, configured local and remote repositories for container images, and more. I have built an end-to-end CI/CD pipeline with JFrog and the registry on Kubernetes, utilizing Jenkins, JFrog X-ray, and more.

I am using JFrog Container Registry for various projects that involve using different Docker setups for an enterprise-grade private container registry with JFrog Artifactory. I have set up high availability JFrog instances on Kubernetes, configured local and remote repositories for container images, and more. I have built an end-to-end CI/CD pipeline with JFrog and the registry on Kubernetes, utilizing Jenkins, JFrog X-ray, and more.

Areas of improvement include advanced security integration that should go beyond basic vulnerability scanning. More documentation about policies, X-rays, and download triggers, along with integrating security and license compliance reports directly into pipelines, would be beneficial. There should be automation of the promotion pipeline for various stages, dependent on quality, test coverage, vulnerability scans, and manual approvals.

We have been using JFrog Container Registry for about ten years.

I have experienced some lagging or crashing a couple of times with DevOps.

Scalability is fair, but not the best. I find cloud-based features to be better in terms of scalability than JFrog Container Registry. Nexus, for example, seems to be slightly better in terms of scalability.

I have not personally contacted technical support. It was my manager who did in previous projects.

Neutral

I have used cloud-based solutions such as AWS ECR, Google Cloud, Azure Container Registry, Nexus, Quay.io, and sometimes GitHub Container Registry.

The initial setup was difficult at first. It involved going through documentation and online resources like YouTube videos and articles to find guidance. Ten years ago, the user interface wasn't as developed, so external resources were crucial.

JFrog pricing includes self-hosted and cloud options, with costs based on licenses, subscriptions, number of nodes, and repository limits. Licensing costs are $3 per year, which I feel is reasonable.

Alternatives include AWS ECR, Google Cloud, Azure Container Registry, Nexus, Quay.io, and GitHub Container Registry.

Overall, I rate JFrog Container Registry a seven. I am skilled at understanding how Artifactory works and although I don't have a strong preference, I prefer JFrog, Nexus, and cloud-based Artifactory in that order.

Hybrid Cloud

Other

JFrog Container Registry acts as a single solution for storing and managing all of our software artifacts. This includes packages, files, and containers throughout our software supply chain. 

We have a central JFrog server, and we integrate various tools with it. The artifacts are stored there. It helps us manage the process from build to release.

There are several aspects. We use it to store container access information securely. We've also implemented authentication mechanisms like SAML, download blocking, and virtual IT consoles. 

For repository optimization, we've used the file store feature within JFrog Container Registry.

The security features in JFrog Container Registry have helped protect the integrity of the Docker images.

From my perspective, it allows us to integrate our development and operations workflows seamlessly. It's self-hosted and works well in hybrid SaaS environments. Plus, it supports multi-cloud deployments across AWS, Azure, and GCP.

In my experience, there was a bit of a learning curve at the beginning. It can be somewhat challenging to install and get started. However, once you gain some experience, working with JFrog becomes much easier. 

Overall, it's manageable for beginners, but there might be a bit of a learning curve. I'd call myself an intermediate user.

We've been using it in my organization for about two and a half years now.

From my experience, it's stable. I've used it heavily for CI/CD workflows, and the automation is fast without any breakdowns. We've even integrated it with IoT device management.

Based on my observations across multiple projects, I'd estimate that around 50-70% of our teams use JFrog in some capacity.

The companies I've worked with, like Walmart and others, already had JFrog deployed when I joined. Often, with larger companies, it's not feasible to switch major tools once they're in place.

As a DevOps engineer, I found the initial setup straightforward to install and use. I've even set up and managed JFrog Artifactory instances from scratch earlier in my career. I know JFrog well from the artifact storage perspective.

Assuming everything is set up correctly, it should take about half an hour – maybe 15 to 30 minutes.

It's cloud-based. We use AWS.

It offers valuable features and is worth the money.

The pricing is somewhat expensive compared to its competitors.   

We use the Pro version because we have a data consumption of 6GB in our organization. We considered the Enterprise plan as well, which is around $750, but we're still evaluating that option. For now, we're sticking with the base Pro package.

I'd definitely recommend it. It's a good choice for those starting out, especially if you're focused on container-based workflows. It's easy to understand and deploy, and you can even use the JFrog interface directly. There might be even better options depending on your specific needs.

Overall, I would rate the solution an eight out of ten.

Public Cloud

Amazon Web Services (AWS)

We use the solution to compile the codes before publishing them. We utilize third-party containers and codes, downloading them to the JFrog Container Registry. Developers then access it from the JFrog Container Registry, and there's a specific job responsible for running and validating all security checks, ensuring compatibility. If there are any issues or if packages require updates, we manage those updates through this system.

The product offers a centralized repository. 

JFrog Container Registry's most valuable feature is code scanning. 

One challenge we face is related to performance. Our integration involves GitHab and JFrog Container Registry, with pipelines fetching data from GitHub and JFrog Container Registry for third-party code. However, there are instances where this process can slow down the pipeline.

I have been using the product for a couple of years. 

I rate the solution an eight out of ten. 

I rate JFrog Container Registry's scalability an eight out of ten. 

JFrog Container Registry's tech support team is responsive. 

Positive

We used ProGet before JFrog Container Registry. JFrog Container Registry is much more advanced. 

JFrog Container Registry's deployment was not complex. 

We have seen ROI with the tool's use. 

The solution is expensive. 

I rate the tool an eight out of ten. 

We push our images and Helm charts to the JFrog Container Registry. Since we have a Kubernetes-based environment, these images and Helm charts are pulled from the Kubernetes cluster and deployed.

We have integrated JFrog Xray, and we use it for storage purposes.

The solution's documentation available over the internet is not straightforward and customer-friendly. The documentation is mostly for the on-prem services, and there's no documentation for the cloud offering, which could be improved. The pricing is not readily explained over the internet, and I had to manually check a lot of forums to get an insight into how we are getting charged.

We were on a pro plan, and JFrog could have suggested optimization or plan upgrades based on our utilization. That didn't happen unless we manually looked into it, and now we are considering moving away from this platform.

The solution's storage costs are getting too high. Last month, we were charged around two and a half terabytes, which is a lot of data. We are considering moving towards a cost-effective platform.

I have been using JFrog Container Registry for one and a half years.

JFrog Container Registry is a stable solution.

I rate the solution an eight out of ten for stability.

We are a team of 35 developers using the tool in our organization.

I rate the solution’s scalability an eight out of ten.

The technical support’s response time could be improved.

Neutral

Since one of our team members had prior knowledge of it, the initial setup of the solution wasn't difficult for us.

The solution’s deployment took around a week.

JFrog Container Registry is a very expensive solution.

On a scale from one to ten, where one is expensive and ten is cheap, I rate the solution’s pricing a two out of ten.

We are using the cloud-based version of JFrog Container Registry. I would not recommend the solution to other organizations.

Overall, I rate the solution a six out of ten.

Public Cloud

Google