Pricore: A Self-Hosted Private Composer Registry for PHP Teams

Every PHP team that has been building software for long enough will eventually accumulate internal packages. Shared authentication logic. API clients for internal services. Utility libraries used across multiple projects. This code is too specific to publish publicly and too valuable to copy and paste between repositories. Managing it well has been an unsolved problem for PHP teams for a long time. Pricore is a new open-source answer to it, and it is now in public beta.

The problem with private PHP packages

If you have tried to manage private Composer packages before, you will recognise the options available and their shortcomings.

VCS repositories in composer.json is the most common workaround. You add a Git URL directly to your composer.json, and Composer clones the entire repository every time it resolves dependencies. It works for one or two packages, but it does not scale. Every composer install or composer update that touches a private package triggers a full Git clone. With a handful of packages and several projects, this adds meaningful time to every CI run and local install. The configuration also clutters your composer.json with repository entries that belong in infrastructure, not in application config.

Satis is Composer's official solution for private packages. You define packages in a JSON file, run a build command, and upload the generated static files to a web server. Composer then reads those files rather than cloning repositories directly. It works, and the Composer integration is clean. The problem is operational: every time you release a new version of a private package, you must rebuild the Satis output and re-deploy the static files. For small teams with occasional package releases this is manageable. For teams with active internal package development it becomes a recurring source of friction.

SaaS platforms such as Private Packagist handle the hosting for you and are genuinely polished. The concern is cost, which scales with team size, and the fact that your package metadata lives on third-party servers. For teams with sensitive internal code or data residency requirements, that is a meaningful constraint.

Existing open-source registries have appeared and disappeared over the years. Most were side projects that stalled, leaving teams running unmaintained software with no clear upgrade path.

None of these options is cleanly satisfying. Pricore is an attempt to fill the gap.

What Pricore is

Pricore is a full Composer v2 registry that runs on your own servers. You connect it to your Git repositories, and it handles mirroring, indexing, versioning, and serving packages to Composer - the same way Packagist handles public packages, but for your private ones.

It is built with Laravel and licensed under Apache 2.0. The author has committed to keeping all current features free, with any future premium tier adding new functionality rather than moving existing features behind a paywall.

Token-based access control

Authentication in Pricore is token-based, with per-package access control. You can create read-only tokens for CI pipelines, tokens scoped to specific packages for projects that should only access a subset of your registry, or full-access tokens for administrators. This is considerably more granular than most self-hosted alternatives, which tend towards a single credential for the entire registry.

The token model maps well to how modern PHP projects actually operate: multiple CI environments, multiple deployment targets, and developers with different levels of access to different codebases.

Webhook-driven updates

One of the core weaknesses of Satis is the manual rebuild step. Pricore eliminates it. When you connect a GitHub or GitLab repository and push a new tag, Pricore picks it up within seconds via webhook. The new version becomes available to Composer immediately, with no rebuild and no re-deployment required. This alone removes most of the operational burden that makes Satis feel like a chore at scale.

Support for generic Git and Bitbucket repositories is listed as on the roadmap for teams whose infrastructure does not run on GitHub or GitLab.

Full Composer v2 support

Pricore implements the full Composer v2 API, including the metadata-url endpoint that allows Composer to resolve dependencies efficiently without downloading the entire package index. For registries with large numbers of private packages, this keeps composer install fast rather than degrading as the package count grows.

The packages themselves are served from your own infrastructure, meaning no third-party dependency for package resolution and no external calls during installation.

Web dashboard

Pricore ships with a web dashboard covering package browsing, access token management, and download statistics. For teams that have been managing private packages via Satis static files - where visibility into what has been downloaded, by whom, and when is essentially nonexistent - having download activity surfaced in a dashboard is a meaningful quality-of-life improvement.

It also reduces the CLI dependency for day-to-day administration. Token management and package inspection can be done through the browser rather than requiring SSH access or configuration file edits.

Getting started

Pricore ships with a Docker setup and is designed to be running in roughly sixty seconds. The setup involves pointing it at your Git repositories, generating tokens, and adding the registry URL to your projects' composer.json:

"repositories": [{ "type": "composer", "url": "https://your-pricore-instance.example.com" }]

From that point, composer require your-vendor/private-package works as it would for any public Packagist package.

Built on Laravel

Pricore being a Laravel application is worth noting specifically. PHP teams managing private packages are, statistically, likely to be working with Laravel - and a registry codebase written in the same framework your team uses daily means the source is legible, extensible, and improvable without learning a new stack. If Pricore is missing a feature your team needs, the barrier to contributing or forking is low.

It also means the deployment and operational model is familiar. Pricore runs like any other Laravel application: a web server, a database, a queue worker for processing webhooks, and optionally a cache layer. No specialised infrastructure is required.

Worth considering if

Pricore is in public beta, which means the API surface may still shift and some rough edges should be expected. That said, the core use case - replacing VCS repositories and Satis with a proper self-hosted registry - is clearly implemented and the project is under active development.

It is worth evaluating for any PHP team that maintains more than a couple of private packages and is currently managing them with composer.json VCS entries or a manually-rebuilt Satis instance. The webhook-driven update model alone makes it a significant improvement over Satis for teams with regular internal package releases.

The project is available at github.com/pricorephp/pricore.