Me and a team have been tasked with creating an application that can receive directories of node.js projects and should be capable of spinning up these projects (via npm start). Once the projects are spun up, we want to be able to hit the endpoints in these projects with AXIOS requests. The structure that we've gone with so far is 3 docker containers

| Client Docker Container | --> | Server Docker Container | --> | SpinUp Docker Container |

The lifecycle is that when a client submits a directory to the server, the SpinUp docker container should grab this dir and try to run npm start from inside it. I've done the research and it seems that docker volumes will be how the Server & SpinUp will communicate the files between them (or share them, more accurately).

Where the issue is coming is how we should use this SpinUp container - as it will just be awaiting submission to the server from the client before doing anything, should we have the container sitting there alive but sleep() the whole time, or should it not be spun up until a submission is received? This opens a whole other can of worms, dynamically creating a docker container during runtime.

Our first thought was running the node projects within the server container with the child_process() library, but there's a lot going on inside that server container and overloading it was not playing nicely.

So just as an overview of the process of the app:

i) the user submits a directory (or a zip of one) of a node.js project (Think a really basic express app, with 2 endpoints url/get & url/post

ii) Once submitted, this node.js project should be spun up by npm start (or like command) inside the SpinUp docker container

iii) We then want to be able to send HTTP requests into this project to see responses

iv) We then need to kill the project (this was super nice in child_process(), and not sure if we should follow that approach in the SpinUp container or just kill the container itself)

Any thoughts or points in a direction would be amazing.

Thanks!