On Tue, Oct 6, 2026, at 5:32 AM, Matthieu Napoli wrote: > Hi internals, > > I'd like to start the discussion on a new RFC: > https://wiki.php.net/rfc/single-binary-cli-fpm > > It proposes a new `--enable-cli-fpm` build option that links the FPM > SAPI into the `php` executable. A combined `php` binary runs FPM when > its first argument is `--fpm`, or when it is invoked under a name > starting with `php-fpm` (e.g. a `php-fpm` symlink to `php`). Everything > else is the CLI, unchanged. The standalone `php-fpm` executable is > still built. > > ``` > php script.php # CLI, as today > php --fpm --nodaemonize -y /etc/php-fpm.conf # FPM > > ln -s php php-fpm > ./php-fpm --nodaemonize -y /etc/php-fpm.conf # FPM, through a symlink > ``` > > The motivation is that the two executables share almost all their code. > I did some measurements with [Bref](https://bref.sh) on AWS Lambda to > illustrate its usefulness for this specific system. Shipping one binary > instead of two: > > - removes one of the two ~26 MB executables from the runtime (leaving > more room under the 250 MB limit for application code) > - cuts the cold start of a minimal FPM application by 70 ms (-25%), > because FPM no longer loads a second copy of the engine right after the > CLI loaded it > > It makes a difference on AWS Lambda, it might also help on other > systems where boot speed (autoscaling, serverless, etc.) or disk size > is important. > > And from a simplicity perspective I like the idea of having a single > binary with FPM "built-in". > > There's a secondary vote on enabling the option by default, as Marc > suggested when I requested RFC karma. > > I'd especially welcome feedback from packagers: > > 1. Would you consider shipping `php-fpm` as a symlink to a combined > `php` binary, with the FPM package keeping only the configuration and > service files? > 2. Should this stay opt-in, or be enabled by default? > > The implementation is at https://github.com/php/php-src/pull/23558 > (thanks Jakub and Marc for the reviews so far). > > Thanks, > Matthieu Napoli
I can see the value here, and I am not opposed in concept. My one question is that this essentially privileges the FPM SAPI, right at the time that we're seeing more and more alternate SAPIs. (FrankenPHP, Swoole, various async tools that just run on the CLI, etc.). Would there be any negative impact for them? If at some point in the future another SAPI (eg, FrankenPHP or something similar to it) became a first-class web-serving SAPI in php-src, would we then need to package multiple variants? (FPM-CLI, Franken-CLI, etc.). I just want to make sure we don't inadvertently lock in FPM as The Way PHP Runs(tm) just at the time that it no longer is. --Larry Garfield
