Initially getting started is very easy. Being a java based application, it ships with a nice embedded db that will meet most small usage scenarios very easily.
Artifactory makes backups very easy to configure and restores are very straightforward. I've done several migrations from/to AWS and installs and it's worked very well.
This is probably the best feature (and frankly one that people would expect. There is only one copy of any artifact regardless of how many different copies there are. This is really helpful for when doing promotion from different repos. It's REALLY nice for Docker layers.
Permissions are REALLY flexible. Permissions are applied to either groups or users.
A good example is our main docker registry:
- we grant everyone read access
- we grant a subset of users the ability to push to specific subdirectories in that repo
You can leverage regexs on all permissions as include or exclude.
The API is really solid. You can script/program against pretty much anything in Artifactory with the API. It allows really flexible automation.
JFrog has really rich documentation.
This is a really cool feature. Imagine you have config files that you want users to download (like a gemrc file) that sets them up to talk to your install. If you're disabling anon access to Artifactory (which you probably are), You need to tell users where to get their artifactory username and encrypted password (or api key). Then you need to walk them through replacing their values in the config file.
Alternately you can provide the config file in artifactory with a few placeholder values like thier enrypted passwords. When a user attempts to download the file, artifactory will replace the placeholders that it understands.
You can read up on it here: https://www.jfrog.com/confluence/display/RTF/Filtered+Resources
This is probably my biggest thing I love about Artifactory. Repositories come in three flavors:
- local
- remote
- virtual
Local is exactly what you think: Local repositories where you push different artifact types Remote is an on-demand upstream proxy to something like CentOS yum repos or Rubygems.org
Virtual is where this really shines. Virtual repos aggregate any number of local and remote repos. In this way, you can use a single source url in something like your Yum configuration on a host to point to a single URL. This virtual repo can point to your local yum packages as well as upstream. Additionally you can control the resolution order in the virtual repo so that your own packages are always resolved first.
For all its coolness, there are some things that "bug" me. I've run into very few actual bugs over the years. Mainly annoyances.
There's no admin group. This is really frustrating when you're leveraging LDAP as your authentication source. Users must be explicity granted the admin bit.
This is something that would be nice to have permissions allow placeholders. It would be nice to say allow users to push to only a subfolder in a docker registry that matches their username without actually having to precreate it.
One nice feature of Artifactory is "encrypted passwords". The idea is that if you're using something like LDAP to auth, you don't want users to store credentials that may have broader network access in text files all over the place.
Encrypted passwords can't be used to log into the web interface. They can only be used for API calls (and things like native repository calls). In fact you can REQUIRE that those be used for all of those calls.
The problem is that if you set that token, it still requires you to log in once to get that value. There's an API call to get it but it can ONLY be called by that user. If you're blocking access to the API except for encrypted passwords, that means someone has to log in first to get it.
This breaks all sorts of nice automation features. A good example is if you want to create per-host credentials. You cannot auto-provision a user and then make a call to get that user's encrypted password to use in api calls if you force encrypted passwords.
At a minimum, admin users should be able to get that encrypted password or it should be an additional permission.
There is very little input from JFrog on user contributed issues. Not even really an acknowledgement most times.