What problem are you trying to solve?

Hello,

Use case
I want to build a dev stack for our dev team based on devbox. The full featured application is micro-services oriented, so running a fully working application requires to run multiple smaller projects simultaneously. Those applications are mostly in PHP, but the required versions are not always the same. To avoid running a devbox for each project, which would be perfect to manage versions but hard to orchestrate and resource consuming (n web server process and m PHP FPM while 1 web server and less PHP FPM are really required).

What I am willing to achieve
A single stack built on devbox running a single web server (nginx) and multiple PHP-FPM to run all micro-services simultaneously from a centralized.

What makes it hard
Currently, when a PHP package is added, the generic PHP plugin is enabled. If another PHP package is added, the same plugin is used and that forbids to run concurrent PHP FPM servers with process-compose.

Good to know
Devbox is great, I love it :)

What solution would you like?

Solution : Split the official PHP plugin into PHP plugins by version

Duplicate the official PHP plugin : one per version (probably minor versions : 7.4, 8.0, 8.1, ...)
Each plugin has then to be modified to use version specific env vars.
I guess that is the main change on the plugin itself.
The other modification is probably to be done on the automatic plugin inclusion mechanism that should include the right plugin depending on the adde PHP package version (I do not know how that is done at the time and cannot evaluate the impact of such a change).

Main advantage : It would benefit to all devbox users.

Of course, I would be glad to participate actively to the implementation.

Alternatives you've considered

Selfish solution : create my own private plugins based on the official PHP plugins

I guess I would :

• create thoses plugins by version in a private repo
• disable php plugin
• include manually the plugins by version in the full stack devbox config