> mod_php runs in the same process as your http server, with the same rights.

mod_php was great for local iteration or when you wanted a very simple setup (and the same could be said about mod_python etc.), but most people have moved over to PHP-FPM nowadays: https://cwiki.apache.org/confluence/display/HTTPD/PHP-FPM There's probably more recent information somewhere, but this pretty much covers it.

Here's a very simple setup of two separate processes, with Supervisord (this is what runs in my self-contained dev container, but no reason why someone couldn't do something similar with systemd, or on a container cluster, with different users/permissions for each process):

  [supervisord]
  nodaemon=true
  [program:php-fpm]
  command=/usr/sbin/php-fpm -c /etc/php/fpm/php-fpm.conf --nodaemonize
  [program:apache2]
  command=/usr/sbin/apache2ctl -DFOREGROUND

And approx. how the Apache configuration might look:

  LoadModule proxy_fcgi_module "/usr/lib/apache2/modules/mod_proxy_fcgi.so"
  <FilesMatch \.(php|phar)$>
    SetHandler "proxy:fcgi://127.0.0.1:9000"
  </FilesMatch>

Conceptually, that's not very different from WSGI for Python: https://en.wikipedia.org/wiki/Web_Server_Gateway_Interface#S...

But yeah, I agree about the shortcomings of mod_php.

> mod_php was great for local iteration or when you wanted a very simple setup (and the same could be said about mod_python etc.), but most people have moved over to PHP-FPM nowadays: https://cwiki.apache.org/confluence/display/HTTPD/PHP-FPM There's probably more recent information somewhere, but this pretty much covers it.

  php -S localhost:8000

https://www.php.net/manual/en/features.commandline.webserver...

Or even simpler, just make your application listen to a particular port and implement a full HTTP server, and reverse proxy to that (or not) using whatever tech you fancy (Apache, nginx, Cloudflare, Cloudfront, ELB...)

This achieves the same thing while providing more control and layering standard protocols.