Security warning: Composer 1.x no longer receives security fixes

Composer 1.x is end-of-life. Published vulnerabilities in the latest 1.x releases will not be fixed, so upgrading to Composer 2.x should be a priority. Mirroring third-party repositories through Private Packagist partially mitigates the risk, but does not replace the upgrade.

How does the Composer 1.x shutdown impact you?

Composer commands like require, update, or remove fetch package metadata from Packagist.org.

The metadata contains a list of available packages and versions and all their metadata. Composer uses this data to select the right dependencies and versions for your project.

A composer install run does not access metadata if a composer.lock file with the metadata is present.

So since September 1st, 2025 you have lost the ability to update dependencies or install new packages with Composer 1.x if you rely on Packagist.org, but you can still reinstall from a lock file with Composer 1.x for deployments.

How can Private Packagist help?

Private Packagist will maintain backward compatibility with Composer 1.x at least until September 1st, 2027. Private Packagist is operated by the same team and company as Packagist.org.

Your Packagist.org dependencies will be mirrored by Private Packagist into your own Composer repository. Your Private Packagist URL is added to composer.json and Packagist.org is disabled. You can then continue to use Composer 1.x to update and install new packages from Packagist.org through Private Packagist.

So the only change needed is to reconfigure your projects to use Private Packagist rather than Packagist.org, and you can keep using Composer 1.x.

Are your projects affected?

You are only affected by the 1.x shutdown if you are still using Composer 1.x and if your projects use the default Composer repository Packagist.org.

Check if you're using Composer 1 by running composer --version in your terminal. If it shows version 1.x.x, you're affected by the Packagist.org metadata shutdown.

Check if your composer.lock file has any references to packagist.org e.g. cat composer.lock|grep packagist.org/.

How to migrate projects to Private Packagist?

If upgrading your projects to Composer v2 isn't an option right now then you can configure them to use Private Packagist.

Create a free trial and follow the steps below once for each of your projects. Once completed, you can interact with Composer as you used to.

• Configure authentication for the Private Packagist repository
• Add the Private Packagist repository to your composer.json
• Disable packagist.org
• Delete the vendor directory
• Run composer update mirrors - This command will rewrite the composer.lock file without changing any of the versions of installed packages.

{
    "repositories": [
        {"type": "composer", "url": "https://repo.packagist.com/your-org-name/"},
        {"packagist.org": false}
    ],
    "require": {
        "org/foo": "^1.2.3",
        "org/bar": "dev-master"
    }
}
                    

Can you trust Private Packagist?

Composer, Packagist.org, and Private Packagist are operated by the same people and company. Packagist.org is the default Composer package repository, which the entire PHP ecosystem relies on.

Private Packagist is currently preparing for SOC2 and ISO27001 auditing/certification, and in the meantime we are happy to answer any specific questions on our security practices.

Private Packagist is hosted on AWS in Ireland with additional data mirrors for Composer access in the US and Singapore.