PHP Composer Repositories

JFrog Artifactory Documentation



Artifactory supports PHP Composer repositories on top its existing support for advanced artifact management.

Artifactory support for Composer provides:

  • Provisioning Composer packages from Artifactory to the Composer command line tool from all repository types.

  • Calculation of metadata for Composer packages hosted in Artifactory local repositories.

  • Access to remote Composer metadata repositories (Packagist and Artifactory Composer repositories) and package repositories (such as Github, Bitbucket etc..) through remote repositories Remote Repositories which provide proxy and caching functionality.

  • Assigning access privileges according to projects or development teams.

  • Support PHP Composer versions 1 and 2 (virtual repositories are only supported for Composer version 2 only),

  • Support for downloading Drupal file version 7 and 8 from remote repositories.

Integration Benefits JFrog Artifactory and PHP Composer Repositories


Local Repositories

To enable calculation of Composer package metadata, from the Administration Module, go to Repositories | Repositories | Local and set PHP Composer to be the Package Type when you create your local Composer repository.

Composer v2 Support

Artifactory supports PHP Composer V2 in addition to V1. From Artifactory 7.24.1 (SaaS Version), Local PHP repositories will automatically be created in V2 that supports faster download times and enhanced performance.

The PHP Metadata V2 index support for local repositories, and complies with the following rules:

  • Your existing Composer repositories will remain unchanged and the Enable Composer V1 Indexing checkbox will set as the default.

  • From this Artifactory version and above, all newly created Composer repositories will be set with Composer version 2. The Enable Composer V1 Indexing field is disabled.

The V1 indexing can be enabled or disabled in the local Basic repository configuration and requires full reindexing after applying changes.

Deploying Composer Packages

The Composer client does not provide a way to deploy packages and relies on a source control repository to host the Composer package code. To deploy a Composer package into Artifactory, you need to use the Artifactory REST API or the Web UI.JFrog REST APIs

A Composer package is a simple archive, usually zip or a tar.gz file, which contains your project code as well as a composer.json file describing the package.


For Artifactory to index packages you upload, each package must have its version specified. There are three ways to specify the package version:

  • Include the version attribute in the package composer.json file

  • Set a composer.version property when deploying a package via REST (or on an existing package)

  • Use the version field when deploying via the UI

Remote Repositories

The public Composer repository does not contain any actual binary packages; it contains the package indexes that point to the corresponding source control repository where the package code is hosted.

Since the majority of public Composer packages are hosted on GitHub, we recommend creating a Composer remote repository to serve as a caching proxy for, specifying as the location of the public package index files. A Composer remote repository in Artifactory can proxy and other Artifactory Composer repositories for index files, and version control systems such as GitHub or BitBucket, or local Composer repositories in other Artifactory instances for binaries.

Composer artifacts (such as zip, tar.gz files) requested from a remote repository are cached on demand. You can remove the downloaded artifacts from the remote repository cache, however you can not manually deploy artifacts to a remote repository.

To define a remote repository to proxy as well as the public Composer Packagist repository follow the steps below:

  1. From the Administration module, go to Repositories | Repositories | Remote and set PHP Composer to be its Package Type

  2. Set the Repository Key, and enter the repository URL (e.g. in the URL field as displayed below .

  3. In the Composer Settings section, select GitHub as the Git Provider, and leave the leave the default Registry URL (e.g.

  4. Finally, click Save & Finish.


URL vs. Registry URL

To avoid confusion:

The URL is the URL of your Git provider where the actual package binaries are hosted.

The Registry URL refers to the URL where the package index files holds the hosted metadata.

To proxy a public Composer registry, set the Registry URL field to the location of the index files as displayed above. To proxy a Composer repository in another Artifactory instance, set both the URL field and the Registry URL field to the remote Artifactory repository's API URL. For example:

Setting Remote Repositories to Work Opposite Drupal 7 and 8 Package Type

From Artifactory version 7.24.1 (SaaS users) and higher supports Composer V2 allowing download of Drupal version 7 and 8 files from remote repositories.

To define a remote repository to proxy Drupal files as well as the public Composer Packagist repository follow these steps.

  1. From the Administration module, go to Repositories | Repositories | Remote | Basic tab and set PHP Composer to be its Package Type.

  2. Set the URL to

  3. Under the PHP Composer Settings section, set the Registry URL field to

Virtual Repositories

A Virtual Repository defined in Artifactory aggregates PHP packages from both local and remote repositories that are included in the virtual repositories. Using virtual repositories can be very useful since users will continue to work with the virtual repository while the admin can manage the included repositories, replace the default deployment target and those changes will be transparent to the users.

To define a virtual PHP Composer repository follow these steps:

  1. Create a new Virtual Repository, in the Administration module, under Repositories | Repositories | Virtual, click New Virtual Repository and set PHP Composer as the Package Type.

  2. Set the Repository Key value.

  3. Select the underlying local and remote PHP Composer repositories to include under the Repositories section.

  4. You can optionally also configure your Default Deployment Repository.


You can set the following in the Advanced tab.




Artifactory Requests Can Retrieve Remote Artifacts

An Artifactory instance may request artifacts from a virtual repository in another Artifactory instance. This checkbox specifies whether the virtual repository should search through remote repositories when trying to resolve an artifact requested by another Artifactory instance. For example, you can use this feature when Artifactory is deployed in a mesh (grid) architecture, and you do not want all remote instances of Artifactory to act as proxies for other Artifactory instances.

Using the Composer command line

Once the Composer client is installed, you can access Composer repositories in Artifactory through its command line interface.

Composer repositories must be prefixed with api/composer in the path

When accessing a Composer repository through Artifactory, the repository URL must be prefixed with api/composer in the path. This applies to all Composer commands including composer install.

For example, if you are using Artifactory standalone or as a local service, you would access your Composer repositories using the following URL:

http://localhost:8081/artifactory/api/composer/<repository key>

Or, if you are using Artifactory Cloud, the URL would be:

https://<server name><repository key>

Once you have created a Composer repository, from the Application module go to Artifactory |Artifacts | Artifact Repository Browser and click Set Me Up to get code snippets you can use to set your Composer repository URL in your config.json file.


Composer config.json file

Windows: %userprofile%\.composer\config.json

Linux: ~/.composer/config.json

Replacing the Default Repository

You can change the default repository specified for the Composer command line in the config.json file as follows:

    "repositories": [
            "type": "composer",
            "url": "https://localhost:8081/artifactory/api/composer/composer-local"},
            "packagist": false

Working with a secure URL (HTTPS) is considered a best practice, but you may also work with an insecure URL (HTTP) by setting the secure-http configuration to false:

    "config": {
         "secure-http" : false
    "repositories": [

From November 2020, GitHub no longer accepts account passwords when authenticating via the REST API and instead requires the use of token-based authentication such as a personal access token for all authenticated API operations on to Access Tokens

Cleaning Up the Local Composer Cache

The Composer client saves caches of packages that were downloaded, as well as metadata responses.

We recommend removing the Composer caches (both packages and metadata responses) before using Artifactory for the first time, this is to ensure that your caches only contain elements that are due to requests from Artifactory and not directly from Package. To clear your Composer cache, run the following command:

Clean the Composer cache

composer clear-cache

composer.lock file

In your project directory already has a composer.lock file that contains different dist URLs (download URLs) than Artifactory, you need to remove it, otherwise, when running the composer install command, the composer client will resolve the dependencies using the composer.lock file URLs

Viewing Individual Composer Package Information

Artifactory lets you view selected metadata of a Composer package directly from the UI.

From the Application module, go to Artifacts | Tree and drill down to select the package archive file you want to inspect. The metadata is displayed in the Composer Info tab.

image2016-10-17 15:31:37.png