WP Packages vs WPackagist

For years, WPackagist was the go-to Composer repository for WordPress plugins and themes. In March 2026, WPackagist was acquired by WP Engine, a private-equity backed company. Tooling this central to the WordPress Composer workflow shouldn't be owned by a single corporation — it should be independent and community-funded.

How they compare

Closed plugins

When the WordPress.org plugin directory closes a plugin — typically for security vulnerabilities, author abandonment, or guideline violations — the plugin is no longer downloadable from wp.org. WP Packages mirrors this behavior: closed plugins are removed from the repository, so Composer cannot install or upgrade to a closed version.

WPackagist continues serving closed plugins with no notice to users. We've heard from developers who migrated to WP Packages and discovered they had been depending on plugins that wp.org closed years earlier — including some closed for security reasons. If your composer.lock references a plugin wp.org has since closed, WP Packages surfaces it; WPackagist silently keeps installing it.

All currently closed plugins are listed on the status page and available via the closures API.

Performance

WP Packages supports Composer v2's metadata-url protocol, which lets Composer fetch metadata for only the packages it needs. WPackagist still uses the older provider-includes approach, which forces Composer to download large index files containing metadata for thousands of packages before it can resolve your dependencies.

Composer resolve times

Cold resolve (no cache) — lower is better.

Metadata & caching

Benchmarks run from a single location using Composer 2.7+. Results may vary by region and network conditions. Benchmark scripts are open source.

The case for independence

WPackagist was originally built and maintained by Outlandish, who operated the service for over a decade. In its later years, the project suffered from neglect — slow updates, limited maintenance, and no meaningful community input into its direction.

Its acquisition by WP Engine raises important questions. When infrastructure this foundational to the WordPress developer workflow is controlled by a single corporation, the community loses its voice. Decisions about availability, pricing, and direction are made in boardrooms, not in the open.

WPackagist publishes its application code, a Dockerfile, and a handful of deployment helpers — but not the production infrastructure that runs the service. Cloud provisioning, environment configuration, CI/CD — all proprietary. The public repo is enough to build the container, not enough to reproduce the running service.

The public repo has also diverged from production at times: gaps the community has had to catch and report (e.g. #556, #557) before they were addressed. With infrastructure closed, there's no built-in way for outside observers to know when the public source no longer reflects what's actually running. WP Packages takes the opposite approach: every component that runs the service — the Go application, the Ansible playbooks, the Caddy configuration, the database tooling — lives in the public repo. The codebase is what runs in production, and anyone can clone it and spin up their own instance.

Built by Roots, maintained since 2011

WP Packages is built by Roots, the team behind Bedrock, Sage, Trellis, and Acorn. Since 2011, Roots has been continuously improving and maintaining open source WordPress tooling. We pioneered the use of Composer in WordPress development and have a proven track record of long-term commitment to the ecosystem.

WP Packages is fully open source and designed for community collaboration. Every line of code is public, contributions are welcome, and the project's direction is shaped by the developers who use it.

The repository includes everything needed to run your own instance: the application code, documentation on how it all works, and the full Ansible setup for deploying to production. Anyone can fork it and build their own WordPress Composer repository.

Community-funded, community-driven

Unlike corporate-backed alternatives, WP Packages is funded entirely by the community through GitHub Sponsors. Your sponsorship directly supports the infrastructure, development, and maintenance of WP Packages and the broader Roots ecosystem.

Sponsoring Roots means investing in independent, community-funded WordPress tooling that serves developers — not shareholders.

Migrating from WPackagist

Switching from WPackagist takes one command. Use the migration script to automatically update your composer.json:

Manually migrate