Skip to main content
Package BrokerStart the quickstart

For Magento and PHP agencies

Keep every client’s keys off your developers’ laptops

Give each developer one personal token for their projects. Store each client’s vendor keys in that client’s project in the broker; give CI a read-only service token for that project.

Start the quickstartSee client access boundaries

2.0 is in development; no tagged release yet. Marketplace sources: built, in final verification.

Illustration · developer access

One personal token
Opens only the projects your grants allow

  • Client A project · granted
  • Client B project · granted
  • Client C project · no grant, no access
Client vendor keys stay in the broker. Developers install with broker tokens.

Rotate one client’s keys without changing everyone’s builds

When several clients’ builds share vendor credentials, a purchased extension can reach any build using those credentials. Replacing a shared key means updating every build that uses it.

Shared vendor credentials

  • Client keys are copied onto laptops and into CI.
  • One shared source makes its packages available to every build using it.
  • Replacing that key affects all those builds.

One project per client

  • Each project owns its purchased package sources and encrypted keys.
  • Developers and CI receive broker tokens, never vendor keys.
  • Replace a client’s source key in the broker; other clients’ sources stay separate.

Organization-owned sources can supply shared packages. Keep purchased extensions project-owned when you need a client boundary. Source ownership and project precedence.

Three clients, separate sources and install access

This fictional example uses one organization with three client projects. Each group has access only to its own project; no organization-wide grants or shared purchased package sources apply.

  1. Store the client’s keys

    Create a project-owned source for the client’s vendor repository. Its credentials are encrypted at rest; organization admins and anyone with both the database and master key can decrypt them.

  2. Grant the project

    Map a group from an OIDC identity provider such as Dex, or grant an individual e-mail address. Identity and group membership stay in your identity provider.

  3. Install with broker tokens

    A developer’s personal token covers their allowed projects. CI uses a read-only service token bound to one project. The same token works for Composer and npm.

Identity provider · OIDC groups · example-agency

Client A: project acme, credential set Aacme-devs has a grant to project acme, which owns source acme-magento and credential set A. The source connects to repo.magento.com. No project connects to another project’s credentials.acme-devsProjectacmeacme-magentoCredential set ASourcerepo.magento.comClient B: project globex, credential set Bglobex-devs has a grant to project globex, which owns source globex-magento and credential set B. The source connects to repo.magento.com. No project connects to another project’s credentials.globex-devsProjectglobexglobex-magentoCredential set BSourcerepo.magento.comClient C: project initech, credential set Cinitech-devs has a grant to project initech, which owns source initech-magento and credential set C. The source connects to repo.magento.com. No project connects to another project’s credentials.initech-devsProjectinitechinitech-magentoCredential set CSourcerepo.magento.com
Each group has a grant to its client’s project. Each project owns its source and credential set. Organization-wide access is excluded from this example.

Each group can install only from its project in this example. Organization roles can allow broader access. Organization and project grants.

When the team or a vendor repository changes

  • A freelancer joins one client. Grant only that project, with no organization role. Use an install-only role if they do not need to publish. Their e-mail domain must be accepted by your identity provider configuration; otherwise use an identity in your agency’s provider.
  • A developer leaves. After moving existing keys into the broker, rotate the old copies once. Suspending the user in the broker takes effect on their next request. Group removal takes up to 12 hours for sessions and 24 hours for personal tokens; e-mail grants and CI tokens need separate removal or revocation. Personal tokens require a broker sign-in at least daily.
  • A vendor repository is down. Archives already installed through the broker are served from its storage. Versions never downloaded through the broker still need the vendor repository. Optional retention rules can remove unused public proxy archives.

Composer uses one credential for the broker host; npm needs a configuration line per project. Personal and service token policy.

Add people without counting seats

The software does not count or cap users. No licence fee or per-user, per-project or per-client charge: you pay for hosting and operations, from USD 5 a month on Workers Paid plus usage, or your own Node host. You operate backups, upgrades and your identity provider.

If you would rather pay for a hosted Composer service, consider Private Packagist Cloud. Its price model counts users and suborganizations. Compare with Private Packagist.

Package Broker is AGPL-3.0-only. Review the licensing and contribution terms before choosing it for your agency.

Try one client project before switching the agency

Evaluate alone with a local administrator and a token; no identity provider is needed for that first trial. Connect your identity provider for the team, then check one project’s source selection and install access before moving more clients.

Migration guides cover Private Packagist, Satis and Packeton. Ask about your current setup before switching.

Start the quickstartAsk about your setupWatch releases on GitHub