Can I install a private GitHub repository with Composer?

Yes. Add the repository to the repositories section of composer.json with type vcs, and give Composer a GitHub token in auth.json. Every person and CI job that installs the package needs access to the repository, so this works for your own team but not for customers.

What is the difference between Satis and Private Packagist?

Satis is an open-source tool that generates a static Composer repository you host and secure yourself. Private Packagist is a paid, hosted Composer repository from the makers of Composer, with per-user and per-customer authentication.

What is the best Private Packagist alternative for selling packages?

If you sell a package to customers, look for a registry that also issues license keys and takes payments. Privato hosts private Composer and npm packages, creates a license key for every purchase through Stripe, and limits each key to the versions it paid for.

Do my customers need anything besides Composer?

No. A private Composer repository is just another repository entry in composer.json plus credentials in auth.json. Customers run composer require as usual.

How to host private Composer packages (2026 guide)

Five ways to host private Composer packages, from VCS repositories and Satis to Private Packagist and Privato, and how to choose between them.

Composer installs public packages from Packagist.org. As soon as a package is private, because it's internal to your company or because you sell it, you need somewhere else to host it and a way to decide who can install it.

This guide walks through the five common options, what each one is good at, and where each one stops working.

1. Point Composer at a private Git repository

The simplest option needs no extra infrastructure. Add the repository to composer.json and Composer reads tags and branches straight from Git:

{
    "repositories": [
        { "type": "vcs", "url": "https://github.com/acme/billing" }
    ],
    "require": {
        "acme/billing": "^2.0"
    }
}

Composer then needs a GitHub token in auth.json to read the repository. That's fine for a small team, but it scales badly: every project lists every private repository, installs are slow because Composer scans Git history, and anyone who installs the package needs access to its source repository. You can't give a customer access to version 2 but not version 3.

2. Generate a static repository with Satis

Satis is the open-source Composer repository generator maintained by the Composer team. You list your repositories in a satis.json file, run a build, and Satis writes a static packages.json (and optionally zip archives) that you serve from your own web server.

Satis is free and fast to install from, but you own everything around it: hosting, HTTPS, rebuilding when you tag a release, and protecting it. Authentication is usually one HTTP Basic password in front of the whole repository, so everyone who has the password can install every package and every version. Read Privato vs Satis for a feature-by-feature comparison.

3. Use Private Packagist

Private Packagist is the commercial, hosted Composer repository from the company behind Composer. It syncs packages from GitHub, GitLab or Bitbucket, mirrors Packagist.org, and gives each developer or CI job its own token. Its vendor features give each customer a unique repository URL and token limited to specific packages and version constraints.

Private Packagist is a strong choice for teams managing internal dependencies. For selling packages, it controls access but doesn't take payments: you still need a shop or billing system and the API to create and expire customers when they pay. There's also no free plan, and it only supports Composer. See Privato vs Private Packagist for details.

4. Use a general artifact manager

Tools such as GitLab's package registry, JFrog Artifactory and Cloudsmith host Composer packages alongside Docker images, npm packages and other formats. They make sense if your company already runs one. They're built for internal teams, so per-customer licensing, payments and a customer-facing portal aren't part of them.

5. Use Privato for packages you sell

Privato is a hosted private Composer and npm registry built for selling packages. You connect a GitHub repository and Privato syncs every tagged release. Customers buy through Stripe, receive a license key, and install with Composer:

composer config repositories.acme composer https://acme.privato.pub/composer
composer config --auth http-basic.acme.privato.pub "[email protected]" "LICENSE-KEY"
composer require acme/billing

Each license is tied to a release channel, which decides which versions it can install, how long it gets updates for, and whether access stops or freezes when it expires. Customers manage their keys in a branded customer portal, and you can serve the registry from your own domain.

Which option should you choose?

A handful of internal packages and a small team: VCS repositories in composer.json.
Internal packages, and you're happy to run a server: Satis.
Many internal packages, mirroring and security monitoring for a company: Private Packagist.
Packages you sell to customers: Privato, which combines the registry with license keys, payments and a customer portal. Here's how selling a Composer package works.

How to host private Composer packages