JFrog Artifactory Reviews

Previously, we were developing products without built-in security tools, and Artifactory lets us bake in that security process. We purchased the enterprise edition, which gives us three instances we use in different environments to better deliver our software. 

We run one instance in a sensitive area that's siloed off, one on our corporate infrastructure, and another on a public Cloud. It could be a customer using something out in the open or on Edge. Artifactory allows us to securely deploy our software.

We're a growing company that has been doing things in an archaic way. Artifactory has helped us modernize, and that's something that we can't do without. Our development operations are fully automated at each step from the daily development to the security scans that happen. It sped up our development, reducing a month-long process to a couple of days

The integration between Frog Xray and Artifactory is a pleasant surprise. When our developers push through code, we ensure it's secure, and it's all automated. 

Artifactory's support for hybrid cloud and multi-cloud environments is critical because we deploy to a wide array of environments, including those setups.
When we did the trial, we created multiple types of package registries that support different file types and tested each one. We were thrilled with the results. We were also pleased with the overall flexibility Artifactory provides in terms of storage and database option.

We have integrated Artifactory with Jira, allowing us to create Jira tickets for our security team to review when we identify vulnerabilities. There was a lot of overhead at first, but it paid off because we have full insight into what our code looks like from a security and a developer standpoint.

The package registries have been helpful. GitLab, our previous solution, wasn't managing that well. 

The documentation is a bit sparse. That's our only complaint.

We did a 30-day trial before we purchased Artifactory, and we just started using it.

Artifactory has been stable so far, but time will tell. 

Scalability is something we looked for, and Artifactory provides out-of-the-box scalability. It didn't require much work on our end. We have offices all over the country, so we can point new developers to the closest Artifactory location.

I rate JFrog customer support nine out of ten. We met with JFrog on multiple occasions. They brought their engineers to each call and thoroughly answered our questions. 

Positive

Setting up Artifactory is relatively straightforward, but the documentation on their website is outdated. That has been a challenge, but it's nothing we couldn't work past. Two of our staff members worked on the deployment, including me and our Chief Information Officer.

We did it in-house.

We've already seen a significant return on investment, and we look forward to seeing how it performs in the next year. The automation of pushing out and scanning code and packages is a huge help. 

The price is about what we expect for a tool like this. 

We evaluated several other products, including SonarQube and GitLab Ultimate. They're all about the same. 

I rate JFrog Artifactory eight out of ten until they get their documentation game under control. If JFrog's documentation were more consistent and up-to-date, I would probably give them a ten. 

My advice to potential users is to understand the difference between the tiers, so they can make the right decision. We ultimately made the right decision, but we almost bought the lower tier, which would not have done us any good.

We use it for development purposes, more specifically for continuous integration to push artifacts for deployment. JFrog is in the middle of both my CI and CD integration.

It plays a major role in my environment for continuous integration and continuous deployment. It is our only storage for artifacts, which includes all compiled and customized images.

It allows us to have everything accessible from a common location. It is user-friendly and secure.

It is user-friendly. It is playing a major role in creating new software. It has been very helpful in placing the bundles and doing the deployment. It plays a great role in pipeline technology. Without it, doing the same would be a lot more complicated. We wouldn't be able to achieve the required speed for on-time delivery of the new software.

Any AI project is a combination of multiple programming scripts or multiple programming bundles that need to be coordinated at a single point, either by the repository point or by the version control point. For version control, we have Git for saving multiple programming scripts into a single point. For the bundle point or placing the bundles in a single point, JFrog is used. It provides the proper bundle that the script demands.

The feature that I like is Permission Targets. If I want to give permission to only deploy the cache, I can give that permission to a set of users. Similarly, if I want to overwrite an artifact with the same name from the same pipeline, I can give permission for that as well to particular users.

Another important feature is the concept of a remote repo. For example, we have set up separate private clouds for the dev lab and prod. The dev lab has a given artifactory, and the prod has a different one. There is no communication from the lab to the prod or from the prod to the lab. If I want to access any version of an artifact from the lab to the prod, I use the remote repo concept. Instead of downloading the content from one place and taking it to another place and placing it there for use, I use the proxy method. That's one of the best features.

It is a flexible tool. It supports any cloud and any environment. It interacts with the pipeline or the version control system. It doesn't directly interact with a cloud system.

The latest version that I am using is 7.41. It has been upgraded graphics-wise, but there is a bit of slowness. They can improve the graphical interface for the admin jobs and make it faster. However, we rarely use the graphical interface. We only use it for enrollment, permissions, proxy bypassing, etc. All other things related to pushing or pulling images are done in the terminal mode via pipeline script.

If it comes with an option for version control, it would be great. Instead of going to Git, everything can be done in a single tool.

I have been using JFrog Artifactory for two years.

It is a stable product.

It is a scalable product. It is being used at multiple locations.

So far, I haven't had any issues that required me to contact their support. Most of the information is available on the JFrog forum.

We were using Nexus. We switched because of the features. JFrog is more advanced. If I want to give effective permissions or if I want to bypass a proxy for the version from the lab to production, it can be done. These features are not there in Nexus. If I want to achieve this, it is more complicated. I need to find multiple things to do that, whereas, in JFrog, it is very easy. In just three or four steps, I can get the remote repos. In terms of security, both Nexus and JFrog are quite secure.

In terms of its deployment model, we have AWS public cloud, and then we have our private network, but I was not involved in its deployment.

It doesn't require any maintenance from our side.

I am not aware of its cost, but it is worth investing in this. My guess is that its price is not much because we generally prefer open-source solutions, and if we are investing, we don't go for expensive ones. Our selection is based on the market demand and needs, and we invest only if something is worth the cost.

I would advise properly analyzing the needs of your environment and the number of licenses required before buying it. You should also analyze the deployment model that you are going to use. Cloud is advisable. I have been using it on the cloud, and it never went down. Globally, if you want to make JFrog available at any time, cloud deployment is the best option.

There are many products available in the market, such as Nexus, but in an enterprise environment, there should be a standard tool that is accessible from anywhere and from any system. If I want to create a new application from the existing bundle, it should be downloadable from a common point. It should be user-friendly and available throughout the environment. It should also be secure. The security of each and every code component is important. JFrog has the token method and the secret value method. So, security and availability are important factors when considering investing in such a tool. JFrog is the best tool in these aspects.

I would rate it a 10 out of 10. There isn't much to improve. Overall, the features that they provide in the latest versions are very good. They observe how people are using the product, and they keep on updating their product.

The main use case was to store the artifacts, store the binaries, basically. And then we used it as a container registry as well.

One of my tasks was to get X-ray running. I got the product running and tested it, but users never really started using it. So, from the user perspective, I don't really know how much they used X-ray.

What I can say about X-ray is that it did what Artifactory advertised. So, from that point of view, in my opinion, it worked fine, but we never really got to use it too deeply. We never got enough requests from our customers, the developers, or the security management team to implement some checks or block downloads from Artifactory, even when the software is too old or has some vulnerabilities.

That was a disappointment for me because I worked on the installation and management of X-ray for a couple of months. But that's not something that X-ray is responsible for.

For me, Artifactory was just a system that I needed to maintain, install, update, and back up.

I was an administrator of Artifactory, the person who manages the software. For me, it was manageable and stable. The upgrades were coming regularly, and the documentation on how to upgrade the system was clear. 

Then, when we had to implement certain customizations because of the way our networking is set up, it could get messy. But with the help of support, we got it working. Sometimes, the database got corrupted or something wrong happened, and then we needed support. In most cases, they were able to help us and sort it out.

So far, the software worked fine. There are some other products like Artifactory Insights that provide some level of monitoring and management and graphs of utilization.  

Sometimes the documentation was sort of messy because there are many possibilities for where and how to install Artifactory. So sometimes, I got a little bit lost, and it wasn't very clear which path in the documentation to take. But when I tested things and could just follow the manual, that was working fine.

Sometimes the UI was not working as expected. Users were complaining that they didn't see their Artifactory, but they had to clear their browser cookies or something. It was just the browser taking some information from the caches of the user's PC. So sometimes, this can be better. The UI could get laggy; maybe because our environment reached its limit. We had a large number of assets. It could take time for all the artifacts to load.

If there could be some better features for me, it would be being able to upgrade Artifactory directly from the UI. I think that is something that JFrog maybe offers with the cloud solution, but I don't know. For some reason, we still use the standalone on-premise solution. Maybe that version doesn't provide this functionality.

I've worked with Artifactory for two years.

For the most part, it's pretty stable. We had some performance issues. Sometimes, users complained that it was slow, especially with replication. We upload the artifacts into a central Artifactory that then replicates the artifacts to our other networking environments. Sometimes, it may be slow because of our network. 

Sometimes, it seemed to me that something was happening in the architecture itself that was making this process slow. Either it was maybe some kind of Artifactory process running in the background that slowed down this replication process, or, at times, I had this kind of feeling that I don't know why it's not replicating that Artifactory. And I wasn't able to really tell the user what was happening. It was mostly with the container images. Sometimes, it seemed that the container image was not replicated completely. You can see the container image in the other location, but the container image consists of several parts. And for example, one or two parts were missing. So then, the user was not able to download the container image and to really use it. So there were cases like this, and we had to basically delete the artifact in the affected location and try to replicate it again. I think, if I remember correctly, we were solving this issue with support.  

We have piles of data in there. We put lots of data into just one Artifactory. There were several millions of artifacts and terabytes of data, like hundreds of terabytes of data, on the file system.

We used three or four virtual computers to run the software and utilize the load, and those machines handled it fine. So, from this kind of point, it was okay. 

But from the manageability point of view, I would probably do it differently. I would probably split the data into several Artifactory instances because of backups and such things. So, from the scalability point of view, it was scalable.

We had developed some Ansible scripts that deployed Artifactory. I don't remember it exactly, but I guess they were sort of using the solution that JFrog provides. They have some Ansible scripts. So, I think we used those scripts to some extent and then modified them to our use case. That's the way we deployed Artifactory with Ansible scripts.

I came to an almost ready solution that was done by my colleague. I tweaked a little bit here and there depending on the changing requirements, like from the security team that told us to install certain firewalls or antivirus software. So, there were not any significant challenges to using those scripts. 

From my point of view, the maintenance aspect is not difficult. Doing the backups or updates usually worked fine. 

I personally would probably recommend it. For me, it did what it did well, or at least that was my feeling from it. So, I would recommend it. 

Overall, I would rate it an eight out of ten. 

We usually use it to store our artifacts, version them, and use them in production. We use it in CI/CD pipelines. All our R&D uses it as do all our development teams that need to release software. It doesn't matter what, they use it.

JFrog Artifactory is very essential to us. Without it, we could not use the artifacts, the products that our developers are writing. We would need to maintain a lot of different artifactory repositories in a lot of places. It would be more difficult. You definitely need some kind of artifactory solution. It doesn't necessarily need to be JFrog, but in my opinion, it's better to use it because it's a good, centralized solution. I haven't found any good competitors.

The way to explain to C-suite executives why they should continue to invest in JFrog is that it saves a lot of time and a lot of mundane work that would be required to maintain many solutions that JFrog gives you in one solution. 

We don't have to maintain a lot of repositories. We get the same outcome with JFrog with less maintenance. With the SaaS solution, we don't even need to maintain the installation, the server, or whatever infrastructure is around it. There is less involvement in artifactory management.

We don't need to use all kinds of artifactories like Docker Hub or different PyPI repositories for Python. Everything is there and we don't need to pay different companies for all these solutions or to maintain them.

It gives us a good workflow in terms of how we create software because we use it for all of our artifact types. It's good that it's centralized and it helps us in our CI/CD flows, to release software. You don't need to create different scripts or automations to upload different kinds of artifacts to different vendors or repositories. It simplifies our workflow.

The most valuable feature is that it is a centralized repository and that you can open multiple repositories for different types of artifacts. That is very good. 

Also, the fact that you can integrate artifacts with authentication systems, like Active Directory or Okta is valuable.

And for binary management, versioning them, it does a very good job and it gives us a good API to work with.

In some of the latest versions of JFrog's SaaS solution, they changed the user interface, the SSO settings, how you interact with them over API, and how you generate tokens. It was very confusing for me. The overall user management is very complicated.

Also, their documentation about how to do things could be better. It was very confusing. I had been using it for a couple of years and then they completely changed how it works—the user and token management.

I have been using JFrog Artifactory for three or four years. I have used it in almost every workplace.

It's very stable. I don't think I have had many problems. There may have been some many years ago, maybe, but not something critical.

It scales very well. In a previous company, we used it in a couple of locations globally and it was also an on-premises installation. We used the syncing options for repositories and it worked very well. We didn't have a lot of problems setting it up or using it.

In my current company, we have about 200 users.

We use it all the time. If we have another artifact type to throw in it, we will increase our usage of it. Every new software that we have developed and released has gone to JFrog Artifactory. We're always increasing its use.

The technical support is an eight out of 10.

Positive

Before JFrog Artifactory, we used all kinds of solutions, like Docker Hub and PyPI, but we didn't have a centralized solution like JFrog.

drop database *;

It's very good that they have SaaS and non-SaaS solutions. You can take the SaaS solution and simply use and get support. But for small companies that don't want to invest in paying them for the solution, their free, on-premises solution is very good. It's almost the same as the paid version, minus the support and some features. It's very important that they have both options.

Because we use the SaaS solution, there is no maintenance involved for us. They maintain it. We maintain our versions and artifacts within it, but not the system itself.

Artifact did not affect how long it took us to fix the Log4j issue because our company was part of some cybersecurity companies that detected the breach and we fixed it for ourselves.

I would recommend using it because it's a great tool. Everyone is using it, most companies, as far as I know. It's a very well-known solution. It's a good, centralized solution.

HPE used JFrog for a lot of things, but my team was building OVAs for VMware. Once the build process was complete, we would upload it to JFrog. There was some other process that would pull it down from JFrog and copy it to AWS for customers to access it. However, I don't think the customers downloaded it from JFrog. They downloaded it from AWS, but it was essentially just a version control for binary bits—artifacts that we created from our build process.

It's an enterprise product that acts like an enterprise product. In other words, it's not a product where they focus on user experience. I wasn't an administrator, so I primarily worked with the command line tool to upload and download parts of the product. I was not impressed with that because it wasn't well documented. It was challenging to figure out how to get things to work.

I don't know what alternative they could have used. JFrog was there when I joined the company, and that's what I had to use. I could envision an easier way to do it. The command line interface needs better documentation. When there are error messages, it should tell you precisely what failed. 

They also need to provide better examples of how to do various things. They've got a lot of documentation, but it never seems to be the thing that you need when you're trying to figure something out. They document it, but they don't give good examples. Furthermore, the upload performance is awful.

I used JFrog for about a year when I was working at HPE, but I left that job six weeks ago. 

I didn't have any real issues with stability.

HPE was using it for a lot of things, and they certainly had a massive implementation.

I rate JFrog Artifactory four out of 10.

Our primary use case is for storing the artifacts, dockery majors, or any kind of builds that are created as part of the CI process. Mainly the CI/CD pipelines are what we are using it for.

The most valuable feature I have found is the JFrog CLI. I think I am not so sure if my client has used the CLI with Nexus or if there are any CLI available with Nexus, but if I specifically talk about JFrog, I think that is a good thing. I can upload or download the files even without a CI/CD pipeline directly with the help of an access token or maybe with the authentication mode.

We are currently having some migration issues and errors. It would be helpful if we could get some proper documentation on how to fix the current environment where we are currently struggling. I would like to see written technical support instead of having to contact them directly.

I have been using JFrog Artifactory for the past eight to nine months now.

The current stability is good.

There is scalability.

I did contact technical support about some issues I was facing and that went well.

I was previously working with Nexus and JFrog Artifactory is definitely better. One of the reasons for the switch is the JFrog X-ray option and the CLI.

I would rate JFrog Artifactory a seven out of ten.