Buyers

Project and licence activation

Buying a package is not the last step. You also activate the licence against the project that needs it before tokens in that project can install it.

What a project is

A project is one Magento install, or one environment of an install. Most teams create three: production, staging, and a local development copy. You can also use a project per branch, per CI runner, or per customer site you build for. The shape is up to you. What matters is that a project is the thing your Composer credentials belong to, and the thing that licences activate against.

You create projects from the Projects and Tokens area of your account. You can have as many as you need.

Why activation is a separate step

A licence sits on your account. A project is one of potentially several installs you run. When you buy a single-activation licence you have to tell us which install gets to use it; when you buy a multi-activation licence you choose which of your projects each activation goes to. Either way, the act of pinning a licence to a project is what turns purchased entitlement into installable access for that install.

Keeping activation separate from purchase also means a multi-environment org can buy once and decide later which environment goes live first, or move the licence between environments as their setup changes.

How to activate a licence to a project

  1. Sign in and open My licences from your account menu.
  2. Find the licence you want to activate. Each licence row shows how many activations it has in total, and how many are still free to spend.
  3. Click Activate on the licence. A panel opens with one project picker per free activation slot.
  4. For each slot, choose an existing project, or pick "New project" and give it a name (and optionally a production domain).
  5. Submit. The licence now appears on each chosen project under Activated licences.

If a project you activated against did not already have a Composer access key, one is generated for you and revealed inline once. Capture the private key right then, or use the Download auth.json link on the key row in Projects and Tokens. The reveal is shown once and once only.

Moving a licence between projects

There is no "move" button. To shift an activation from one project to another, unassign it from where it is now, then activate it against the project you want.

  1. Open Projects and Tokens and find the source project.
  2. In the project's Activated licences table, click Unassign on the row you want to move. The slot returns to the licence.
  3. Open My licences, click Activate on that licence, and pick the new project for the now-free slot.

Unassign and re-activate are both instant. There is no cooldown and no billing impact.

Who can activate

Activation spends a slot on a licence, so it is a workspace-level action. Workspace members with the owner, admin, or developer role can activate and unassign licences against any project in the workspace. The billing and viewer roles, and project-level guest roles, cannot.

The licence and the target project must belong to the same workspace. You cannot activate a licence held by one workspace onto a project owned by a different workspace, even if you happen to belong to both.

See Team and roles for the full role matrix.

What tokens in the project see after activation

Once the licence is active on a project, any access key that belongs to that project can install the package. Composer running with that project's credentials in auth.json discovers the package in /packages.json, fetches its metadata, and downloads the archive the same way it does for any other package.

Access keys are scoped to one project, so a key from your production project will only see packages activated against production. A key from staging will only see what is activated against staging. That separation is the whole point of activating per project.

If the package you activated requires other packages from the same vendor, those are auto-included for the same project; you do not need to activate them separately. Cross-vendor requirements still need their own licences.

What happens on unassign

Unassign drops the link between the licence and the project. The slot returns to the licence so you can spend it somewhere else.

  • The project's access keys stop seeing this package. The next composer install or composer update from that install will no longer resolve it from the registry.
  • Files already on disk in vendor/ are not touched. An install that has the package extracted in its tree at unassign time keeps running until you next reinstall or wipe vendor/.
  • The licence itself is untouched: billing, expiry, and refund eligibility stay exactly as they were. Unassign is purely about which project gets to use the slot.
  • Access keys are not revoked or rotated by an unassign. The same keys keep working for everything else the project is still entitled to.

Common gotcha: buying does not auto-activate

A common surprise after checkout: the order is confirmed, the licence appears under My licences, and the package still will not install. The reason is almost always that the licence is sitting unassigned on the account. Until you activate it against a project, no access key in any of your projects can pull it.

You can have a perfectly valid, fully paid licence and zero installable access at the same time. That is by design. The fix is one click: open My licences, click Activate, and pick a project.

Composer hints for this state look like a 404 on the package metadata or "package not found" at composer require time. If you see that immediately after a purchase, check the activation status first.

See also

  • API tokens - how the per-project access keys work and how they pair with activated licences.
  • Organisation billing - how licences are owned, who in your workspace can act on them.
  • Composer setup - adding the registry, dropping in auth.json, installing your first package.