WPackagist is a free service that mirrors the WordPress.org plugin and theme directories as a Composer repository. You require plugins as packages, Composer records exact versions in a lock file, and your build installs the same code everywhere. It covers only items published on WordPress.org.
Why teams use it
Managing plugins through the dashboard makes the live site the source of truth. Managing them through Composer makes your repository the source of truth, which means reviewable changes, repeatable builds and a clear record of what runs. It also gives dependency scanners a manifest to read.
How it works
The WPackagist site explains that it scans the plugin and theme Subversion repositories hourly, fetches the tags of updated packages, maps them to versions, and rebuilds the Composer metadata. Plugins use the vendor name wpackagist-plugin and themes use wpackagist-theme. For plugins it adds trunk as a development version. Themes have no trunk, so the guidance is to use a wildcard constraint for them.
Basic setup
You add the repository to composer.json, require packages, and run an update. By default, packages install into wp-content/plugins or wp-content/themes unless you override the paths with installer paths.
composer require wpackagist-plugin/akismet
composer update
Commit both composer.json and composer.lock, so every environment installs the same versions.
What it does not cover
| Item | Covered? |
|---|---|
| Plugins and themes on WordPress.org | Yes |
| Premium plugins | No, only items published on WordPress.org appear |
| WordPress core | No, use a core installer package |
| Your custom plugins | Host them in your own repository |
The site also notes that version strings Composer cannot parse are ignored, though plugins always have trunk available. Pinning to trunk is rarely a good idea for production, since it moves under you.
A practical workflow
- Define each plugin with a version constraint you can defend.
- Run composer update on a branch, review the lock file changes in a pull request, and test on staging.
- Merge, and deploy by installing from the lock file.
- Run an audit of dependencies on a schedule.
- Keep premium and custom code in a private repository with its own review.
Watch the trust model
A mirror makes installs convenient, but you still depend on the upstream plugin author and the mirror service. Pin versions, review updates, and know which plugins are abandoned. If you commit the manifest, Safeguard can scan a repository for dependency manifests and produce an SBOM, and there is a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a manifest turns into a full dependency list, the same step a Composer lock file enables.
Quick check
Does WPackagist include premium plugins?
No. A package appears only if it is published on wordpress.org.
Should I use trunk versions in production?
Rarely. Trunk changes under you. Pin released versions and commit the lock file.
Sources
Last reviewed: 19 October 2026.
