SatisPress: a Composer repository built from the plugins you already own

A Composer repository generated from a live WordPress install

SatisPress exists to facilitate modern best practices for managing WordPress websites by automating Composer support for private plugins and themes. It is a standard WordPress plugin, and its output is a Composer repository that other projects can consume.

The mechanism is unusual enough to be worth stating plainly. SatisPress does not download your commercial plugins for you. It looks at the plugins and themes already installed on the WordPress site where it runs, zips the versions it finds there, and publishes them as Composer packages. New releases arrive because WordPress's own update process fetches them, using the licence credentials that the vendor already accepted.

That is the trick, and it is why the tool exists. A commercial plugin cannot be fetched programmatically by Composer because the download sits behind a proprietary licensing scheme, a login, or a serial number check. WordPress can fetch it, because the site is already licensed. So SatisPress lets WordPress do the fetching, and then republishes what it got as packages anyone with repository access can install.

The repository description says it generates a Composer repository from installed WordPress plugins and themes, the readme calls it the missing piece for managing WordPress websites with Composer, and the author is Brady Vercher with support from Gary Jones.

The two workarounds it replaces, and why both hurt

The readme describes the problem in terms of the workarounds people actually use, and it is worth reading because the cost of each one is what the project is selling against.

The first workaround is checking the plugin or theme in alongside your custom project code in your version control system. That works, and it has an obvious failure mode: your repository now contains a copy of someone else's code, which is a licensing question as well as a maintenance one, and every update is a manual merge.

The second is creating a separate private repository for each plugin or theme and manually updating it as new versions are released. This is the more common approach for a team with several licences, and the readme is blunt about it: neither option is ideal and both can be a hassle to maintain over time.

Underneath both workarounds sits the same difficulty, and the readme names it: access is usually restricted with proprietary licensing schemes that make it difficult to download releases programmatically. Not because the vendor is being obstructive, but because the licence check is what stops unlicensed use, and any tool that bypasses it is a problem for the vendor.

SatisPress's approach sidesteps that by never bypassing anything. It uses the update process the site is already entitled to use, which is a meaningful difference from a tool that scrapes a vendor's download page.

The four step workflow, and where the cache lives

The readme lists the process in four steps, and the order matters because the first step is a decision and the second one is a copy.

First you choose the plugins and themes that you want to manage. Then SatisPress zips the currently installed versions and stores them in a cache directory. Then, when an update for a managed plugin or theme becomes available, SatisPress downloads and saves it alongside the previously cached releases. And finally a Composer repository is generated that can be included in your composer.json file to download any cached plugin or theme.

The interesting design decision is that the cache accumulates rather than replacing. A new version is saved alongside the previously cached releases, so the repository is not a mirror of what is installed now, it is a history of what has been installed. That is what makes the rollback feature possible.

The second step also has a consequence worth naming. SatisPress copies what is on the site, which means the site where it runs has to have the commercial plugin installed and licensed, and the cache directory is the state that other environments pull from. The readme points to a documentation section with installation notes, usage information and security notes, and those are the pages to read before deciding where this runs, because the security question here is about who can reach the generated repository and who can reach the WordPress site that serves it.

Rollback and diffing, which is the argument without Composer

The readme has a section for people who do not use Composer, and its argument is the strongest one in the document.

SatisPress can still benefit you since it makes releases downloadable directly from your admin panel, so you do not need to log in to vendors' sites to download updates. The second point is the one that matters when something breaks. Oftentimes vendors only provide access to the latest release, so you are stuck if something breaks and you did not save the previous version. With SatisPress, you can download previously cached releases to rollback if needed and compare the code to see what changed.

That is a genuine operational benefit, and it does not depend on Composer at all. A commercial plugin that breaks a site after an update, with no way to get the previous version back, is a real and common outage. Caching every release as it passes through turns that from a disaster into a download.

The comparison capability is the other half of it. Being able to diff two cached releases answers the question that usually has no answer, which is what actually changed between the version that worked and the version that did not.

So the case for the tool does not rest on dependency management. It rests on keeping a rollback path for software you cannot download twice.

What actually ships: a WordPress plugin with vendored dependencies

The package manifest describes the artefact, and it is worth reading because it shows how the plugin is assembled.

{
	"name": "satispress",
	"version": "3.0.0",
	"description": "Generate a Composer repository from installed WordPress plugins and themes.",
	"repository": {
		"type": "git",
		"url": "https://github.com/cedaro/satispress.git"
	},
	"author": {
		"name": "Brady Vercher",

The development dependencies are small and unremarkable: an archiver, a file system helper, a glob matcher and an argument parser. The archiver is there because the whole mechanism is zipping installed plugins.

The distFiles list is the more revealing part, because it describes what ends up in the distributable zip. Alongside satispress.php, the README and the assets, languages, src and views directories, it ships vendor/autoload.php, the Composer autoloader files, the source of the vendored Cedaro WordPress plugin library, composer/semver, psr/container, psr/log, and the Pimple dependency injection container.

So the plugin is distributed with its dependencies vendored and autoloaded, and it uses a PSR container and a PSR logger, with Pimple as the container implementation. That is a conventional, portable PHP layout, and it is why the repository can ship a single zip that a site installs the ordinary way.

The rest of the tree follows the same shape: an src directory for the code, a views directory for the admin interface, a languages directory for translations, a bin directory, a tests directory with a PHPUnit configuration, and a rector.php for automated refactoring.

Where SatisPress is the wrong tool

Four limits, and the first is the dependency on a running WordPress site.

SatisPress can only publish what is installed and licensed somewhere. If your commercial plugin is not installed on the WordPress instance where SatisPress runs, there is nothing to zip, and the repository will be empty for that package. The workflow also assumes the WordPress update mechanism is functioning, which means the site has working vendor credentials, and that the update check is not disabled.

The second is that it is a server side tool, and a server side tool has a server side attack surface. It exposes a generated Composer repository, and the documentation has a security section, which is the right place to look for what the readme does not tell you. A repository of commercially licensed code, served by a site whose administrator session can install the plugin, deserves the same scrutiny as the site itself.

The third is scope. It handles plugins and themes. It does not handle the WordPress core itself, since the readme mentions WordPress in the list of dependencies that are usually plugins and themes and even WordPress itself, but the mechanism described is a zip of installed plugins and themes. And it does not solve anything for a site that uses only free plugins, which WordPress Packagist already provides access to.

The fourth is the release history. Version 2.0.0 came in October 2024, 2.0.1 in December 2025, and 3.0.0 in July 2026, with the last push on 2026-07-13. The gaps are long, which is normal for a plugin that has to keep up with WordPress releases but does mean you should read the changelog before upgrading a site that depends on it.

Licence, versions and who maintains it

The licence is GPL-2.0+, stated in the package manifest, with the repository also carrying a licence reference in its metadata and a CHANGELOG.md at the root. The GPL is a reasonable choice for a WordPress plugin, since WordPress itself is GPL, and it is worth noting for anyone embedding SatisPress in a commercial product. This is not legal advice.

The project is created by Brady Vercher, of Cedaro, and supported by Gary Jones, which is a two person arrangement with an organisation behind it, and the repository carries the usual community infrastructure including a .github directory, a .distignore, an .editorconfig, a .phpcs.xml.dist and a .jshintrc.

The version line moved from 2.0.0 in October 2024 to 2.0.1 in December 2025 and 3.0.0 in July 2026, a major bump that suggests a change in the plugin's own compatibility or its configuration format. The default branch is develop, which is the convention for a project where the stable line lives on a maintenance branch, so the 3.0.0 tag is the artefact to look at rather than the tip of the default branch.

For an adopter, the documentation is the deciding factor and it is linked from the readme, with installation notes, usage information and security notes in the docs directory. The two questions to answer there are where the generated repository is served from and who can reach it, because that determines whether the commercial packages it exposes are as protected as the licences behind them.

Editorial conclusion

SatisPress is the right tool for an agency or a development team that has licensed commercial WordPress plugins and wants the same deployment story for them as for the rest of a Composer managed site, and it is worth adopting even without Composer purely for the cached releases. It is the wrong tool for a site that only uses free plugins from WordPress.org, which WordPress Packagist already covers, and it is the wrong tool for a team that will not run a WordPress instance with the licensed plugins installed on it. Before adopting, read the security notes in the docs directory, decide which single site will be the source of truth for the cached packages, and test a rollback before you need one.

Frequently asked questions

Official sources

1. cedaro/satispress on GitHub
2. Issues
3. README
4. Releases