Not necessarily, the idea behind fast CGI is that you have your fast cgi application running in the background listening to incoming requests to handle them seperately. They kindof work like a very limited webserver.
As such process management must often be done individually. For example from the
nginx wiki:
Unlike Apache or Lighttpd, NGINX does not automatically spawn FCGI processes. You must start them separately. In fact, FCGI is a lot like proxying. There’s a few ways to start FCGI programs, but luckily PHP5 will auto-spawn as many as you set in the PHP_FCGI_CHILDREN environment variable.
Some webservers like Apaches
mod_fcgid spawns the respective number of fast cgi processes.
So it heaviely depends on the webserver.
This is why PHP nowadays has the so called
PHP FastCGI Process Manager (php-fpm), which dynamically pools and creates instances of the FastCGI services. This way, the user just starts the fpm, and sets it as the target for the fast cgi passthrough in the webserver, and the fpm then spawns new cgi processes dynamically, this also allows configuration of the individual processes (so some processes only handle some requests with some specific configuration).
It can also be quite helpful to containerize your application, e.g. using docker, and then you can just spin up multiple docker instances if you need to handle more load. This is what I usually do when I write a web server application, as this also has a lot of other useful features (as resource isolation and ease of deployment)