Packagist.org serves only public packages; how should a team distribute private PHP packages to its own projects instead?

## Why not Packagist.org **Packagist.org** is a public index. It crawls repositories it can reach and publishes their metadata (names, versions, requirements, download locations) to every Composer client in the world. Private code has no place there. Even when the code host requires authentication, the metadata would still announce the package's existence and structure. Private packages need a **private repository**: a source that only your projects are configured to read and only authenticated users can fetch from. ## The three ways teams do it | Option | What you run | Good for | Costs | |---|---|---|---| | `vcs` repositories | nothing extra | two or three private packages | every project repeats the list; Composer scans each repository on resolution; credentials per code host | | **Satis** | a static `composer` repository you build and host | many packages, full control | you run the build job, the hosting and the authentication | | hosted private registry | a service speaking the `composer` repository protocol | teams that want access control and mirroring managed | a subscription and a third party in the install path | ### Direct vcs repositories Each project adds each private repository as a `vcs` entry. It works immediately, but it scales badly. Repositories declared by a dependency are **not** loaded for the root project, so a private package that depends on another private package forces every consuming project to list both. Resolution also slows down, because Composer reads tags and branches from each repository itself. ### Satis **Satis** is Composer's open-source static repository generator. You give it a `satis.json` naming the repositories to include (often `vcs` entries), and either `"require-all": true` or an explicit list of packages. It writes a `packages.json` and the per-package metadata files, and can also build dist archives. You host the output on any web server behind authentication, re-run the build when packages change (typically from the same hooks you would point at Packagist), and each project needs a single `composer` repository entry. ### A hosted private registry Commercial registries implement the same `composer` repository protocol with user management, per-package permissions and mirroring of dist files. The mirroring means installs keep working when a code host is down. The trade-off is operational: someone else runs it, and it sits on your install path. ## Credentials Composer reads credentials from **`auth.json`** (in the project directory or the global Composer home) or from the **`COMPOSER_AUTH`** environment variable, which holds the same JSON. The supported forms include: - `http-basic`: a username and password (or token) per host; - `bearer`: a bearer token per host; - `github-oauth`, `gitlab-token` and similar: tokens for code-host APIs. Rules that keep this safe: 1. **Never put credentials in a repository URL in `composer.json`.** That file is committed and shared. 2. **Keep a project-level `auth.json` out of version control**, or better, inject `COMPOSER_AUTH` from the CI secret store. 3. **Give CI a read-only token** scoped to the packages it needs. ## Advisory data for private packages Packagist.org publishes security advisories for public packages. A private `composer` repository can publish advisories too: its `packages.json` may advertise a `security-advisories` section with an `api-url` or per-package metadata, and Composer then blocks and audits private packages as well. Without that, advisories only exist for what Packagist knows about. ## Keeping a private registry current A private registry has the same freshness problem as Packagist. A static registry built with Satis only knows about tags that existed at its last build, so teams trigger the build from a hook on each private repository or on a short schedule. A hosted registry typically updates from hooks as well. When a new internal release "does not exist", the first check is the same as on Packagist: does the registry's `packages.json` list it yet? ## Choosing - A handful of private packages, one or two projects: `vcs` entries are fine. - A growing internal library set: a registry, built with Satis or hosted, restricted with `only` to your vendor prefix and listed above Packagist. - Many teams: a hosted or self-run registry with per-team access control, plus an audit trail of who can publish.