Re: [RFC] Single binary for CLI and FPM

I like this idea. Aesthetically, it makes PHP look more like mainstream languages such as Ruby or Python, in my opinion. Something interesting is that on Linux when configuring a PHP web app with Nginx, every request goes from the server to the php-fpm service (i.e: php8.4-fpm.socket on Debian). I'm actually on openSUSE Leap 16.0, and the socket/service execution step looks like the following: ``` ExecStart=/usr/sbin/php-fpm --nodaemonize --fpm-config /etc/php8/fpm/php-fpm.conf ``` So yeah, if the PHP-FPM looks like PHP-CLI, then migrating to a single binary would be ok, as the dynamic libphp.so library is not an option based on your RFC (co. However, I have a concern about the OS package maintainers from major Linux package repositories (dpkg, rpm and others). I think, in the case that this becomes the default behavior, they would need to be aware that PHP-FPM is now on a symlink of PHP-CLI (else what happens when you download PHP-FPM?).. Because they would need to take the required steps to rebundle PHP (configure the symlink of PHP-FPM to php-cli or deprecate it). Something similar to mysql now being a symlink of now MariaDB by default would take in place. Not forgetting that all of those operating systems would have to configure the PHP-CLI package to include the necessary service manager (systemd) script previously available on PHP-FPM. Because there are also a lot of IT infrastructures that depend on it (think about Docker containers, for instance).. Also, how would it clash with users of OSes without systemd (openrc, runit)?. For the rest, the idea is cool. My concern is around the maintainers of these packages. I think the safest action would be to have it first as a new optional ./configure flag and then progressively pass it to a default behavior. Because this would maybe enable use cases like serverless PHP (the https://bref.sh project) to be able to have that option by default from a specific Docker image of PHP with that config. And well, I think that having a shared library libphp.so would actually be a way easier solution to fix it. I have a question about that approach: Isn't it possible to do it by default without any PHP modification? Kind Regards, David Maye. > El 06/10/2026 12:32 Matthieu Napoli <matthieu@mnapoli.fr> escribió: > > > 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