Re: [RFC] Single binary for CLI and FPM

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