Private Composer delivery

Private Composer packages, controlled per customer

A registry alone does not decide who may download which release. We connect Composer, customer licenses, access tokens and traceable delivery—without changing how developers install packages.

Review your delivery setup See the request flow
  • Composer 2 compatible
  • Access tied to customers and licenses
  • Tokens can be rotated or revoked
  • Self-hosted or operated with us
Composer request Access granted
Release Package published
Registry Metadata resolved
Access License checked
Delivery Build receives dist
Composer setup composer config repositories.softwaresilo composer https://repo.softwaresilo.io composer config --auth bearer.repo.softwaresilo.io YOUR_TOKEN
  1. 01Token belongs to an active customer account
  2. 02Requested package is covered by the license
  3. 03Approved archive is returned and logged
The developer keeps the familiar Composer workflow. Access decisions happen in the delivery path.

Control before scale

A package repository is only one part of delivery

The operational problems start after the first customer gets access. Credentials, licenses, releases and support cases need one consistent path.

  1. 01

    Shared credentials outlive the project

    A token copied between agencies, developers and build systems is difficult to rotate and almost impossible to attribute.

    ControlIssue separate credentials for each customer or pipeline and revoke them without republishing packages.

  2. 02

    Repository access drifts away from the license

    A customer may still reach modules, add-ons or releases that are no longer covered by the commercial agreement.

    ControlResolve package access from the active customer license for every request.

  3. 03

    Builds depend on a fragile download path

    Missing archives, stale metadata or manual release steps turn routine deployments into support incidents.

    ControlPublish versioned metadata and immutable archives through a monitored Composer-compatible path.

  4. 04

    Support sees the error, but not the cause

    A failed install can look identical whether the token expired, the package is missing or the customer lacks access.

    ControlRecord the decision and return a clear failure reason that support can trace.

Request flows

One delivery path, four operational views

Release, installation, revocation and support use the same package and access data. Select a flow to see where the decision is made.

Source Tagged release
Build Tests and package
Registry Metadata and dist

Release pipeline

A tested version becomes an immutable Composer artifact

The pipeline publishes the package once. Registry metadata then points authorized installs to that exact archive.

Input
A versioned, tested release from the source repository.
Decision
Package name, version and archive must match the release policy.
Result
One immutable artifact is available to eligible customers.

Operating model

Clear ownership from release to support

The delivery layer should not become an undefined black box. Your team owns the software release; the platform enforces access and delivery; operations can remain internal or be handled with us.

Swipe horizontally to compare responsibilities.

Responsibilities by operating areaYour teamDelivery platformOptional operation
Release approvalOwns version and qualityAccepts approved artifact—
Customer package accessDefines commercial accessEnforces license mappingReviews exceptions
Token lifecycleAssigns users or pipelinesIssues, rotates and revokesMonitors abnormal use
Registry and archivesPublishes releasesServes metadata and distMonitors availability
Support diagnosisHandles package behaviorProvides request evidenceTriages delivery failures

The exact split is agreed before implementation. Managed operation is optional, not a hidden requirement.

Choosing the right scope

Not every private package needs a delivery platform

The right option depends on whether you need a repository, a managed registry or access tied directly to customer licenses.

Swipe horizontally to compare the approaches.

Decision pointStatic SatisManaged registryLicense-aware delivery
Primary roleGenerate and host Composer metadataOperate a private package registryControl delivery to customers and builds
Customer accessCustom implementationAccount and permission modelMapped to customer and license data
Token lifecycleCustom implementationManaged credentialsRotation and revocation tied to access
Audit contextInfrastructure logsRegistry activityCustomer, credential and package decision
OperationsYour teamSaaS providerYour team or managed with us
Best fitSmall, stable internal package setPrivate development across teamsCommercial package delivery to customers

This comparison describes the typical role of each approach. The exact feature set still depends on configuration and vendor plan.

Architecture review

The review ends with a delivery plan you can implement

We trace the current release and install path, identify the control gaps and turn the findings into an implementation sequence.

  1. 01

    Map the current path

    Repositories, package builds, credentials, license data and customer onboarding.

  2. 02

    Test the failure cases

    Expired access, missing versions, leaked credentials and unavailable archives.

  3. 03

    Define the target architecture

    System boundaries, request flow, ownership, monitoring and recovery.

  4. 04

    Plan the rollout

    Migration order, customer communication, validation and rollback points.

Technical questions

What teams usually clarify first

The implementation depends on your package catalog, customer model and operating boundaries.

Do customers still use normal Composer commands?

Yes. They configure the private repository and authenticate with a dedicated token. Package constraints, update commands and Composer 2 workflows remain familiar.

Can a customer use the same token in local development and CI?

It is technically possible, but separate tokens are easier to rotate, attribute and revoke. We normally separate people, projects and automated pipelines.

What happens when a license or support period ends?

That rule is defined explicitly. Access can end immediately, allow previously released versions, or follow another commercial policy. The delivery layer enforces the agreed rule consistently.

Does this require rebuilding existing Magento modules?

Usually not. Packages need valid Composer metadata and reliable versioned archives. The access and delivery controls sit around the package rather than inside its Magento code.

Can the platform run in our infrastructure?

Yes. The target model can be self-hosted, operated with us or split between both teams. Hosting, monitoring and incident ownership are agreed before implementation.