Skip to main content

Composer

Install Composer packages through a project URL. Use these steps in the directory containing your Magento, Symfony or Laravel application's composer.json.

Prerequisites​

You need Composer 2, a running broker, a project with packages available from a source, and a token that can read those packages. Composer 1 is rejected. Replace <broker-host>, <project> and <vendor>/<package> throughout with your broker's HTTPS host, project slug and a package visible to the token. Include the port in <broker-host> when using a nondefault port.

Token kinds​

See token kinds in the access model for token boundaries, expiry and revocation.

For automated installs, follow GitHub Actions or GitLab CI.

Configure the repository​

Run this from your application directory. The URL is the project root; Composer requests packages.json beneath it.

composer config repositories.broker composer 'https://<broker-host>/<project>'

Review composer.json. Place the broker before other repositories. Composer repositories are canonical by default: when it contains a package, Composer does not look in lower-priority repositories for that package. Packagist remains available for names the broker does not contain. If your project must resolve everything through broker sources and proxies, run the second command below to disable direct Packagist access.

{
  "repositories": [
    {
      "name": "broker",
      "type": "composer",
      "url": "https://<broker-host>/<project>"
    }
  ]
}

To disable direct Packagist access without manually converting repository structures:

composer config repositories.packagist.org false

Vendor credentials belong on a broker source. For Magento vendor credentials, follow Vendor repositories as sources.

Set credentials​

Choose one of these methods. Credentials are keyed by host, including any nondefault port, rather than by project path. A host entry does not widen the token's project access. Do not commit auth.json; add it to your application's .gitignore before writing credentials.

Local auth.json​

Create auth.json beside composer.json. Replace <token> locally. The username is the literal word token; the password is the complete PAT or service token.

{
  "http-basic": {
    "<broker-host>": {
      "username": "token",
      "password": "<token>"
    }
  }
}

Alternatively, with BROKER_TOKEN already supplied in your terminal environment, write a bearer entry using Composer. The broker accepts both HTTP Basic and Bearer token authentication. This variable is a recipe input, not a broker runtime setting. Avoid shell tracing when handling credentials.

composer config --auth 'bearer.<broker-host>' "$BROKER_TOKEN"

COMPOSER_AUTH​

For automation, supply COMPOSER_AUTH as a secret environment variable containing this JSON, with placeholders replaced. It carries the same HTTP Basic credentials without writing auth.json. Keep the value out of workflow files and logs.

{"http-basic":{"<broker-host>":{"username":"token","password":"<token>"}}}

Verify the install​

In an existing application with a committed composer.lock, install its locked dependencies. These flags suppress package plugins and scripts; review your application's requirements before enabling them.

composer install --no-plugins --no-scripts

For a package not yet in your application, add one visible to your token:

composer require '<vendor>/<package>:^1.0' --no-plugins --no-scripts

Confirm the package appears in composer.lock and its distribution URL points to your broker. A lock file created before switching repositories may retain its previous distribution URLs; changing the repository setting alone does not rewrite that lock file. To move selected packages to broker URLs, run composer update '<vendor>/<package>' --no-plugins --no-scripts, naming each package you want re-resolved. This can change those packages and their required dependencies within your constraints. A full composer update --no-plugins --no-scripts re-resolves all dependencies and can change unrelated versions. composer update --lock does not move existing distribution URLs to the broker.

Resolve authentication failures​

ResponseMeaning and next step
401Authentication was not accepted. Check credential placement, host and port, token expiry, revocation and principal status. Replace an expired or revoked token.
403Authentication succeeded, but a required permission is missing for a visible project. Ask someone managing the project to check the principal's grants and token scope.
404The project or package is absent or hidden from this token. Check the project URL and access with someone managing that project.

Continue with npm, pnpm and yarn setup for front-end packages or the CI recipes for automated installs.