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 <[email protected]> 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
