Artifactory support for Git LFS provides you with a fully functional LFS server that works with the Git LFS client.
LFS blobs from your Git repository can be pushed and maintained in Artifactory offering the following benefits:
With Artifactory’s file storage on your local or corporate network, file download times may be significantly reduced. When considering the number of files that may be needed for a build, this can drastically reduce your build time and streamline your workflow.
- Reliable and consistent access to binaries:
With Artifactory as your LFS repository, all the resources you need for development and build are stored on your own local or corporate network and storage. This keeps you independent of the external network or any 3rd party services.
- Security and access control:
Artifactory lets you define which users or groups of users can access your LFS repositories with a full set of permissions you can configure. You can control where developers can deploy binary assets to, whether they can delete assets and more. And if it’s access to your servers that you’re concerned about, Artifactory provides full integration with the most common access protocols such as LDAP, SAML, Crowd and others.
- One solution for all binaries:
Once you are using Artifactory to store media assets there is no need to use a 3rd party LFS provider. Artifactory can now handle those along with all the other binaries it already manages for you.
To enable calculation of LFS package metadata in local repositories, in the Edit Local Repository dialog, select the Packages tab and check Enable Git LFS Support:
After entering a valid repository name the Git LFS section also shows the url that should be inserted in the .gitconfig file to have the Git LFS client work with Artifactory
as it's LFS server, with respect to any custom base url you may have set.
Setting Up the Git LFS Client to Point to Artifactory
In order for your client to upload and download LFS blobs from artifactory the
[lfs] clause should be added to the .
gitconfig file of your Git repository in the following format.
You can also set different LFS endpoints for different remotes on your repo (as supported by the Git LFS client), for example:
Working with Proxies and HTTPS
When using HTTPS (i.e. behind a proxy) with a self signed certificate your configuration might also require you to add the following:
Always consult your System Administrator before bypassing secure protocols in this way.
When running Artifactory behind a proxy, defining a base url is usually required (depending on configuration) due to the operation of the
Git LFS client which expects to receive redirect urls to the exact upload \ download location of blobs.
LFS repositories must be prefixed with api/lfs in the path
When accessing a Git LFS repository through Artifactory, the repository URL must be prefixed with api/lfs in the path, except when configuring replication.
For example, if you are using Artifactory standalone or as a local service, you would access your LFS repositories using the following URL:
Or, if you are using Artifactory Online the URL would be:
https://<server name>.artifactoryonline.com/<server name>/api/lfs/<repository key>
When configuring replication, reference the repository's browsable url i.e.;
Working with Artifactory without Anonymous Access
By default, Artifactory allows anonymous access to Git LFS repositories. This is defined under Security | General Configuration. For details please refer to Allow Anonymous Access.
If you want to be able to trace how users interact with your repositories you need to uncheck the Allow Anonymous Access setting. This means that users will be required to enter their username and password.
The Git LFS client will ask for credentials for the Artifactory LFS repo when accessing it - if anonymous access is allowed you can just enter blank credentials, otherwise you should enter your Artifactory user name and password (not your Git one).
To make the authentication process automatic you can use Git Credential Helpers to store these for you, and have the Git LFS client authenticate automatically.
Git stores credentials in plain text by default
You should take extra measures to secure your username and password when using Git credential helpers
As the Git LFS client supplies only limited data about the blob being uploaded (only it's sha256 checksum, or 'OID', and it's size) Artifactory does not store or process any metadata for LFS blobs.
You can set properties on the blobs for your own convenience but this requires extra logic to infer a sha256-named file stored in artifactory from the actual pointer stored in your Git repository.
Artifactory stores LFS blobs in a manner similar to the Git LFS client, using the provided sha256 checksum.
Git LFS blobs will be stored under a path such as
Where ad and 1b are the 1st and 2nd, and the 3rd and 4th characters in the blob's name respectively.
Git LFS behavior when download from the LFS endpoint fails
The Git LFS client will download the pointer file it created in your remote Git repository if downloading the blob from the LFS endpoint failed (i.e. wrong credentials, network error etc.).
This will cause the actual file in your local repo to be substituted with the pointer created by the LFS client with the same name and lead to any number of problems this behavior can cause.
This is a limitation of the LFS client tracked by issue 89.