Share your experience using JFrog Container Registry

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.

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