Private Composer delivery composer install. But only if you paid.

We build private Composer delivery with access per customer and license. For developers nothing changes: add the repository, store the token, install. We deliver our own Magento modules exactly this way.

Have your delivery setup reviewed
What developers see
$ composer config repositories.acme composer https://repo.example.com
$ composer require acme/b2b-pricing
✓ Token active · license valid · archive delivered

$ composer update acme/b2b-pricing
✕ License expired · access denied

Where it breaks

A repository is set up quickly. The trouble starts with the first customer.

  • Shared tokens

    One token travels between agency, developers and build server. After that nobody can rotate it without breaking something somewhere.

  • License and access drift apart

    The contract has ended, but the repository keeps delivering updates. Or the other way round.

  • Builds depend on the download

    Missing archives, stale metadata or a manual release step turn a normal deployment into a support case.

  • Every error looks the same

    Token expired, package missing, license does not cover it: Composer reports the same thing in all three cases.

The flow

Four moments, one access decision.

  1. Release

    The pipeline builds an immutable archive from a tested version and publishes it once.

  2. Install

    Composer asks, the platform checks token and license, then delivers metadata and archive.

  3. Revoke

    Withdraw a token or license without renaming or rebuilding packages. The next request is refused.

  4. Support

    The log shows which check failed, without anyone having to see the token.

Your deployment process is called crossed fingers? We’d suggest a pipeline.

Build, test, publish and deliver a release: automated properly once, instead of by hand every time.

Have your delivery setup reviewed
Four-leaf clover under a glass dome

What you need

Not every private package needs its own platform.

SatisHosted registryLicense-based delivery
Job Generate and host Composer metadata Provide private packages to teams Deliver packages to paying customers
Customer access Build it yourself Accounts and permissions From customer and license data
Revoking tokens Build it yourself In the vendor backend Automatically with the license
Operation Your team Vendor Your team or with us
Fits A few internal packages Development across several teams Commercial modules with licenses

If your current setup is enough, we will tell you so. A new platform is not automatically the right answer.

Technical questions

What teams should clear up at the start.

Do customers keep using the normal Composer commands?
Yes. They add the private repository and log in with their own token. Everything else stays Composer 2 as usual.
Can the same token run locally and in CI?
Technically yes. Separate tokens are easier to rotate, attribute and revoke, though. That is why we separate people, projects and pipelines.
What happens when a license or support period ends?
You decide: end access immediately, limit it to versions already released, or follow another contractual rule. The platform applies it consistently.
Do existing Magento modules have to be rebuilt?
Usually not. The packages need valid Composer metadata and versioned archives. Access and delivery sit around the package, not in its code.
Can the platform run on our infrastructure?
Yes. Entirely with you, with us, or split. We agree on hosting, monitoring and incident responsibility beforehand.

Find the gap before your next customer does.

Have your delivery setup reviewed