Not really incompatible, PHP provides configurable shared memory across processes that survive even if fastcgi releases every process and just keeps something idle for new requests.

don’t know a lot about fastcgi, but looking it up it seems like it also keeps a persistent process running to avoid execution overhead

More of less, the good thing about PHP + fastcgi is that it keeps a configure amount of minimum persistent processes (plus a dynamic number) to avoid execution overhead like you said… now there’s an important detail, PHP processes are generic, meaning if you’ve 50 apps hosted in your server they can all be served with just one persistent process. No need to spin up 50 processes for each app like with node/go etc.

Supervisors shutting down containers/processes are good, but starting up is slow compared to the single PHP idle process ready to go for any app. :)

Exactly my situation. Thanks @mlunar@lemmy.world. The only way this could be done better was to do it in PHP / have fastcgi so it wouldn’t require a constantly running background process specifically for it. People can say a lot of things about PHP, but nothing beats the fastcgi model.

Dude the guy is running on system with restricted resources and you’re suggesting the most bloated and prone to fail thing ever.

The OP would be way better with Debian + Cockpit (also provider a webUI and virtual machine manager) or Debian + LXD/LXC (containers + VMs, optional webUI). Both of those solutions are way lighter and won’t mess your base system.