JFrog Artifactory Reviews

We use Artifactory for all of our software development. We're an electric car company, and we're headquartered in China, but we've got an R&D software development office in San Jose. All of our software development teams use Artifactory for storing all their artifacts, binaries, and things like that for the software that they're developing for the electric vehicles that we manufacture and sell in China and Europe.

We are using the Enterprise X version. It's self-hosted and on-prem. It's not on the cloud.

It's very good for end-to-end binary management. It's a very good solution. I've worked at companies where software developers were just storing all of their releases, merge requests, and everything in a file structure or file storage. It's difficult to keep track of that. You can't tag metadata to that, and you can't see information, such as dates of when things were uploaded. Artifactory having all those capabilities makes it very useful for the developers to track the index and be able to sort and find all of their data, especially for keeping archives of all of the releases and things.

It's one of the core tools that our engineers rely on every day, not just our engineers in the US office in San Jose but also our engineers in China. We're a global company. Our software teams are globally distributed. So, there's constant sharing of software source code, artifacts, and binaries across the countries. We have Artifactory instances deployed both in the US and in China. It's, if not the most valuable, the second most valuable tool behind our source code repository for the engineers to use on a day-to-day basis.

We've had it since the beginning days when we started as a company in 2016. It has certainly not been a hindrance to our software development and accelerating the developers to be able to do their work. They aren't spending time trying to keep track of all their data in terms of where it's stored and how to store it. So, it enables our engineers and our developers.

We've been able to utilize some of the APIs to build custom interfaces and dashboards for self-service on permission management and user and group permission management. We did that, and then later, Artifactory or JFrog came out with a user group manager interface, but we had built one ourselves initially utilizing the APIs. Now, we're building on top of those same APIs to set up a self-service data retention dashboard for the users or for the developers so that they can set and manage their own data retention policies and then self-manage their own storage usage and growth.

The core functionality is most valuable for indexing and metadata of all the artifacts, but within the last year or two, we've been using the Projects feature, which has been very helpful. We can now assign individual admins for different projects and repos so that they can self-manage their own user permissions for their data. My IT DevOps team doesn't have to be the facilitators of that. It's now more of a self-service capability for them. We were looking for the same feature for a while. We upgraded to the Enterprise X version. We were on the Pro version before, which only allowed three projects, so we recently upgraded to the newer version that allows more projects. That's the only feature that we're currently using from the new version, but we'll probably look at utilizing more features down the road.

Artifactory’s range of support for packages and file types is adequate. It meets our requirements.

We're looking for something that has additional reporting capabilities on data growth and data aging. This goes back to storage lifecycle management so that the actual Artifactory itself can provide these reports to either the administrators or the users. I don't know if it has those capabilities. That's something we have to look into regarding the self-service dashboard, but the tool itself having those capabilities would be great rather than trying to do it at the underlying storage hardware layer.

We moved from the internal Derby DB to the Postgres database last year or the year before. Because of the size and amount of objects in our instance, we were probably going to exceed the recommended number of objects for the default Derby DB. So, we moved to Postgres. The other option was MySQL. There weren't a lot of options. It could've been better. I felt that there wasn't a lot of knowledge base or support available to help with that migration for us. We had reached up to Artifactory support to see if they had a professional services type of engagement to do that, and they didn't have anything of that nature. So, we were left to our own devices to manage that database migration.

We've been using Artifactory since 2015. It has been almost seven or eight years.

It's very stable. We haven't had any major outages. It has been very stable. We haven't had any issues where the platform went down due to software glitches or database corruption problems or anything of this sort. It has been very stable, even with a single instance.

Its stability has affected our software development process in a positive way because it hasn't had any major outages or gone down. We haven't had any big interruptions in our release cycles in being able to get code or things out to the customers or to the vehicles. It has not been a hindrance.

We have two instances deployed. They're just single standalone instances, not HA, deployed in two different regions. We have teams using them across both regions. There's cross-region collaboration happening, and it's used by around 1,000 software developers.

We haven't gone to the multi-site HA feature. We're still on a single instance, and we haven't scaled beyond that level. We have replaced or upgraded the database to Postgres to support a larger number of objects. We did run into that sort of scalability need a year or two ago. The platform itself can scale, but you have to take care of the backend hardware layers of the systems and the performance and storage that it's utilizing. The system or the software itself seems to be able to scale very well.

We're looking to deploy a third instance in another region. Currently, we have APAC and North America, and we're also looking at a European deployment.

Based on what I've heard from my engineers who do call support, their technical support is an eight out of ten.

We didn't use a similar solution at this company. At my previous company, we just used regular network file system storage for storing this type of data.

The initial setup seems pretty straightforward. It wasn't too much effort to get it set up.

Artifactory provides hybrid cloud and multi-cloud support, which is not important to us. We have an on-prem model. It is self-hosted. We don't store data in the cloud for security reasons. We just store the data onsite because it's our crown jewel, and we don't want to have any risk of potential security by being on the public cloud.

We implemented it ourselves. My team is responsible for deploying, setting it up, and managing it. It was implemented by my CIS admin, and he did not have any previous Artifactory experience. He read the manual, and through the documentation available from support and also the support we got over the phone when we had questions, he was able to get it deployed without any issues.

Overall, we had about one and a half staff. One of them was a system administrator. He handled all of the backend infrastructure servers and storage, and the other person was the DevOps engineer handling more of the front-end side of the application and setting up the authentication and configuring the repositories, user permissions, and things like this.

In terms of maintenance, it does require regular upkeep of upgrading to the latest code to stay current and regular archiving or purging, cleaning up of data out of the system to manage the storage utilization and storage growth. Those are two things that my team does on a daily, weekly, or monthly basis. We try to do monthly upgrades of the software itself. We then have almost weekly maintenance of the storage usage and cleaning that involves working with the developers to purge old or unnecessary data from the system so that it doesn't grow massively and becomes unmanageable.

That's hard to quantify. I'm not sure how to quantify an ROI on this type of software.

It is a bit expensive. It could be a little bit lower or have an a la carte option because, in our case, we had to go to the next version of Enterprise X because we needed one feature, which was more than three projects. We don't need all the other capabilities, but we're paying for all those. It's almost twice the cost of the previous version. So, it would be nice to have something along those lines.

We didn't evaluate other options.

We don't have a retention policy on our data. All the data that's stored in there is either kept forever or we manually purge it on a regular basis. We are working on a project to implement a self-service retention capability for the developers because we can't keep all of our data forever. It's just not manageable, and we don't need to. Certain data doesn't need to be kept forever. It has a shorter retention policy. So, we are working on building a custom dashboard that integrates with the APIs so the developers can then set their own retention policy on the different datasets.

We don't utilize the integration between JFrog Xray and Artifactory. We experimented and played with Xray about two years ago. There were some challenges there. I believe it wasn't able to scan docker images at that time. It may have that capability now. A lot of the data was binaries in docker, and it couldn't scan some of those types of objects, so it wasn't as useful to us at that time. So, at the moment, we're not using Xray. We may look at it again if there are additional new capabilities and features beyond what it had a few years ago, which it probably does. I just haven't had time to do that.

The reason that I would give to C-suite executives to continue to invest in Artifactory is that it's like a library. If we're creating all this data and storing all this data for the software, we need to put it into a library. We need to have an index. Some of it is kept forever, and some of it is kept for six months. There are different retention policies on different types of data that goes in there. So, it's essential to have the ability to store this data long-term but also be able to pull it up and find it immediately if we need to address a bug or create a patch on an older revision of a release. For day-to-day work, the software development engineers have to have a place where they upload their merge requests, their final releases, and things like that. So, it's essential.

Overall, I would rate it a nine out of ten.

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.