satisfy

PHP teams using Composer may need a private catalog of packages and someone to maintain which repositories it includes. Satisfy adds a web interface around Satis, the tool that generates that package repository’s metadata. Maintainers can manage configuration and trigger builds without hand-editing the configuration file for every change. It is a management wrapper, not Composer itself. Protect its administrative and build access, because changing package sources can affect the code developers and deployment jobs later install.

Current guidance

The historical chart identifies ludofleury/Satisfy and a Docker wrapper around Composer Satis. The project’s README now directs users to project-satisfy/satisfy. Satisfy provides web management of repository configuration, build triggering and optional authentication. Composer’s own documentation describes Satis as a generator for a static private package repository. An available upstream repository does not, by itself, establish a supported current Kubernetes package or PHP compatibility matrix for this wrapper.

Before adopting it, decide whether maintainers need a web editing interface or whether reviewed repository configuration and a controlled build job are sufficient. Keep package-source credentials separate from published repository metadata. Review webhook authentication, access to the administration interface and permissions of any process able to change package sources or execute builds.

For migration, preserve the Satis configuration, package inclusion rules, generated metadata, distribution archives and client authentication settings. Test a clean Composer install using a representative lock file; existing developer caches can hide missing packages. A different package service may support Composer clients while changing retention, mirroring and access control, so verify those properties before changing repository URLs.